重做产生于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日志，会造成此等待
