完又能保证收集到的统计信息的质量（接近采样比例为100%时的质量）。如果是Oracle 10g，继续采用DBMS_STATS.AUTO_SAMPLE_SIZE就不太合适了，因为这个自动采样比例在Oracle 10g里是非常小的一个值，我们建议在Oracle 10g中将采样比例的初始值设为30%，然后根据目标SQL的实际执行情况再做调整；如果是Oracle 9i，我们建议将采样比例的初始值也设为30%，然后根据目标SQL的实际执行情况再做调整。
（5）建议使用DBMS_STATS包来对分区表收集全局统计信息，并且收集分区表的统计信息时应使用一致的GRANULARITY参数，全局统计信息的收集方法和注意事项请见《基于Oracle的SQL优化》的5.6节“全局统计信息”。
（6）建议要额外收集系统统计信息，但系统统计信息只收集一次就够了，除非系统的硬件环境发生了变化，系统统计信息的收集方法请见《基于Oracle的SQL优化》的5.9节“系统统计信息”。
（7）建议要额外收集X$表的内部对象统计信息，但仅仅是在明确诊断出系统已有的性能问题是因为X$表的内部对象统计信息不准的情形下，对于其他情形就不要收集了。X$表的内部对象统计信息的收集方法和注意事项请见《基于Oracle的SQL优化》的5.11节“内部对象统计信息”。
如果是用写shell脚本的方式手工收集统计信息，我们推荐采用如下的方式。
（1）对于单表的统计信息收集，建议初始情况下采用如下的方式（然后根据目标SQL的实际执行情况再做调整）：
（a）适用于Oracle 11g及其以上的版本
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 REPEAT' );
（b）适用于Oracle 9i/10g
EXEC DBMS_STATS.GATHER_TABLE_STATS(
OWNNAME => 'SCHEMA_NAME',
TABNAME => 'TABLE_NAME',
ESTIMATE_PERCENT => 30,
CASCADE => TRUE,
METHOD_OPT => 'FOR ALL COLUMNS SIZE REPEAT' );
（2）对于单个schema的统计信息收集，建议初始情况下采用如下的方式（然后根据目标SQL的实际执行情况再做调整）：
(a) 适用于Oracle 11g及其以上的版本
EXEC DBMS_STATS.GATHER_SCHEMA_STATS(
OWNNAME => 'SCHEMA_NAME',
ESTIMATE_PERCENT => DBMS_STATS.AUTO_SAMPLE_SIZE
CASCADE => TRUE,
METHOD_OPT => 'FOR ALL COLUMNS SIZE REPEAT' );
(b) 适用于Oracle 9i/10g
EXEC DBMS_STATS.GATHER_SCHEMA_STATS(
OWNNAME => 'SCHEMA_NAME',
ESTIMATE_PERCENT => 30
CASCADE => TRUE,
METHOD_OPT => 'FOR ALL COLUMNS SIZE REPEAT' );
无论是用Oracle自带的自动统计信息收集作业还是用我们自己写的shell脚本来收集统计信息，对于直方图统计信息的收集策略，我们建议都采用如下的方式：只对已经存在直方图统计信息的列重复收集直方图统计信息，而目标列的初次直方图统计信息的收集则是由了解系统的DBA手工来做。具体来说就是这样：
（1）设置METHOD_OPT的值为‘FOR ALL COLUMNS SIZE 1’后先收集一次统计信息，这意味着删除了所有列上的直方图统计信息。
（2）在已经删除了所有列上的直方图统计信息后，设置METHOD_OPT的值为‘FOR ALL COLUMNS SIZE REPEAT’，这意味着今后将只对已经存在直方图统计信息的列重复收集直方图统计信息。
（3）在系统使用或调优的过程中，目标列的初次直方图统计信息的收集是由了解系统的DBA手工来做。
上面所汇总的注意事项和推荐收集方法并没有涵盖所有的方面，完全可以在了解上述知识点的基础上制订出适合于自己系统的统计信息收集策略。比如，如果某个表的数据变化得特别频繁，我们完全可以将其统计信息锁住（使用DBMS_STATS.LOCK_TABLE_STATS，适用于Oracle 10g及其以上的版本），从此不再花时间对其收集统计信息，当然这里的前提条件是锁住的统计信息能使访问该表的SQL走出理想的执行计划。
总之，如何正确的收集统计信息是一个复杂的话题，需要注意的知识点也有很多，但原则只有一个：量体裁衣，找到适合自己系统的统计信息收集策略，用尽量小的代价收集到能稳定跑出正确执行计划的统计信息即可。
某个很耗资源的SQL依然执行很快，要么是用了并行，要么是用了类似于Exadata这样的分布式计算框架。此时如果硬件资源还能撑住，那么再优化的意义并不大（而且很多情况下，特别是在OLAP的环境下，并行和使用Exadata这样的分布式计算框架是针对某些SQL的唯一优化手段）。
我的学习方法：
1、我在metalink上至少已经看过5000篇文章，所以对问题还是有一定的敏感度。
2、这个是基于我比较熟悉Oracle数据库，另外就是metalink和DSI对我的帮助非常大，有metalink和DSI的基础，有一些问题我在模拟的过程中确实可以做到信手拈来。
3、BBED只是一个工具，用好它的关键在于要了解Oracle数据库的一些internal知识点和数据块结构，这才是我们需要深入钻研的地方，深入研究BBED这个工具没有太大意义。
如何通过metalink获取帮助:
第一、怎样能够通过metalink提高自己的水平？（如何通过metalink来学习呢）
如果研究Undo那么就看一个系列的undo文章 包括ORA-1555处理等等， 通过系列文章来学习
第二、metalink中是否有 为查询 各种指标而写好的 SQL脚本？我该如何才能找到这些？
使用script 做关键词 可以获得绝大多数这些脚本
例如undo script
1、metalink是我最频繁逛的网站，没事我就在上面晃
2、不是，DSI我只是反复的看，实验我做的不多（我只有在觉得不太对的时候才会去做实验验证）
3、我用工具或脚本不多，给不了你什么推荐（推荐用sosi.txt看统计信息，这个我强烈推荐，呵呵）。Tanel Poder的网站上有很多很有用的脚本，你可以去看看
1、我个人是两种方式兼有，先是在备份恢复方面钻研的相对深入，后续又在优化器方面做了较深入的钻研，同时从06年开始，我一直坚持在MOS上看Oracle数据库各个方面的文章（这应该算是横向的学习）。
2、Jonathan Lewis的《Cost Based Oracle Fundamentals》的第4章“Simple B-tree Ac |