相关redo的等待事件 (转)

相关重做的等待事件
  一，下面共描述了12个直接相关日志的等待事件，但只有前面几个是值得注意的.
  1,log file parallel write
    当日志缓存到日志文件时,这是一个主要的等待事件.虽然这个时间的名字中有"并行"(parallel)字样,但即使日志缓存并没有使用并行写,因日志缓存的写出而造成的等待仍然是此等待事件.
    我们可以通过v$system_event来了解下某一个阶段内,此等待事件的平均等待时间.通过此时间值,来评估我们的日志I/O是否正常.有资料介绍当log file parallel write的平均等待时间大于10毫秒时.有可能就表明着日志的吞吐量缓慢.我认为这只是一个参考值,在不同的系统上要根据不同的情况来决定.记录一些在正常情况下log file parallel write等待事件的平均等待时间,当出现问题后,以此时间作为是否有问题的标准.这种方法也是可取的.
    当日志I/O确实有问题时,减少重做产生的数量,确实能够缓解log file parallel write的等待时间.但有时,重做信息的数量是无法减少的.根据情况,将日志I/O转移到更快速的磁盘上,也是解决问题的方法之一.
    日志缓存的大小,有时候也会对此等待事件产生影响.如果你的日志缓存更大,会降低LGWR刷新缓存到磁盘的次数,增大日志的缓存,也会有助于缓解此等待事件.但过大的日志缓存,有可能会造成LGWR间歇性的拥堵.因为LGWR被触发的条件之一是日志缓存满1/3,如果日志缓存过大,1/3的日志缓存数量可能过多,每次LGWR被触发,不得不写大量数据,这造成LGWR间歇性的停顿与拥堵,这也会增加此等待事件的等待时间.我们可以通过设置隐藏参数_log_io_size来改变日志缓存满1/3才触发LGWR的阙值.通过设置此参数,我们即可以拥有较大的日志缓存,又避免了LGWR间歇性的停顿或拥堵.
    我没有在生产库中使用过这个参数,因为他毕竟是一个隐藏参数.虽然据说他不会带来什么bug.在我的测试机上,通过调节这个参数,确实可以对性能略有提升.但这些都是为数据库的"微调".不可能带来大幅度的性能提升.
    LGWR 在刷新缓存时,需要redo allocation和redo writing闩,并且LGWR需要等待一些redo copy 闩的完成.因此,如果这些闩的争用较高,则不要减少_log_io_size此隐藏参数,因为减少它,将会使LGWR更为频繁的刷新缓存.这会进一步加剧这3个闩的争用.减缓LGWR完成工作的速度.
**小小结:日志缓存到底应该设置为多大??_log_io_size参数的值应该定为多少??这没有一个统一的标准,只有通过多做测试才能决定.
 
  2,log file sync
    此等待事件用户发出提交或回滚声明后,等待提交完成的事件,提交命令会去做日志同步,也就是写日志缓存到日志文件， 在提交命令未完成前,用户将会看见此等待事件,注意,它专指因提交,回滚而造成的写缓存到日志文件的等待.当发生此等待事件时,有时也会伴随log file parallel write.因为此等待事件将会写日志缓存，如果日志的I/O系统较为缓慢的话,这必将造成log file parallel write 等待.当发生log file sync等待后,判断是否由于缓慢的日志I/O造成的,可以查看两个等待事件的等待时间,如果比较接近,就证明日志I/O比较缓慢或重做日志过多,这时,造成log file sync的原因是因为log file parallel write,可以参考解决log file parallel write的方法解决问题,如果log file sync的等待时间很高,而log file parallel write的等待时间并不高,这意味着log file sync的原因并不是缓慢的日志I/O,而是应用程序过多的提交造成的.
 
  当一个用户提交(commits)或者回滚(rollback),session的redo信息需要写出到redo logfile中。用户进程将通知LGWR执行写出操作,LGWR完成任务以后会通知用户进程.这个等待事件就是指用户进程等待LGWR的写完成通知.对于回滚操作，该事件记录从用户发出rollback命令到回滚完成的时间.
