与log相关的等待事件及解决方法

author:skate
time:2009/10/11



一. log buffer的优化



日志块的都是按照顺序往里写，不存在更新日志块的以前的内容，同时每个日志块大小都很小，是
操作系统数据块的大小（一般为512k），所以几乎不会有多个进程抢同一个日志块的情况。其争用主要是进程由于
找不到可用的日志块而必须等待的情况。而我们知道LGWR负责释放脏的日志块从而提供可用日志块，
LGWR在日志缓冲区中的脏日志块超过1M或者超过日志缓冲区的1/3时就会启动，而且在将重做记录写入联机日志文
件时，都是按照顺序写入，不存在类似DBWR的随机写入，所以写入的速度是非常快的，除非硬盘
的I/O速度有很大的问题。



SQL > select total_waits,time_waited,average_wait,time_waited/total_waits as avg
2 from v$system_event where event = 'log file parallel write';
TOTAL_WAITS TIME_WAITED ***ERAGE_WAIT ***G
----------- ----------- ------------ ----------
314346633 129581305 0 .41222425



我们可以看到，***ERAGE_WAIT表示LGWR完成一次写入平均需要多少时间，是用等待时间除以等待次数得出的、
并四舍五入以后得到的平均值（***G是没有四舍五入以后的值）。如果***ERAGE_WAIT大于1，就表示硬盘的I/O比较慢。

和log相关的等待事件

1. log buffer space --日志缓冲区空间



当进程需要向日志缓冲区里拷贝重做记录时，发现没有足够的可用空间时，则必须等待log buffer space事件



log buffer space等待事件产生的原因：



1) 日志缓冲区尺寸太小。对于一个繁忙的批处理数据库系统里，一个太小的日志缓冲区（小于512K）会导致进程等待log buffer space。

2) LGWR进程太慢了，这也就是物理I/O速度过慢。可以通过检查log file parallel write等待事件的平均等待时间来判断，如果大于10毫秒，则说明LGWR过慢

消除log buffer space等待事件的方法：



可以通过增加日志缓冲区的尺寸或加快LGWR的进程（更快的磁盘）来减少log buffer space等待事件。



2. log file switch（包括下面三个详细等待事件）
log file switch(archiving needed)
log file switch(checkpoint incomplete)
log file switch(completion)



这个等待事件出现时通常是因为日志组循环写满以后，第一个日志归档尚未完成，出现该等待。出现该等待，可能表示io 存在问题



log file switch completion：表示进程正在等待日志切换完成。

log file switch (checkpoint incomplete)：当应用程序产生很多重做，然后由LGWR进程非常快得写日志文件并进行日志切换时，这时DBWR进程还没有把脏数据块写入磁盘以通知checkpoint结束时，这个时候产生log file switch (checkpoint incomplete)等待事件。

log file switch(archiving needed)：表示正等待归档



消除这个等待事件的方法：



1）. 可以考虑增大日志文件和增加日志组

2）. 移动归档文件到快速磁盘

3）. 调整log_archive_max_processes .



3.log file sync



当用户发出提交或回滚语句时会触发LGWR将重做记录写入联机日志文件，这种触发LGWR的方式叫做同步写（sync writes）触发，
而其他剩下的触发LGWR的方式叫做后台写（background writes）。log file sync等待事件只与sync writes有关，而log file
parallel write等待事件只与background writes有关。



此等待事件产生的原因：过于频繁的提交也正是log file sync等待事件出现的主要原因。而log file parallel write等待事件
则总是会出现的，只要LGWR开始刷新日志缓冲区，该进程就会等待log file parallel write等待事件，
是不可避免的，不用过多关注该等待事件



要减小log file sync的主要方法就是减少提交或回滚的次数。同时，过于频繁的提交不光会引起log file sync等待事件，产生
大量的重做日志，而且很有可能引起ora-01555：snapshot too old错误

消除此等待事件的方法：



如果应用程序已经确保了使用正确的频率进行提交，则还是发现很严重的log file sync等待事件，则比较常见的原因主要包括：



1) 联机日志文件放在一个很慢的磁盘上。可以用前面我们提到的log file parallel write的平均等待时间应该小于等于10个毫秒
来判断，磁盘速度是否过慢。



2) 联机日志文件与其他随机写入的文件放在了同一个磁盘上。从前面已经知道，联机日志文件都是顺序写入的。不能够将其与其
他随机写入的文件放在一起，需要存放在单个的磁盘上。



3) 联机日志文件放在了RAID 5的磁盘组里。RAID 5适合频繁的读取，比如数据仓库类的应用等，但不适合频繁写入。

最好能够将每个联机日志文件都放在单独的小的、转速快的磁盘上，与数据文件所在的磁盘阵列分开。

如果可以的话，最好不要使用文件系统来管理磁盘，直接使用RAW设备，直接交给oracle来管理磁盘。而且，oracle中最适合放在
RAW设备上的文件就是联机日志文件。

4.log file single write



该事件仅与写日志文件头块相关，通常发生在增加新的组成员和增进序列号时。



5.log file parallel write



从log buffer 写redo 记录到redo log 文件，主要指常规写操作(相对于log file sync)。如果你的Log group 存在多个组成员，
当flush log buffer 时，写操作是并行的，这时候此等待事件可能出现。



尽管这个写操作并行处理，直到所有I/O 操作完成该写操作才会完成(如果你的磁盘支持异步IO或者使用IO SL***E，那么即使只有
一个redo log file member,也有可能出现此等待)。



　　这个参数和log file sync 时间相比较可以用来衡量log file 的写入成本。通常称为同步成本率

二. 设置 log buffer大小：



在设置日志缓冲区时，可以参考下面这个建议的公式来计算：1.5×(平均每个事务所产生的重做记录大小×每秒提交的事务数量)。
首先先找到总事务量是多少：

select a.value as trancount from v$sysstat a,v$statname b
where a.statistic# = b.statistic# and b.name = 'user commits';



然后，找到系统总共的运行时间：

select trunc(sysdate - startup_time)*24*60*60 as seconds from v$instance;



第三，找到所产生的所有重做记录大小：

select value as redoblocks from v$sysstat where name = 'redo blocks written';

最后，我们可以分别计算公式中的值：平均每个事务所产生的重做记录大小= redoblocks/trancount；
每秒提交的事务数量=trancount/seconds。

这样，最后所建议的日志缓冲区的大小可以写为：

1.5* (redoblocks/trancount)* (trancount/seconds)



设置例子：
SQL> alter system set log_buffer=5242880 scope=spfile;





9i调整相关参数：

可以灵活改变各个参数：

alter system set shared_pool_size=数字M;
alter system set db_cache_size=数字M;
alter system set log_buffer=数字M;



---end---