4. 预分析工作

　　在开始分析跟踪文件前，我们首先进行一些观测，了解一些CBO计算成本时的有关因素。有时，这些参数和因素的值会很好的告诉我们，为什么从诸多执行计划中选择了特定的执行计划。

　　要收集10053事件的跟踪文件，可以在sqlplus中使用下面的语法命令：

　　"oradebug tracefile_name"会显示10053产生的跟踪路径与文件名。

　　 A) 确认查询被跟踪了

　　这步很重要，因为我们想确认所跟踪的是相关查询的跟踪信息。在跟踪文件的QUERY部分找到sql语句，并确认该sql就是我们所关心的sql语句。在10g版本中，如果没有使用绑定变量，QUERY部分在跟踪文件的结尾，否则，QUERY部分就在跟踪文件的开始。注意，搞清楚我们关心的QUERY部分跟哪些跟踪信息关联。有时候，很容易误以为跟踪文件尾部的QUERY部分就是想要跟踪的信息(这在10g中没有使用绑定变量的sql语句中很容易发生)。

　　 B) 参数

　　OPTIMIZER_FEATURES_ENABLE = 9.2.0

　　_OPTIMIZER_PERCENT_PARALLEL = 101

　　OPTIMIZER_INDEX_CACHING = 70

　　此参数会影响索引访问的成本，使用索引的成本为原始成本乘以(100 - optimizer_index_caching)/100。所以，本案例中，会用以下的因子相乘，来减少索引使用的成本：(100 - 70)/100 = 0.3或者大约1/3。这就是说，索引成本乘以0.3，即为不使用此参数情况下成本的1/3。注意，索引I/O成本根据"BLEVEL", "LEAF_BLOCKS", 以及 "CLUF" (群集因子)的值来计算。这个参数只影响与BLEVEL和LEAF_BLOCKS有关的成本部分。CLUF影响对表访问的成本，参数OPTIMIZER_INDEX_CACHING对其不会有影响。

　　OPTIMIZER_INDEX_COST_ADJ = 99

　　此参数用下面的分数来表示索引访问成本的百分比：optmizer_index_cost_adj / 100。本案例中，该分数为99/100 或者 0.99。该参数会影响所有的索引成本，即使在连接中使用的索引也一样受影响。

　　OPTIMIZER_DYNAMIC_SAMPLING = 1

　　该参数控制CBO多大程度的依赖于动态样本以便获取集的势和选择率的信息，集的势和选择率会在计算访问路径的成本时用到。如果设置为1，表示仅仅当查询中表的统计信息缺失时才会使用样本统计方法。

　　_OPTIMIZER_COST_MODEL = CHOOSE

　　如果设置为CHOOSE，而且已收集系统的统计信息，CBO将使用新的CPU模型。如果设置为I/O，将会使用旧成本模型，忽略CPU成本。

　　DB_FILE_MULTIBLOCK_READ_COUNT = 64

　　该参数控制执行全表扫描或者索引扫描时的成本。该参数的值越高，执行全表扫描或者索引扫描时成本越低。该参数的值被CBO要么按照固定公式(如果OPTIMIZER_COST_MODEL = io)计算，要么从收集的实际统计信息中计算并进行参考。

　　_CPU_TO_IO = 0 (默认)

　　该参数用于量度在使用CPU和I/O成本来计算总成本时，一次I/O成本需要的CPU周期。如果设置为0，即默认值，CBO要么使用一个内部固定的值，要么使用系统统计信息派生的一个值(统计信息包含CPU转速，单块I/O时间，多块I/O时间，多块I/O时所读的平均块数目)。当CBO考虑CPU成本时，为了确认成本，判断CBO使用该参数的什么值非常重要。

　　 C) 计算CBO使用的CPU对I/O比率

　　为了确定CBO用到的_CPU_TO_IO的值，在10053中，必须找到一个入口，此入口包含下述参数的值：CPU 成本, I/O 成本, 总成本。通过获取这三个值，使用相关的公式，我们可以计算CBO内部使用的这个比率。