如果该等待过多，可能说明LGWR的写出效率低下，或者系统提交过于频繁.针对该问题，可以关注:
log file parallel write等待事件
user commits,user rollback等统计信息可以用于观察提交或回滚次数
解决方案:
1. 提高LGWR性能，尽量使用快速磁盘，不要把redo log file存放在raid 5的磁盘上。
2. 使用批量提交。
3. 适当使用NOLOGGING/UNRECOVERABLE等选项。
可以通过如下公式计算平均redo写大小：
avg.redo write size = (Redo block written/redo writes)*512 bytes
如果系统产生redo很多，而每次写的较少，一般说明LGWR被过于频繁的激活了.可能导致过多的redo相关latch的竞争,而且Oracle可能无法有效的使用piggyback的功能.

  
  
  
  3,log buffer space
    服务器进程生成重做记录的速度快过LGWR写出重做记录的速度,因而发生等待.日志I/O缓慢是log buffer space等待的主要原因之一.还有一点,如果日志缓存区过小,也容易出现此等待事件.将日志缓存设置的大一些,对于缓解此事件的等待会有帮助.但是,过大的日志缓存,又会降低LGWR刷新缓存的频率,这可能会使提交时必须刷新的缓存数量增多.从而造成log file sync等待.日志缓存具体应该设置为多大,这就多进行测试咯.不同的环境下,不可能有一个标准.为了缓解log buffer space等待事件,将日志缓存调节的比较大之后,可以通过_log_io_size参数来提高LGWR刷新缓存的频率.这样做既可以减少log buffer space的等待,也可以减少log file sync等待.但这样的隐藏参数 应该小心使用.
  4,log file switch(checkpoint incomplete)
    在日志切换时,会完成一个检查点操作,如果此检查点完成的过于缓慢,就会造成此事件的等待,检查点为什么会缓慢呢?可能是buffer cache太大因此容纳的脏块太多,DBWR进程太少,调整检查点频率的参数设置频率太低等原因造成的.
  5,log file switch(archiving needed)
    在日志切换时,下一日志文件还没被归档完成,此时所有的数据库DML操作都停止下来,等待下一日志文件可用,至于原因,很简单,归档进程太慢或日志切换太快,再问为什么切换太快?日志文件太小或生成的重做太多.
  6,log file switch(clearing log file)
    这发生在DBA发布alter system clear log file命令.且LGWR正需要切换到被清空的日志文件.等待时间是1秒.
  7,log file switch completion
    当一个日志文件满了,oracle要打开另一个日志文件,写完上一日志文件,准备好下一日志文件,这之间的等待就是此等待事件了,简单点说,就是为了完成日志文件切换而发生的等待.
  8,switch log file command
    执行日志文件切换命令的时候等待日志文件切换完成.超时时间为5秒.
  9,log switch/archive
    当DBA手动输入命令alter system archive log change时,可能会等待此事件.
  10,log file sequential read
    等待从日志文件中读,一般ARC进程会遭遇此事件,如果P3参数为1,证明等待发生在读日志文件头,否则,P3代表要读出的日志块的数量.
  11,log file single write
    日志文件写等待,注意,这里所指的写,并不是从日志缓存写到日志文件,这里的写并不涉及日志缓存,此事件只代表写日志文件头时发生的等待.有两种情况日志文件头被写:当添加新的成员文件或日志序列号增加.应对日志文件尽量使用裸设备.或避免将日志文件放在同一磁盘上,以减少此事件产生的可能.
  12,LGWR wait for redo copy
    LGWR将要写一组日志块,但它必须等待直到服务器进程完成任意当前的拷贝操作,这些拷贝操作影响将要被写出的缓存.

 

 

 

 

 

log buffer过大或者过小都有可能造成log file sync ？
过小的话，似乎要过于频繁刷新到磁盘，可以理解。
过大的话，为何会造成log file sync  ？

 

http://www.eygle.com/archives/2005/02/oeouredo_copy_l.html

一个进程产生redo时首先需要获得redo copy latch，获得了该latch以后才能把redo拷贝到Log Buffer中。
redo copy latch表明进程正在把redo拷贝入log buffer中，在此过程中，LGWR应该等待直到进程拷贝完成才能把目标Log buffer Block写入磁盘。

注意:LGWR进程必须获得所有的redo copy latch，然后才能将Log Buffer写入Log File.
redo copy latch获取以后，紧接着需要获取redo allocation latch ，分配redo空间，空间分配完成以后，redo allocation latch 即被释放，进程把PGA里临时存放的redo信息COPY入redo log buffer,COPY完成以后,redo copy latch 释放。

在完成redo copy以后，Process可能需要通知LGWR去执行写出（如果redo copy是commit等因素触发的）。
为了避免LGWR被不必要的post，进程需要先获取redo writing latch去检查LGWR是否已经激活或者已经被Post。如果LGWR已经激活或被Post，redo writing latch将被释放。

如果redo writing latch竞争过多,可能意味着你的提交过于频繁.
通过系统统计信息或statspack可以获得这些信息，具体参考:Statspack之十四-"log file sync" 等待事件

在执行redo copy的过程中，进程以log file sync事件处于等待。

当进程从log file sync中等待中醒来以后，进程需要重新获得redo allocation latch检查是否相应的redo已经被写入redo log file，如果尚未写入，进程必须继续等待

如果过小就是第一种情况 写的太频繁 导致等待
如果过大就是第二种情况 写的过多   时间长  导致等待

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/7532565/viewspace-586773/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/7532565/viewspace-586773/