Re: Hints
- From: Greg Rahn <greg@xxxxxxxxxxxxxxxxxx>
- To: ian@xxxxxxxxxxxxxxxxx
- Date: Tue, 16 Aug 2011 16:30:25 -0700
I'm not jumping to conclusions, nor was I being critical of any
specific example, but speaking in general. There are always
exceptions, but exceptions can be justified and supported with data.
Just beware of the the silver bullet syndrome...
The unfortunate part of scenarios like yours is that rarely anyone
goes back and does the root cause analysis. It tends to fall into the
bucket of "problem...solved". Hopefully you get that chance.
On Tue, Aug 16, 2011 at 3:56 PM, MacGregor, Ian A.
<ian@xxxxxxxxxxxxxxxxx> wrote:
> 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
>
>
>
--
Regards,
Greg Rahn
http://structureddata.org
--
//www.freelists.org/webpage/oracle-l
Other related posts:
