相关重做的等待事件

晶晶实验十二 相关重做的等待事件
  一，下面共描述了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,而是应用程序过多的提交造成的.
   
  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<SCN>时,可能会等待此事件.
  10,log file sequential read
    等待从日志文件中读,一般ARC进程会遭遇此事件,如果P3参数为1,证明等待发生在读日志文件头,否则,P3代表要读出的日志块的数量.
  11,log file single write
    日志文件写等待,注意,这里所指的写,并不是从日志缓存写到日志文件,这里的写并不涉及日志缓存,此事件只代表写日志文件头时发生的等待.有两种情况日志文件头被写:当添加新的成员文件或日志序列号增加.应对日志文件尽量使用裸设备.或避免将日志文件放在同一磁盘上,以减少此事件产生的可能.
  12,LGWR wait for redo copy
    LGWR将要写一组日志块,但它必须等待直到服务器进程完成任意当前的拷贝操作,这些拷贝操作影响将要被写出的缓存.