ASSM下DML的物理读高

    ASSM虽然是9i就出现的功能, 但一直没有使用它, 也没有任何经验. 早上在检查执行成本有显著变化的SQL时, 发现一条Insert语句的单次执行成本只有以前的四分之一, 很奇怪一条插入语句的平均执行成本为什么有这么大的变化. 从Statspack的信息中用WebChart画了一个图.

    在上图中, 这个语句的表是按月分区的, 每天进入的记录数是相同的, 但物理读31号和1号截然不同, 可能是什么原因呢?

    在ASSM中虽然了减轻了DML操作对Segment Header的争用, 但增加了用于空间管理(Free List的替换方案)Bitmap区域, 这部份的读取需要代价, 另外记录会被尽量均分出去, 最近Insert的记录也不一定放在一起, 所以每次Insert操作都可能会发生物理读.

    除了这方面的问题, 记录的查询一般落在最新的数据上, 但由于使用ASSM, 最新的记录被分散的很历害, 所以查询的读也会比较多. 比如按时间去查询, 就是一个典型的例子, 用传统的Free List去管理, 情况会好一些.

    以上还只是一些猜测, 还没有将表移到非ASSM的表空间上正式对比过, 有空先测试一下好了.

留言 (5)

ASSM是可能有这样的问题

刚才试了一个40MB大小的小表,没有测出这种情况。

将记录插入进去后,根据时间范围去查询某个范围的记录中ROWID(文件号+块号)组合的个数. 结果是没有什么差异.

应当测试多用户并发的情况!

找一个并发插入几百万记录的工具。

要是以前的话,第一句话就说自已写一个,现在是写不动了。

插入一行的成本

                        db block gets        consistent gets
ASSM (No Index)                    3                      5
Free List (No Index)                1                      5
ASSM (1 Index)                      6                      5
Free List (1 Index)                4                      5

发表留言:

« Previous | Main | Next »

英语900句 | English 900

  • Would you be so kind as to lend me some money?
  • 你能借我一点儿钱吗?
  • No problem. How much?
  • 没问题, 你要多少?
  • I hope I'm not bothering you.
  • 我希望我没有打扰你.
  • I hope that will not cause you too much trouble.
  • 我希望那不会给你添太多麻烦.
  • I really appreciate your help.
  • 我非常感谢你的帮助.