How often should we re analyze CBO statistics?
Oracle Tips by Burleson Consulting
February 12, 2004
There is a huge debate
among Oracle DBAs about the merits of periodically re-analyzing their
schema statistics for the cost-based SQL optimizer. Remember, the sole purpose of running
"analyze", "dbms_utility.analyze_schema" or "dbms_stats"
is to change the SQL execution plans, causing changes to your production
When we consider that re-analyzing stats can cause huge changes to data
access patterns I?m continuously amazed at the number of shops that
re-analyze on a schedule and have the ?Monday Morning? syndrome where
un-planned production changes are implemented.
What if I
have tight change control?
I have worked for shops where they must ?certify? every change, no
matter how trivial. Mostly banks and medical systems.
These ?certified? shops are stuck. On one hand, they are obligated to
follow the best-practices of their vendor, yet obligated not to make any
untested changes in production.
Even Oracle is schizophrenic on the issue; my contacts in the real-world
performance group are zealously in favor of the ?take one deep sample?
approach, while the 10g developers are pissed that the CBO has been
getting a bum-rap because of crappy statistics.
Personally, I love the automatic histogram generation ?skewonly? and the
?auto? option in dbms_stats, and use it for all my r2 clients.
However, I remain skeptical about the benefits of ?dynamic sampling? and
?workload analysis? automation tools for most shops. These Oracle10g
dynamic sampling features will be most useful for specialized systems
like data warehouses and decision support systems.
In my experience, the vast majority of OLTP shops DO NOT benefit from
scheduled re-analysis, and I?ve got shops where re-analysis NEVER results in
How can I be sure than a re-analyze does not cause a problem?
That's the issue, you
cannot be certain. The central questions about stats changes are:
1- How can I list the changes to execution plans after
2 - How do I justify the risk (and server expense) of
Some alternatives for the next release of Oracle might be:
1 - Enhance the dbms_stats "auto" option (monitoring) to make it more
intelligent. Wouldn't it be nice if dbms_stats could do an
"incremental" refresh, tracking changes that might make a difference to
a) Changes to
b) Changes to column skew. Only create histograms when column is skewed
AND SQL uses the column. The Oracle 10g workload
tool "claims" to do some of this.
c) Changes to highest-lowest values of key indexes, etc.
2- Devise a method where
new stats can be collected, stored and compared against historical SQL
a) Allow for dbms_stats to
collect, store and compare changes to existing execution plans, using
historical SQL from STATSPACK (or new 10g workload views)
b) Allow the DBA control about whether to implement the new statistics
Is the CBO
Sadly, there are still bugs
in the CBO, especially with complex subqueries.
I have more than a dozen systems where management insists on staying
with the RBO! Every time we collect deep stats and histogram and
switch optimizer_mode, hundreds of statements generate poor
It would cost these clients many thousands of dollars to have adjusted
these plans, and management says "If it ain't broke, why fix it".
We need look no further than Oracle Applications to see this issue.
Oracle made a big-deal
about going to the CBO in 11i, yet when we look at the SQL, a
significant number of statement employ the "rule" hint!
Connect-the-dots and you
can guess why the RBO IS NOT being removed from Oracle10g. . . .
||If you like
Oracle tuning, you might enjoy my book "Oracle
Tuning: The Definitive Reference", with 950 pages of tuning tips and
You can buy it direct from the publisher for 30%-off and get instant
access to the code depot of Oracle tuning scripts.