Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> RE: When stats trash your performance

RE: When stats trash your performance

From: Charudatta Joshi <>
Date: Thu, 8 Dec 2005 14:52:00 +0530
Message-ID: <>


Good point about backing up stats which wasn't mentioned before in this thread. I will just pitch it stronger:

NEVER start gathering statistics until you have exported the earlier stats.

Stephen, have you checked if the person gathering stats had exported the earlier ones by any chance? Also, there might be chance of getting the original stats from your last backup, if you can restore it on a different host.

Mark Farnham's solution based on a repository of SQL queries is very nice. In fact a full-fledged product could be constructed on that concept.


-----Original Message-----
[] On Behalf Of malcolm arnold Sent: 07 December 2005 22:01
Cc:; Subject: 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.


On 07/12/05, Steve Ollig <> 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:
> []On
> Behalf Of stephen booth
> Sent: Wednesday, December 07, 2005 12:59 PM
> To:
> 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
> ______________________________________________________________________



The contents of this E-mail (including the contents of the enclosure(s) or attachment(s) if any) are privileged and confidential material of MBT and should not be disclosed to, used by or copied in any manner by anyone other than the intended addressee(s).   In case you are not the desired addressee, you should delete this message and/or re-direct it to the sender.  The views expressed in this E-mail message (including the enclosure(s) or attachment(s) if any) are those of the individual sender, except where the sender expressly, and with authority, states them to be the views of MBT.

This e-mail message including attachment/(s), if any, is believed to be free of any virus.  However, it is the responsibility of the recipient to ensure that it is virus free and MBT is not responsible for any loss or damage arising in any way from its use

Received on Thu Dec 08 2005 - 14:54:41 CST

Original text of this message