ASSM下DML的物理读高
ASSM虽然是9i就出现的功能, 但一直没有使用它, 也没有任何经验. 早上在检查执行成本有显著变化的SQL时, 发现一条Insert语句的单次执行成本只有以前的四分之一, 很奇怪一条插入语句的平均执行成本为什么有这么大的变化. 从Statspack的信息中用WebChart画了一个图.
在上图中, 这个语句的表是按月分区的, 每天进入的记录数是相同的, 但物理读31号和1号截然不同, 可能是什么原因呢?
在ASSM中虽然了减轻了DML操作对Segment Header的争用, 但增加了用于空间管理(Free List的替换方案)Bitmap区域, 这部份的读取需要代价, 另外记录会被尽量均分出去, 最近Insert的记录也不一定放在一起, 所以每次Insert操作都可能会发生物理读.
除了这方面的问题, 记录的查询一般落在最新的数据上, 但由于使用ASSM, 最新的记录被分散的很历害, 所以查询的读也会比较多. 比如按时间去查询, 就是一个典型的例子, 用传统的Free List去管理, 情况会好一些.
以上还只是一些猜测, 还没有将表移到非ASSM的表空间上正式对比过, 有空先测试一下好了.
