这两个星期忙于对开发部门提交的大批量单证数据操作语句进行优化处理。
要知道这些语句没有优化前需要在生产环境下运行接近100小时,这样的语句能拿到生产环境下运行吗?亏他们想得出来。
但是这样的数据改造又是是在必行,在开发部门没有dba的情况下,出于对数据库的负责,必须对语句进行优化。
优化有些分析思路就不写了,只写一个其中的语句优化结果和优化效果。
源语句逻辑为:
update /*+ bypass_ujvc parallel(vsmarkview)*/ (select t.printdate t_prindate,d.printdate d_printdate
from vsmark t, vsmarkdetail d
where t.visacode = d.visacode
and t.visaserialno = d.visaserialno
) vsmarkview
set t_prindate = d_printdate;
当然,考虑到修改数据量大,对回滚段,及可能造成锁这样的问题,开发部门还是由所了解,所以采用了存储过程分批提交的方式进行。尽管这样,执行时间需要12小时。
优化后的过程为
DECLARE
TYPE ARRROWID IS TABLE OF ROWID INDEX BY BINARY_INTEGER;
tbrows ARRROWID;
row PLS_INTEGER;
TYPE DPDATETYPE IS TABLE OF date INDEX BY BINARY_INTEGER;
DPDATE1 DPDATETYPE;
TYPE bidtype IS TABLE OF number INDEX BY BINARY_INTEGER;
bid1 bidtype;
cursor update_table is select /*+ parallel(t,8)*/ dbms_rowid.rowid_block_number(t.rowid) bid,t.rowid,d.printdate
from vsmark t, TPALL.vsmarkdetail d
where t.visacode = d.visacode
and t.visaserialno = d.visaserialno order by bid;
v_count int:=0;
BEGIN
open update_table;
loop
fetch update_table bulk collect into bid1,tbrows,DPDATE1 limit 100000;
FORALL row IN 1 .. tbrows.count()
update vsmark set printdate= DPDATE1(ROW) WHERE rowid = tbrows(row);
commit;
v_count:=update_table%rowcount;
insert into exec_time values(sysdate,'printdate',v_count);(实时监控更新记录数)
commit;
exit when update_table%notfound;
end loop;
close update_table;
END;
/
执行时间为不到1小时。
其他语句类似,个别语句需要构建临时数据,总共下来10个小时足以。可以分批晚上进行执行,减少对生产的影响。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/288166/viewspace-705052/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/288166/viewspace-705052/