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 system.

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 9ir2 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 moist 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 execution plan changes.

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 re-analysis?

     2 - How do I justify the risk (and server expense) of re-analyzing?

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 execution plan:

a) Changes to clustering_factor

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 (from stats$sql_summary)

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 bug-free?

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 plans.

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 scripts.  You can buy it direct from the publisher for 30%-off and get instant access to the code depot of Oracle tuning scripts.