RE: Hints
- From: "MacGregor, Ian A." <ian@xxxxxxxxxxxxxxxxx>
- To: "oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>
- Date: Tue, 16 Aug 2011 15:56:19 -0700
I was not speaking about Tim's comments which were not harsh and quite
reasonable, and also self-deprecating. Please don't jump to conclusions, but
stick to the evidence. Seems I've heard that somewhere before. All I can
say is that the astrophysicists are much happier now than before the change
was made. For what its worth, none of the other 50 or so databases under my
purview has had this parameter changed. I also thought I had included
caveats about changing the parameter, though perhaps not all.
Where I disagree with is the notion that the parameter should never be changed.
FWIW, doing as you suggest is more proper, and in the end would give better
throughput than the change in the parameter. Indeed that was the path I had
chosen, when I got the call suggesting changing it, and after singing: "NO!,
NO!, NO, we don't do that no more", gave it a try and instantaneously the
system was performing much better. The evidence is happy customers.
________________________________________
From: Greg Rahn [greg@xxxxxxxxxxxxxxxxxx]
Sent: Tuesday, August 16, 2011 2:39 PM
To: MacGregor, Ian A.
Cc: oracle-l@xxxxxxxxxxxxx
Subject: Re: Hints
Cases like this warrant further investigation - as with any execution
plan change. For whatever reason, a faster executing plan was found,
take the time to understand why this is the case. Is it a stats
related thing? Is it because the costing model assumes something that
is not correct in this environment? Is it related to the current
environment resource limitations?
Tim's comments/rants are completely valid in my opinion (perhaps
harsh, but fair) - way too many people just blindly apply something
(like "best practices"), ç
--
//www.freelists.org/webpage/oracle-l
Other related posts:
