Re: Hints
Date: Tue, 16 Aug 2011 14:39:47 -0700
Message-ID: <CAGXkmitnGc=+UvPhhSiMDrLeRucooUdwngnFT9H5aLaxc1uKpg_at_mail.gmail.com>
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"), then circulate their "solution" on the Internet. Nowhere is there any analysis of the problem, nowhere is there data from before or after, etc. because that is hard stuff - but it's these things that separates the true experts from the rest. I certainly discount "empirical" stories if there is no data to support the observations. Then the community spends the next 10 years trying to stomp out the "sins of the past." It's really time to raise the bar and embrace being data-driven.
On Tue, Aug 16, 2011 at 2:05 PM, MacGregor, Ian A.
<ian_at_slac.stanford.edu> wrote:
> I very much agree with what has been said, though some was a bit over the top. Here's the situation: A database is handling about 2800 connections per minute peak. These are not light-weight connections, but are pulling together information from on the fly user defined conic sections of the celestial sphere. The connections themselves come from perhaps 1000 client machines in a batch farm. The data is then processed via a pipeline controlled by the database which controls the order of the processing, and weeds out redundant steps.
>
> Shortly after this started one of the physicists had been ready one of Tim's old posts. He wanted to see what would happen if we the unmentionable parameter was changed. I advised against it, but finally thought that such a change would probably make the system worse. It did not, things improved dramatically. Oh we have a few queries where the buffer gets count are out-of-this-world. But overall the change turned out to be positive. I think the real problem was taking of the OS stats at a not so busy time. However the chances of reverting the parameter is not good.
>
>
> ________________________________________
> From: Greg Rahn [greg_at_structureddata.org]
> Sent: Monday, August 15, 2011 1:53 PM
> To: tim_at_evdbt.com
> Cc: neil_chandler_at_hotmail.com; MacGregor, Ian A.; oracle-l_at_freelists.org
> Subject: Re: Hints
>
> Or to put it another way: "make sure the scope of the solution matches
> the scope of the problem".
-- Regards, Greg Rahn http://structureddata.org -- http://www.freelists.org/webpage/oracle-lReceived on Tue Aug 16 2011 - 16:39:47 CDT