利用rowid快速在线更新海量数据

bluemoon0083

-- keep buffer pool 6GB
问下这张表多大？keep池设了多大？

suniori

无它，但机器好而已

battleman

为什么第一种方法不keep呢?

duiego

对啊，我也觉得是因为你把表keep了进去，所以才会有速度提高的，和rowid的顺序读取应该没有关系的吧！ 楼主回答一下！

fromeast

原帖由 棉花糖ONE 于 2008-9-8 09:11 发表
虽然你的那个最后是达到结果了,但是还是没想明白,order by rowid怎么会影响一个块里的行,还有一个问题就是,从你的hint上看也应该是hash join+full table scan+index fast full scan,正常的等待事件应该是sequential scan而非scatter scan

按照ROWID的结构，ROWID的顺序即是数据块的顺序，而CURSOR返回的记录的顺序即是更新的顺序，所以更新就会按数据块的物理顺序依次处理，即更新完一个数据块里的所有行，再更新下一个数据块的数据。这样一来，对于每个数据块，就只有第一行会产生物理读，其他的行，因为数据块已经在内存里了，就只都是逻辑读了。

按数据块的顺序更新可能还有另外一个好处，就是磁盘的顺序读写成本更小，因为磁头减少了磁头的寻道动作。对于单个磁盘肯定是这样，但对于做了条带的RAID是不是也有这个好处，就不清楚了。但有一点是肯定的，就是好的存储设备会根据顺序访问的规律做预读，即监测到顺序访问时，会提前把后续的数据块读入存储的缓存。

CURSOR上的HINT只对CURSOR里的SELECT其作用。从SQL TRACE文件看到的大量的db file sequential read事件是UPDATE语句等待的，不是SELECT语句等待的。

[ 本帖最后由 fromeast 于 2008-9-8 10:37 编辑 ]

fromeast

原帖由 bluemoon0083 于 2008-9-8 09:49 发表
-- keep buffer pool 6GB
问下这张表多大？keep池设了多大？

这张表>60GB。KEEP BUFFER SIZE是6GB。

suniori

KEEP 够大，给个60GB 估计2小时就好了

fromeast

原帖由 duiego 于 2008-9-8 10:18 发表
对啊，我也觉得是因为你把表keep了进去，所以才会有速度提高的，和rowid的顺序读取应该没有关系的吧！ 楼主回答一下！

alter table T1 storage (buffer_pool keep)立即就执行结束了，看起来只是改了数据字典，并没有执行读取的动作。这个表有60多GB，而KEEP BUFFER只有6GB，无法装下整张表。

fromeast

原帖由 棉花糖ONE 于 2008-9-8 09:37 发表
楼主order by rowid为什么会起到你说的作用呢,你第一个测试的时候缓存了T1表吗

第一个测试没有把表改到KEEP池，不过我觉得KEEP池对性能的提升作用不大，因为KEEP池只有6GB，而T1却大于60GB。有空我试一下，第一个测试用KEEP池，第二个测试不用KEEP池，各自的效果有什么变化。

棉花糖ONE

原帖由 fromeast 于 2008-9-8 10:22 发表


按照ROWID的结构，ROWID的顺序即是数据块的顺序，而CURSOR返回的记录的顺序即是更新的顺序，所以更新就会按数据块的物理顺序依次处理，即更新完一个数据块里的所有行，再更新下一个数据块的数据。这样一来，对于每个数据块，就只有第一行会产生物理读，其他的行，因为数据块已经在内存里了，就只都是逻辑读了。

CURSOR上的HINT只对CURSOR里的SELECT其作用。从SQL TRACE文件看到的大量的db file sequential read事件是UPDATE语句等待的，不是SELECT语句等待的。

这里的order by rowid应该是不影响一个块里的行的,你第一个做的时候有把表放到keep池吗??