首页 » ORACLE » 利用rowid快速在线更新海量数据

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

今天 在pub上看到这个以前很老的贴子,颇具争议,转过来分享一下

转帖 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)

另一位网友的跟贴

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;
/

打赏

目前这篇文章有1条评论(Rss)评论关闭。

  1. Leeanna Joshlin | #1
    2011-12-21 at 05:27

    With havin so much content and articles do you ever run into any issues of plagorism or copyright infringement? My site has a lot of unique content I’ve either authored myself or outsourced but it looks like a lot of it is popping it up all over the web without my agreement. Do you know any methods to help reduce content from being ripped off? I’d definitely appreciate it.