重做产生于PGA,再由各个session的服务器进程将重做记录拷贝到SGA 的log buffer中,再由LGWR进程刷新到redo log文件中
重做产生于PGA,再由各个session的服务器进程将重做记录拷贝到SGA 的log buffer中,再由LGWR进程刷新到redo log文件中
涉及到的三个latch:
Redo copy latch
Redo allocation latch
Redo writing latch
Redo copy latch
redo copy latch的数量可以有多个,可以通过_log_simultaneous_copies参数来设定,,缺省值是两倍CPU的个数,
此latch保护日志缓存中的信息,主要用于从PGA拷贝重做到log buffer中,但是不允许对重做记录一边进行修改,
一边将重做记录写入磁盘。所以LGWR工作的时候,必须等待持有redo copy latch 的前台进程将要刷新的重做记录拷贝完毕
这里也就是说,LGWR从redo log buffer写到文件的时候,是无法写正在copy的redo log buffer,但是可以写不持有
Redo copy latch的log buffer。
Redo allocation latch
前台进程和LGWR都将持有该latch
Oracle把向log buffer中写缓存这样一个操作分做两个步骤:
1. 是先在log buffer中分配一块空间
2. 是向这块空间中实际的写入重做信息
当前台进行分配空间的时候,必须先持有该latch,但是该阶段该latch只有一个,所以前台进程这个时候会相互阻塞。
当LGWR进行刷新缓存时,持有该latch,当确定刷新的范围后,那么就会写到磁盘,写磁盘前会释放该latch
Redo writing latch
当日志缓存没空间分配时,前台进程必须通知LGWR刷新日志缓存,只有第一个得到此latch的进程通知LGWR,
用来阻止其他进程通知LGWR,通知后,马上释放该latch,不会一直占用。LGWR得到通知,持有该latch,
写入磁盘文件前释放该latch。
重做产生的流程:
1.先在PGA中生成重做记录,并计算出重做记录大小
2.由服务器进程申请redo copy latch如果成功的话继续
3.再去申请redo allocation,成功分配空间后
4.释放redo allocation
5.开始把PGA中的重做记录写往log buffer
6.记录写完后,释放redo copy latch
_log_io_size:如果使用的log buffer大小等于或者大于该值,那么就触发LGWR写磁盘,缺省大小为log buffer的1/3,上限值为1M
redo buffer等待事件:
LOG BUFFER SPACE:
redo copy的速度快于LGWR,造成free log buffer总是不够用
原因:
LOG BUFFER太小,总没有空间copy
LOG BUFFER太大,但是录入的太频繁
提高LGWR写的效率,以及磁盘的IO性能
log file parallel write
此等待事件是LGWR将log buffer写到在线日志文件,重用log buffer。
解决方法:
减少日志的生成(NOLOGGING)
减少日志组成员数
避免在备份模式下做大量的事务
尽量用最小的辅助日志模式(Supplemental Logging),如在LOGMINER下分析日志.
日志组成员分布在不同的物理磁盘上
不要将在线日志存放在RAID5上
尽量使用裸设备
Log file sync
事物提交时,一个进程创建一个重做记录,LGWR从log buffer写到磁盘,当再次发出commit,前面的LGWR还没有完成,会造成log file sync等待
原因:
过度频繁的提交
CPU使用过度
bug
如果log file sync接近log file parallel write,那么冲突可能是日志IO问题,如果远大于,则IO不是主要问题
Log file switch(checkpoint incomplete)
当日志切换的时候,要覆盖一个检查点未完成的的日志造成的等待
解决办法:
IO有严重问题,增加DBWR的效率,提高磁盘IO性能
增大日志文件
增加日志组
Log file switch (archiving needed)
如果是归档模式存在此等待,那就是归档的速度慢,可以调整归档日志所在磁盘的性能,调整log_archive_max_processes。
log file sequential read
当redo进行归档时,会顺序读取redo日志,会造成此等待