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

kisschina

有这么神奇？！

shijialiang

rollingpig 说得非常清楚，谢谢

这样看来
by rowid 和 keep都应该是速度变快的原因

laielvis

学习了。还得自己测测。

BTxigua

原帖由 xzh2000 于 2008-9-11 10:48 发表
还有n多种办法提高批量数据处理的速度...
假如需要在2个小时内处理完毕呢?楼主该如何处理?其实用不用rowid,都可以很快地处理完...

讲讲你的n种方法啊。

fromeast

原帖由 xzh2000 于 2008-9-11 10:48 发表
还有n多种办法提高批量数据处理的速度...
假如需要在2个小时内处理完毕呢?楼主该如何处理?其实用不用rowid,都可以很快地处理完...

老和尚不要卖关子啦

fromeast

原帖由 棉花糖ONE 于 2008-9-11 10:44 发表
还不知道是keep住表起作用还是order by rowid起作用了,keep住表当然能减少一些物理读啊

测一次至少需要1个多小时的CURSOR打开时间，而我们的测试组白天黑夜地一直占着测试环境。有机会一定按相同的条件测一下。

不过我觉得KEEP在这个例子里的作用应该不大。表数据只有被访问，才会读到内存里，并不是把表设为KEEP池，就都读进来驻留在内存了--也没那么大的地方把表数据全部装进来。从这一点上来说，DEFAULT池和KEEP池的作用是相同的。ORACLE之所以要设置KEEP池，是提供一种手段，让DBA有机会把不同行为的表分开，使之互不干扰。拿本例来说，设成KEEP是想在生产上执行时，免得其他程序把刚读进来并且还没有处理完的数据块挤出去。但是在当时的测试环境上的负载很低，所以在测试时KEEP应该没起什么作用。这个观点需要实际验证。你也可以构造一个测试环境验证你的想法。

对于方案一（不用order by rowid），反正rowid是乱序的，每次基本上也都是从磁盘读，既然data buffer不起作用，那么用哪个data buffer都一样。

likaiabc

我觉得可以改成单条update更新，
首先分配一个巨大的回滚段，那后
update t1 set curr_count = t2.curr_count
from t1,t2 where t1.id2 = t2.id2;


不知道对不对。

zhp6489

根据数据字典表中数据块的信息来生成ROWID，然后每次只更新这些数据块中的信息，这样就不需要那么大的CURSOR了，而且每次都是更新几个数据块，也不需要根据ROWID进行排序了，占用系统的资源也应该下降了。

winedy

keep提高应该是明显的。rowid有没有效果，去掉keep再测试下看看就明白了。

cow977

如果是table full access的话，也会是同一数据块的记录在一起的，只是数据块之间不是顺序的。

应该还是KEEP起的作用。

用了order by ，增加了打开的时间。