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

http://www.itpub.net/thread-1052077-1-1.html 最近一直在折腾大表的更新问题，今天终于有了突破。兴奋之余发个帖子跟大家分享一下心得，并且讨论一下是否还可能进一步提高处理速度。 问题是这样的：一张5亿条记录的表，没有分区。由于增加了一个冗余字段，需要根据另外一张表（4.8亿条）更新这个大表。下面是具体的描述： 环境：HP-UX 11i+Oracle9.2.0.8+RAID 要更新的表：T1 (id1 number, id2 number, curr_count number,.....)   --id1唯一  5亿条记录 >60GB 更新数据来源：T2 (id2 number, curr_count number)   --id2唯一  4.8亿 更新逻辑：T2中的每一条记录，都到T1中找到对应的记录（T2.id2=T1.id2），更新T1.curr_count=T2.curr_count 限制条件：只能在线更新（应用程序一直在访问这个表，所以不能用INSERT SELECT），不能占用太多系统资源，要求3天之内更新完毕。 原来的做法： declare   cursor cur_t2 is      select /*+ use_hash(T1,T2) parallel(T1,16) parallel_index(IX_T1_id2,16) */        T2.id2, T2.curr_count, T1.rowid row_id     from T1, T2     where T1.id2=T2.id2;   v_counter number; begin   v_counter := 0;   for row_t2 in cur_t2 loop     update T1 set curr_count=row_t2.curr_count        where rowid=row_t2.row_id;     v_counter := v_counter + 1;     if (v_counter>=1000) then       commit;        v_counter := 0;     end if;   end loop;   commit; end; / 问题：更新太慢，260 rows/s，全部更新完毕需要22天！ 经过调查发现是UPDATE语句执行的效率太低，进一步的跟踪发现，UPDATE至少90%的时间是在等待db file sequential read这个事件。按说都ROWID了，为什么还有这么多磁盘等待？再看disk reads，明白了，原来UPDATE语句产生了大量的物理读，当然慢了。想必T1表太大了，Data Buffer装不下，并且有其他的表跟它竞争，所以刚更新一条数据，从磁盘读取了一个数据块到内存，很快就被挤去出了，下次更新这个块上的其他数据时，还得再从磁盘读取。这样Data Buffer Cache的效率就很低，基本没有利用上。 怎么解决呢？最好是能按数据块的顺序更新，这样某个数据块里的第一行数据更新后，数据块内的其他行就不用再从磁盘里读取了（不太可能那么快就被挤出内存），物理读降低了，速度肯定能加快。可是怎样按数据块的顺序更新呢？我想到了ROWID的结构是data object number(6位字符串)+relative file number(3位字符串)+block number(6位字符串)+row number(3位字符串)，那么ROWID的顺序应该就是数据块的顺序了。于是我修改了PLSQL： alter table T1 storage(buffer_pool keep);    -- keep buffer pool size = 6GB declare   cursor cur_t2 is      select /*+ use_hash(T1,T2) parallel(T1,16) parallel_index(IX_T1_id2,16) */        T2.id2, T2.curr_count, T1.rowid row_id     from T1, T2     where T1.id2=T2.id2     order by T1.rowid;   v_counter number; begin   v_counter := 0;   for row_t2 in cur_t2 loop     update T1 set curr_count=row_t2.curr_count        where rowid=row_t2.row_id;     v_counter := v_counter + 1;     if (v_counter>=1000) then       commit;        v_counter := 0;     end if;   end loop;   commit; end; / alter table T1 storage(buffer_pool default); 这回更新的速度大为加快：10000 rows/s。分析跟踪文件表明db file sequential reads和磁盘读取变的很少。按照这个速度20个小时之内就能全部更新完了。 心得：处理的数据量并没有减少，只是改变一下处理的顺序，也可以极大地提高性能。 ==================================================================== *后记4：已上生产 *后记3：试验了KEEP的影响 (1)重新运行试验1（不order by rowid）      开始的语句改成：alter table T1 storage(buffer_pool keep);      处理速度：73~74行/秒 (2)重新运行试验2（order by rowid）：      开始的语句改成：alter table T1 storage(buffer_pool default);      处理速度：1万条/秒 结论：从本次测试可以印证先前的推断——把表的buffer_pool属性设为keep与否，对处理速度的影响很小，以至于可以忽略。处理速度加快的原因，是因为order by rowid，按块顺序处理数据，很大程度上减少了物理读。 *后记2：关于order by rowid的资料：   http://rdc.taobao.com/blog/dba/html/199_oracle_rowid_order.html    这篇文章说order by rowid导致大量的查询物理读。其实在本文第二个测试中也是这样的——CURSOR的打开时间比不ORDER BY ROWID时间要长，因为多了SORT。可是这样是值得的，因为后续有大量的UPDATE，节省的物理读是很可观的。 *后记1：修改了几处错误：   where T1.id1=T2.id2  => where T1.id2=T2.id2    parallel_index(IX_T2_id2,16) => parallel_index(IX_T1_id2,16)

--------------------------------------------

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

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

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

 

为什么order byrowid 能起作用。想象一下一个极端情况，你的db_cache_size 很小，只够放一个table的block. 如果不用order by rowid, 那么，连续的每个更新的语句更新的row很有可能不在同一个block里。
如有这样的数据：
row1 :block 1
row2 :block 2
row3 :block 3
row4 :block 1
row5 :block 2
row6 :block 3
row7 :block 2
row8 :block 1

那么，逐条更新的话，每更新下一条都会导致前一个block被挤出去，相当于总共8个物理读。
而如果order by rowid
则会是这样子：
row1 :block 1
row2 :block 1
row3 :block 1
row4 :block 2
row5 :block 2
row6 :block 2
row7 :block 3
row8 :block 3
逐条更新的话，相当于3个物理读。

当然，实际情况可能更复杂，但是，总体来说，除非原始数据本来就按rowid/blockid排序，或者内存足够大，否则，order by rowid 并逐条更新的确会降低物理读(db file sequential read) .

其实可以自己构造一个测试来验证，紧记两点：
1。 内存尽量小
2。 原更新source的顺序尽量不合rowid排序

 

 

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

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

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

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

以上见解，请多指教。

 

---------------------------------------

 

加一个for all, 效果会更好 declare maxrows number default 1000; row_id_table dbms_sql.Urowid_Table; currcount_table dbms_sql.number_Table;   cursor cur_t2 is      select /*+ use_hash(T1,T2) parallel(T1,16) parallel_index(IX_T1_id2,16) */        T2.id2, T2.curr_count, T1.rowid row_id     from T1, T2     where T1.id2=T2.id2     order by T1.rowid;   v_counter number; begin   v_counter := 0; open cur_t2; LOOP EXIT WHEN cur_t2%NOTFOUND; FETCH cur_t2 bulk collect into row_id_table,currcount_table limit maxrows; forall i in 1 .. row_id_table.count     update T1 set curr_count=currcount_table(i)        where rowid= row_id_table(i);       commit;    end loop; end; /

 

http://blog.csdn.net/leshami/article/details/7545597

BULK COLLECT批量绑定的示例

oracle学习之bulk collect用法

通过bulk collect减少loop处理的开销，使用BulkCollect提高Oracle查询效率

Oracle8i中首次引入了Bulk Collect特性，该特性可以让我们在PL/SQL中能使用批查询，批查询在某些情况下能显著提高查询效率。

采用bulk collect可以将查询结果一次性地加载到collections中。

而不是通过cursor一条一条地处理。

可以在select into,fetch into,returninginto语句使用bulk collect。

注意在使用bulk collect时，所有的into变量都必须是collections.