11g上如何收集优化器(optimizer)统计信息

注：本文参见MOS（my oracle support）英文文档Document:749227.1 - How to Gather Optimizer Statistics on 11g

本文概述了在Oracle 11g中收集CBO（Cost Based Optimizer）统计信息的推荐方法。
 
   本文适用范围：
       
   Oracle Server – 企业版 – 版本 11.1.0.6
to 11.2.0.3
       
   Oracle Server – 标准版 –版本11.1.0.6 to 11.2.0.3
       
   Oracle Server – 个人版 –版本11.1.0.6 to 11.2.0.3
 
   文文信息适用于任何平台。

1、不同数据库版本的缺省设置：
   
不同版本收集统计信息时使用的缺省设置可能是不一样的，例如：
?
a、ESTIMATE_PERCENT的缺省值:
          9i :
100%
       
  10g :
DBMS_STATS.AUTO_SAMPLE_SIZE (使用非常小的估算百分比)
          11g :
DBMS_STATS.AUTO_SAMPLE_SIZE (使用更大的估算百分比 - 100%)
? b、METHOD_OPT:
defaults:
          9i :
"FOR ALL COLUMNS SIZE 1" ，等同于没有列值的具体分布信息。
          10g
and 11g : "FOR ALL COLUMNS SIZE AUTO" 。
       
   设置成AUTO意味着如果histogram的存在会有助于生成更准确的执行计划，DBMS_STATS会自动在需要字段上生成它。
    
 在11g中，AUTO_SAMPLE_SIZE的缺省值是100%，从而尽可能使统计信息是准确的。在之前的版本上，由于时间的制约，100%的sample
size有时候是不可能的，由于11g实施了一个新的hash算法避免了传统的排序（在9i和10g典型慢的部分是排序），这显著的减少了了收集的时间并提升了资源使用效率。同样，是否收集列上的统计信息也是自动决定的。

2、快速重建统计信息的推荐步骤
 
   为快速删除和重建某张表及它的索引的统计信息（包含非均匀分布列的统计信息）,推荐如下操作：
     exec
dbms_stats.delete_table_stats(ownname=>‘user_name‘,
            
tabname=>‘table_name‘,cascade_indexes=>true);
     exec
dbms_stats.gather_table_stats(ownname=>‘user_name‘,
          
   tabname=>‘table_name‘,
          
   estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE,
          
   cascade=>true,
             
 method_opt=>‘for all columns size AUTO‘);
      注：从10gR2
开始,可用下边的方法来恢复统计信息，参见文档Document:452011.1
- * Restoring table statistics in
10G onwards

3、统计信息收集命令的几种情况
 
   a、收集单一表的统计信息
          exec
dbms_stats.gather_table_stats(
             
   ownname => ‘ Schema_name ‘,  
             
   tabname => ‘ Table_name ‘,
             
   estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE,
             
   cascade => TRUE, - method_opt => ‘FOR ALL COLUMNS SIZE AUTO‘
);
         
注1：如果确定histogram不会对产生更好的执行计划有帮助，那么更好的做法是将下边这一行：
       
   method_opt => ‘FOR ALL COLUMNS SIZE AUTO‘替换成method_opt => ‘FOR ALL
COLUMNS SIZE 1‘
         
注2：您需要将‘ Schema_name ‘和‘ Table_name ‘替换成真正需要收集的schema和table的名字。

b、收集某一schema下的所有对象的统计信息
          exec
dbms_stats.gather_schema_stats(  
                
 ownname => ‘ Schema_name ‘,  
                
 cascade => TRUE,
                
 method_opt => ‘FOR ALL COLUMNS SIZE AUTO‘ );
          注：将‘
Schema_name ‘替换成需要收集的schema的名字。

c、收集database中所有对象的统计信息:
           exec
dbms_stats.gather_database_stats(  
                
 cascade => TRUE,  
                
 method_opt => ‘FOR ALL COLUMNS SIZE AUTO‘ );

4、注意事项
 
   a、为了尽可能生成准确的统计信息，推荐使用的sample size（采样率）为100%。因为sample
size的减少可能会导致生成的统计信息不准确。一般来说使用100%的sample
size会使收集信息的时间增长，所以需要考虑调整当前使用的maintenance window，使统计信息的收集能在一个maintenance
window完成。
?
b、收集新的optimizer统计信息一般会保持或改进已存在的执行计划，但是也可能使某些查询的性能下降。所以从10gR1开始系统默认会保留最近30天的统计信息，这期间如果遇到问题可以用如下方法恢复到之前的统计信息:
         
