tablescan 之不同block size的影响

前面我们知道Oracle的CBO会根据操作系统的信息适当的调整db_file_multiblock_read_count的值，具体的测试结果如下 (CBO fundamentals原书上因为是8i的结果，所以和我的略有不同，差别就在于8i的全表扫描的cost比9i的少1)：

db_file_multiblock_read_count	tablescan 10000 block的cost	调整过的db_file_multiblock_read_count
4	2397	4.17
8	1519	6.58
16	963	10.38
32	611	16.37
64	388	25.77

接下来我们看看再不同的block size下，当设置db_file_multiblock_read_count=8的时候，扫描10000个block的情况：

Block Size	Costof 10,000 Block Scans	调整过的db_file_multiblock_read_count	Cost for 80MB Scan
2KB	611	16.37	2,439
4KB	963	10.38	1,925
8KB	1,519	6.58	1,519
16KB	2,397	4.17	1,199

从上面的实验得到的结果很有趣的，我们发现当我们扫描一个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下全表扫描要高：

Block Size	Costof 10,000 Block Scans	调整过的db_file_multiblock_read_count	Cost for 80MB Scan
8KB MSSM	1,519	6.59	1,519
8KB ASSM	1,540	n/a	1,540

这是因为ASSM下每个extent下都有多于的用来做管理的block。

ITPub博客

CBO学习笔记系列3(转载)

最新文章