RE: Hints
Date: Tue, 16 Aug 2011 15:56:19 -0700
Message-ID: <FD1D618E4F164D4C8BA5513D4268174A015751BC9CC9_at_EXCHCLUSTER1-02.win.slac.stanford.edu>
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_at_structureddata.org] Sent: Tuesday, August 16, 2011 2:39 PM
To: MacGregor, Ian A.
Cc: oracle-l_at_freelists.org
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"), ç
-- http://www.freelists.org/webpage/oracle-lReceived on Tue Aug 16 2011 - 17:56:19 CDT