Document:452011.1 - * Restoring table statistics in 10G onwards
?
c、收集新的optimizer的统计信息可能使shared
pool中的cursor无效，所以建议在数据库负载低的时候执行统计信息收集工作，比如在maintenance window期间执行。
? d、除了object
statistics（比如业务表和索引的统计信息）以外，推荐对dictionary objects（数据字典对象）也做统计信息收集:
       
 Document 457926.1 How to Gather Statistics on SYS Objects and ‘Fixed‘
Objects?
?
e、对非常大的系统，统计信息的收集会是非常消耗时间和资源的工作。在这种情况下需要小心选择sample
size的大小，确保在可接受的时间范围、资源限制和维护窗口内完成收集。详细建议参见以下文档：
       
 Document 44961.1 Statistics Gathering: Frequency and Strategy
Guidelines
 
   f、对于某些系统，推荐使用基于改变的统计信息的收集，避免重复收集不必要的信息。和10g相比，11g的自动统计信息的过程已经发生了改变，详见以下文档：
        Document
237901.1 Gathering Schema or Database Statistics Automatically -
Examples
        Document
756734.1 11g: Scheduler Maintenance Tasks or Autotasks
        Document
743507.1 Why Has the GATHER_STATS_JOB been removed in 11g

5、收集对象统计信息需考虑的因素
     Cost Based
Optimizer（CBO）是基于统计信息来生成特定查询的执行计划。当sample
size减小的时候，基于抽样出来的样本可能会生成不同的统计信息，这是因为这些样本有可能正好是用某些特定的方法录入的。
在11g中，推荐使用定期统计信息收集脚本收集统计信息。
 
   收集统计信息时考虑如下因素：
 
   a、使用足够大的sample size 在11g中，对于ESTIMATE_PERCENT，我们建议使用缺省的
DBMS_STATS.AUTO_SAMPLE_SIZE。Oracle首先会判断如果对一个表使用100%的sample size是否能在一个maintenance
window中收集完。如果能收集完那么就对这个表使用100%的sample size，这意味着对这张表收集统计信息的频率会降低。如果100%的sample
size并不可行，那么会至少使用30%作为sample size。11g使用了一种hash算法来计算统计信息，所以在大多数时候收集信息的性能都是可以接受的。
通常，对大部分应用程序而言，相对于数据每天发生的一点点变化，统计信息整体上的准确度更重要一些。
?
b、收集所有对象的统计信息
       
 确保所有对象（表和索引）都收集了统计信息。这个可以通过使用CASCADE参数来实现。
?
c、收集字段的统计信息/数据非均匀分布列的histogram
       
 确保所有数据非均匀分布的列都收集了histogram,并且使用METHOD_OPT参数来确保histogram的精度。通常推荐使用缺省的设置“AUTO”。这意味着如果histogram的存在会有助于生成更准确的执行计划，DBMS_STATS会自动在需要字段上生成它。相对于在所有的列上收集histogram，只在确实需要的列上收集是更稳妥的做法。
       
 在早期的版本中，参数METHOD_OPT的缺省的设定是"FOR ALL COLUMNS SIZE
1"。这意味着我们只会收集列的最大最小值，而没有值的具体分布的信息。有些时候histogram的存在反而不利于好的执行计划的产生，所以当从一个版本升级到另外一个版本后，用户可能希望先将这个参数设置为之前版本的值，运行一段时间后再调整为当前版本的值，确保升级后系统更加平稳，详见文档：Document
465787.1 How to: Manage CBO Statistics During an Upgrade from 10g or 9i into
11g
 
   d、收集分区对象的Global Statistics(全局统计信息)
       
 如果使用了partition（分区）技术，时间允许的话尽可能收集Global
Statistics。Global Statistics是非常重要的，但因为涉及数据量及收集时间长度的影响，很多时候它都被略过了。小的采样（例如0.001,
0.0001,
0.00001等）可以是非常有效的，但同时大量能帮助optimizer生成准确执行计划的数据会被忽略掉的。参数ESTIMATE_PERCENT有一个非常弹性的有效的范围，不同的系统需要经过测试才能得出最适合这个系统的值。详见以下文档：Document
236935.1 Global statistics - An Explanation
     e、收集System
Statistics(系统统计信息)
         
收集System
Statistics可以真实反映系统CPU负载情况。除了估算正常I/O部分的cost之外，这些信息会帮助CBO更好的估算CPU部分的cost。详细内容可参见文档：
       
 Document 470316.1 Using Actual System Statistics (Collected CPU and IO
information Document 149560.1 Collect and Display System Statistics (CPU and IO)
for CBO usage
        Document
153761.1 Scaling the System to Improve CBO optimizer
?
f、从早期版本升级到11g
    
   如果您是从Oracle的早期版本升级到11g，您可以参见以下关于统计信息管理的建议：
        Document
465787.1 How to: Manage CBO Statistics During an Upgrade from 10g or 9i into
11g