Oracle中联机日志文件(online redo log)在大多平台上以512 字节为一个标准块。
(HPUX,Tru64 Unix上是1024bytes,SCO UNIX,Reliant UNIX上是2048bytes,而MVS,MPE/ix上是4096bytes,虽然以上许多UNIX已经不再流行,实际情况可以通过
select max(l.lebsz) log_block_size_kccle
from sys.x$kccle l
where l.inst_id = userenv(‘Instance’) 语句查询到)
LGWR后台进程写出REDO时未必能填满最后的当前日志块。举例而言,假设redo buffer中有1025字节的内容需要写出,则1025=512+512+1 共占用三个重做日志标准块,前2个标准块被填满而第三个标准块只使用了1个字节。在LGWR完成写出前,需要释放”redo allocation”闩,在此之前SGA中索引”redo buffer”信息的变量将指向未被填满块后面的一个重做块,换而言之有511字节的空间被LGWR跳过了,这就是我们说的redo wastage;我们可以通过分析v$sysstat动态视图中的redo wastage统计信息了解实例生命周期中的重做浪费量。
SQL> col name for a25 SQL> select name,value from v$sysstat where name like '%wastage%'; NAME VALUE ------------------------- ---------- redo wastage 132032
redo wastage的一个图示:
为什么要浪费这部分空间呢?实际上,这种做法十分有益于LGWR的串行I/O模式。redo wastage并不是问题或者Bug,而是Oracle故意为之的。当然过量的redo wastage也不是什么好事,一般是LGWR写出过于频繁的症状表现。9i以后很少有因为隐式参数_log_io_size过小而导致的LGWR过载了,如果在您的系统中发现redo wastage的问题不小,那么无限制地滥用commit操作往往是引起问题的罪魁祸首,减少不必要的commit语句,把commit从循环中移除都将利于减少redo wastage。
我们来看一下关于redo wastage的演示:
SQL> select distinct bytes/1024/1024 from v$log; BYTES/1024/1024 --------------- 50 /*确认联机日志文件大小为50MB*/ SQL> archive log list; /*确认数据库处于归档状态*/ Database log mode Archive Mode Automatic archival Enabled Archive destination /s01/arch SQL> set time on; 19:49:45 SQL> alter system switch logfile; /*切换日志,清理现场*/ System altered. 19:51:07 SQL> col name for a25 19:51:16 SQL> select name,value from v$sysstat where name in ('redo size','redo wastage'); NAME VALUE ------------------------- ---------- redo size 1418793324 redo wastage 88286544 /*演示开始时的基础统计值*/ 19:51:19 SQL> begin 19:52:10 2 for i in 1..550000 loop 19:52:10 3 insert into tv values(1,'a'); 19:52:10 4 commit; 19:52:10 5 end loop; 19:52:10 6 end; 19:52:11 7 / /*匿名块中commit操作位于loop循环内,将导致大量redo wastage*/ PL/SQL procedure successfully completed. 19:53:07 SQL> select name,value from v$sysstat where name in ('redo size','redo wastage'); NAME VALUE ------------------------- ---------- redo size 1689225404 redo wastage 112011352 /*频繁提交的匿名块产生了 1689225404-1418793324=257MB的redo,其中存在112011352-88286544=22MB的redo wastage*/ 19:53:14 SQL> begin 19:53:33 2 for i in 1..550000 loop 19:53:33 3 insert into tv values(1,'a'); 19:53:33 4 end loop; 19:53:33 5 commit; 19:53:33 6 end; 19:53:34 7 / /* 此匿名块中commit操作被移除loop循环中,批量修改数据后仅在最后提交一次*/ PL/SQL procedure successfully completed. 19:53:59 SQL> select name,value from v$sysstat where name in ('redo size','redo wastage'); NAME VALUE ------------------------- ---------- redo size 1828546240 redo wastage 112061296 /*稀疏提交的匿名块最后产生了1828546240-1689225404=132MB的重做,而redo wastage为112061296-112011352=48k*/
可能您会很奇怪前者不是只比后者多出22MB的redo浪费吗,为什么总的redo量差了那么多?
我们需要注意到commit本身也是要产生redo的,而且其所产生的还不少!就以上演示来看频繁提交的过程中,commit所占用的redo空间几乎接近一半(257-132-22)/257=40%,而每次commit的平均redo量为(257-132-22)*1024*1024/550000=196 bytes。
commit操作是事务ACID的基础之一,合理运用commit可以帮我们构建健壮可靠的应用,而滥用它必将是另一场灾难!
Leave a Reply