Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 
 Home
 E-mail Us
 Oracle Articles
New Oracle Articles


 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog


 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Analysis
 Design
 Implementation
 Oracle Support


 SQL Tuning
 Security

 Oracle UNIX
 Oracle Linux
 Monitoring
 Remote s
upport
 Remote plans
 Remote
services
 Application Server

 Applications
 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S
upport  
 Development  

 Implementation


 Consulting Staff
 Consulting Prices
 Help Wanted!

 


 Oracle Posters
 Oracle Books

 Oracle Scripts
 Ion
 Excel-DB  

Don Burleson Blog 


 

 

 


 

 

 

 
 

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


 

 

��  
 
 
Oracle Training at Sea
 
 
 
 
oracle dba poster
 

 
Follow us on Twitter 
 
Oracle performance tuning software 
 
Oracle Linux poster
 
 
 

 

Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


                    









Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


 

Copyright © 1996 -  2017

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.

Remote Emergency Support provided by Conversational