Re: When stats trash your performance

I agree that changes to statistics should adhere to the same change management procedure as application code.

As a general point, I think that it is more important to have consistent response times than the best possible response times in a production environment.

I also think that it is a good idea to backup your statistics (using dbms_stats.export_*_stats) as first step of any statistic regathering procedure, so you have the capability to put things back if it all goes horribly wrong.

Malcolm.

On 07/12/05, Steve Ollig <sollig_at_lifetouch.com> wrote:
>
> Stephen -
>
> I believe the reasoning behind that school of thought is that statistics
> should adhere to normal change management procedures just as application
> code would. You wouldn't sling a code change into production without
> running it through a well defined QA process. Why wouldn't you do the same
> with statistics?
>
> -----Original Message-----
> From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]On
> Behalf Of stephen booth
> Sent: Wednesday, December 07, 2005 12:59 PM
> To: oracle-l_at_freelists.org
> Subject: When stats trash your performance
>
> I've heard mention in a number of talks that you shouldn't gather stats very
> often, even not at all once a system is bedded in, as it can cause your
> database to start performing really badly. I don't recall any one ever
> saying, or ever reading, an explanation as to why this might happen.
> Perhaps I'm looking at it from the wrong perspective but it seems axiomic
> that the fresher your stats the better decisions CBO is likely to make.
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit
> http://www.messagelabs.com/email
> ______________________________________________________________________
>

--
http://www.freelists.org/webpage/oracle-l