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

Marshaljlc · 发表于 2008-9-15 19:39

rowid也好，keep也罢，还有老和尚的方法，都没说明透彻。加精华值得商榷。

iamclq · 发表于 2008-9-15 20:30

原帖由 棉花糖ONE 于 2008-9-8 08:39 发表
在第一个里没看到你缓存T1表啊,想不明白这里有了order by rowid怎么会起到你说的那作用,order by rowid怎么会影响一个数据块里的数据呢???

rowid 排序的话，相同块的数据就会排在一起更新，这样就避免了数据读进来只更新一部分数据，然后又换出，更新另一部分时又要调进来。我想楼主是这个意思吧。

iamclq · 发表于 2008-9-15 20:31

原帖由 TO_TO_RO 于 2008-9-8 09:05 发表
根据表中字段的特点比如idx=aa,idx=bb....将小的表分割，直接UPDATE呢？
另外，游标里面每隔1000行就commit一次也是忌讳的。容易引起“快照太旧”错误

同意，尤其是楼主数据量那么大一次性更新，很容易引起这个问题

iamclq · 发表于 2008-9-15 20:39

原帖由 nyfor 于 2008-9-11 09:44 发表
谢谢, 增长了知识, 但是楼主依然没有说明在第一种情况下,
在 alter table T1 storage(buffer_pool keep);
之后的速度怎么样, 是否第二种方法的按 rowid 排序取到了非常重要的作用.

keep池只是用于缓存频繁需要的数据而已，如果楼主使用rowid排序的话，每个块只需要读入一次就可以了，这与使用不使用keep没有多大关系。

iamclq · 发表于 2008-9-15 20:45

原帖由 棉花糖ONE 于 2008-9-11 11:30 发表

别这么肯定,能举个例子吗

order by rowid后块中的数据都是连续更新的，而不是分散更新，当然比之前分散更新的要块。

比如你更新一个块上面的10和20这两条记录，如果没有使用 rowid的话，那么这两条记录就不一定会排序在一起，因此，当你更新10记录后，假设块被换出了，而你更新20记录时又要把块读进来。

相反地，用了 rowid 后10和20这两条记录就会先后更新，这样就不存在相同块被多次读入内存的情况。

至于 keep pool 有没有作用，我想如果没有使用 rowid的情况下作用是很明显的，因为它减少了块被换出的可能性；如果是使用rowid的情况，因为更新的块只要读入一次后就不要了，所以影响不明显，甚至毫无作用可言。

以上见解，请多指教。

yaocf · 发表于 2008-9-16 15:35

个人之见，请各位指正

1.用keep 对数据读取起了作用，缓存了源数据,
看法：oracle是不是很聪明地只载入用到的6G，依次序加载数据？应该是，但cache buffer 太大了，6G差不多10%的数据，对冷数据没有影响，处理速度会很快，到热点数据影响很大，会引起问题，对条带化的存储，问题也表现成散开了，定期程序死了
方法：减少 keep buffer =100M
或用T1.id2 分段取出更新，类似分页原理

问题：为什么不同时keep T1/T2呢？

2.order by 我觉得是在写数据库是起了作用，更新一个地方，不用跑很多地方做一点事情，事情集中在一块完成!
看法：我猜测这个应用是个交易应用，你用1000 commit,是怕影响前台，对已经cache的数据处理量，一定可以加大 batch commit 10000 合适不？
你的机器性能能足够保证这个batch commit.

方法：加大batch commit. 以保证读取一批，处理一批，保存一批，流程匹配、干净利落

请高人拍砖!

ljianmao · 发表于 2008-9-18 14:28

学习中

fromeast · 发表于 2008-9-18 17:12

原帖由 yaocf 于 2008-9-16 15:35 发表
个人之见，请各位指正

1.用keep 对数据读取起了作用，缓存了源数据,
看法：oracle是不是很聪明地只载入用到的6G，依次序加载数据？应该是，但cache buffer 太大了，6G差不多10%的数据，对冷数据没有影响，处理速度会很快，到热点数据影响很大，会引起问题，对条带化的存储，问题也表现成散开了，定期程序死了
方法：减少 keep buffer =100M
或用T1.id2 分段取出更新，类似分页原理

问题：为什么不同时keep T1/T2呢？

2.order by 我觉得是在写数据库是起了作用，更新一个地方，不用跑很多地方做一点事情，事情集中在一块完成!
看法：我猜测这个应用是个交易应用，你用1000 commit,是怕影响前台，对已经cache的数据处理量，一定可以加大 batch commit 10000 合适不？
你的机器性能能足够保证这个batch commit.

方法：加大batch commit. 以保证读取一批，处理一批，保存一批，流程匹配、干净利落

请高人拍砖!