CBO学习笔记3
http://hi.baidu.com/richard%5Fcxs/blog/item/7c3398510618a61a367abe49.html
|
tablescan 之 不同block size的影响 tablescan 之 不同block size的影响 前面我们知道Oracle的CBO会根据操作系统的信息适当的调整db_file_multiblock_read_count的值,具体的测试结果如下 (CBO fundamentals原书上因为是8i的结果,所以和我的略有不同,差别就在于8i的全表扫描的cost比9i的少1):
接下来我们看看再不同的block size下,当设置db_file_multiblock_read_count=8的时候,扫描10000个block的情况:
从上面的实验得到的结果很有趣的,我们发现当我们扫描一个block size为2k的表的时候,调整过的db_file_multiblock_read_count等于16.37,也就是等于我们上一个测试里面设置db_file_multiblock_read_count=32,block size为8k的表的时候的调整过的db_file_multiblock_read_count。通过观察其他的block size的情况,再和前面的实验做对比,我们发现了这个结论:当在非default的block size的表上做全表扫描的时候,Oracle会自动修改db_file_multiblock_read_count的设置,更改之后的 db_file_multiblock_read_count设置是= "default block size" * "当前的db_file_multiblock_read_count设置" / "这个表的block size",于是当oracle生成执行计划的时候,会根据这个更改之后的db_file_multiblock_read_count去得到新的调整过的db_file_multiblock_read_count。 这么说有一点绕,简单的说,当做小block size做全表扫描的时候,Oracle会倾向在每次IO里多读一些block,而当block size比较大的时候,Oracle会倾向在每次IO里相对少读一些block,从性能的角度,也确实应该如此。 最后,我们看到,当我们固定表的大小(而不是固定表的block的个数),再进行实验的时候,大的block size显示的全表扫描的cost还是相对要少的。所以如果我们需要全表扫描大量数据的时候,把这个表放到比较大的block size的表空间里面,还是有用的,不过相对而言,效果不会像我们以前估计的那么大而已。 最后,由于我们前面的实验都是做在MSSM下的,在ASSM下,我们发现全表扫描的cost要比同样的block size的MSSM下全表扫描要高:
这是因为ASSM下每个extent下都有多于的用来做管理的block。 |
浙公网安备 33010602011771号