　　_CPU_TO_IO的值在10053中是个常量，在任何计算中都是一样的，因此任何入口中显示的这三个变量的值，对于计算_CPU_TO_IO的值都是有用的。需要注意的是，选择一个CPU和I/O成本较大的值，因为它们的值越大，算出来的结果就越准确。

　　找一个index fast full (IFF)扫描，或者一些包含CPU，IO与总体成本有关的信息。　

　　使用公式

　　综合的Resc Cost = (RSC_CPU cost / _cpu_to_io) + RSC_IO Cost

　　计算 _cpu_to_io:

　　_cpu_to_io = RSC_CPU Cost / (Combined Cost - RSC_IO Cost)

　　= 2865229980 / (55630 - 52693)

　　= 975563.49 CPU cycles per IO

　　 D)计算多块读除数

　　当CBO估算全表扫描或者索引快速全扫描的成本时，它会使用除数去除表或者索引的总块数，这个除数估算了每次从磁盘上进行的物理读时将要读入的块数(这里称为多块读除数MBDivisor)。以前，参数"DB_FILE_MULTIBLOCK_READ_COUNT”是估算多块读除数的一个基数(为了补偿实际环境下的限制，它的值通过公式进行减少的计算)，在9.2及其以后的版本中，多块读除数的值的估算在统计信息收集了的情况下，有很大的变化。

　　在分析10053之前，计算出CBO使用的这个除数，能帮助我们快速了解它的值是不是合理的。较低的值会导致CBO使用FTS和IFF时候的成本较索引访问路径要昂贵，较高的值，会使FTS和IFF的成本较低廉。

　　为了获得这个除数，找一个简单的表访问路径入口，获取表扫描("tsc")的资源成本("Resc")。然后查找表包含的总块数。计算公式如下：

　　tsc cost = Num Blocks / MBDivisor

　　MBdivisor = Num Blocks / tsc cost

　　例如：

　　在"Base Statistical Information"部分:

　　在"Single Table Access Path"部分:

　　Mdivisor = Nblks / tsc

　　Mdivisor = 125272 / 116982 = 1.07

　　注意：这个值有点低。查看系统统计信息以及了解这个值是如何计算的，这非常有用。较低的值会使FTS与IFF相对索引扫描来说较昂贵。也许这些值是真实的，但也可能系统统计信息是在过去某个时间获取过，但是不能反应系统负荷的实际状况。考虑FTS可能较昂贵，客户可能觉得他们进一步要使用index_cost_adjustment参数来降低索引成本。很容易看出，这个数据库在很多情况下，将倾向于使用一种索引访问的方式而不是FTS(全表扫描)。

　　多块读除数已经很低，这很可能阻碍CBO选择非索引的访问路径，这种情况下，客户将OPTIMIZER_INDEX_COST_ADJ设置得如此的高，看起来有点不寻常。了解一下客户以前为什么要设置这个值会很有帮助。

　　 E)查看" BASE STATISTICAL INFORMATION"与" SINGLE TABLE ACCESS PATH"部分，检查缺失或者不充分的统计信息：

　　典型问题包括：

　　表或者索引没有统计信息

　　如果一个对象没有收集统计信息，你会看到一些消息，比如："(NOT ANALYZED)"。

　　但是对于索引，不会有消息明确的指出它们没有被分析过。因此，你只能读索引的统计信息，并查看默认统计信息。LEAF_BLOCKS默认统计信息是25，CLUSTERING_FACTOR是800。

　　对于分区对象，需知道是否有全局或者分区级别统计信息被收集了。

　　为了检测global only(非分区级别统计信息被收集)，查找UNANALYZED分区。例如(下述数据不是来自当前实例的跟踪信息)：　

　　不幸的是，没办法弄清楚系统的总体统计信息的收集，是采用全局样本还是单个的分区表的方式。如果有疑问，全局样本最好是查看DBA_TABLES.GLOBAL_STATS，如果为YES，则表示全局统计信息已被收集。

　　 无直方图

　　为特定的列查找"No Histogram". 例子 (下述数据不是当前实例的追踪文件):