log file sync(日志文件同步) 与 Log file parallel write 等待事件
log file sync(日志文件同步)等待事件具有一个参数:buffer#。在Oracle Database 10g中，这种等待事件位于Commit等待下面。当处理log file sync等待事件时，注意下面的思想：
???? ◎ log file sync 等待时间和事务中指(提交或回滚)相关
???? ◎ 当进程在log file sync事件上花费大量时间时，这通常表明过多的提交或短事务。
?
触发LGWR进程的条件有：
? 1. 用户提交
? 2. 有1/3重做日志缓冲区未被写入磁盘
? 3. 有大于1M的重做日志缓冲区未被写入磁盘
? 4. 3秒超时
? 5. DBWR 需要写入的数据的SCN大于LGWR记录的SCN，DBWR 触发LGWR写入。
触发DBWR进程的条件有：
?1. DBWR超时，大约3秒
?2. 系统中没有多余的空缓冲区来存放数据
?3.?CKPT 进程触发DBWR
?
???? 由用户提交和回滚初始化的写入称为同步写入；其余的写入成为后台写入。log file sync
等待只和同步写入有关。换句话说，用户进程可能正在处理一个大型的事务并生成许多触发LGWR以执行后台写入的大量重做条目，但用户会话从来不需要等待后台写入的完成。然而，一旦用户会话提交或回滚它的事务且_WAIT_FOR_SYNC参数是TRUE时，进程提交LGWR并在log file sync事件上等待LGWR将当前重做条目(包括提交标记)刷新到日志文件。在这种日志同步期间，LGWR进程在log file parallel write事件上等待同步写入的完成，同时用户会话在log file sync事件上等待同步进程的完成。
?
一旦进程进入log file sync等待，就有两种可能性。
一种可能性是LGWR在日志同步完成时提交前台进程时。
另一种情况是在等待已超时的时候(一般在1秒内)，在这个时刻，前台进程检查当前日志SCN(System Change Number,系统改变号)，确定它的提交是否已经传递到磁盘。如果是的话，进程继续处理，否则进程就重新进入等待。
?
高log file sync等待事件的3个主要原因。
???? ①．高提交频率
??????????? 解决方法是简单的消除不必要的提交，事务是工作单元。工作单元应该是全部成功或全部失败。
???? ②．缓慢的I/O子系统
????????较高的IO吞吐良可以改善log file sync和log file parallel write事件的平均等待时间。频繁的提交会弄乱数据库布局和IO子系统。解决办法是将日志文件放裸设备上或绑定在RAID 0或RAID 0+1中，而不是绑定在RAID 5中。
???? ③．过大的日志缓冲区
????????过大的日志缓冲区也可能延长log file sync等待。大型的日志缓冲区减少后台写入的数量，允许LGWR变得懒惰，并导致更多的重做条目堆积在日志缓冲区中。同时可以调整参数_LOG_IO_SIZE参数，其默认值是LOG_BUFFER的1/3或1MB，取两者之中较小的值。换句话说，你可以具有较大的日志缓冲区，但较小的_LOG_IO_SIZE将增加后台写入，从而减少log file sync的等待时间。
?
注意：
???? 你必须绝对不将参数_WAIT_FOR_SYNC设置为FALSE，即使是在一个开发数据库或测试数据库中，因为不能保证提交的事务在实例失败时可以恢复。人们使用这种特性来避开基准测试。
???? 一般情况下，log file sync等待是非常频繁的时间。它非常简短，终端用户一般不会注意
到它。然而，许多这样的事件可能产生较长的响应时间并在v$system_event和v$session_wait
视图中获得显著的等待统计。使用下面的查询来找到当前的会话，这些会话从登陆开始就花费大量的处理时间在log file sync事件上等待。
?
Log file parallel write
?
log file parallel write 事件是LGWR进程专属的等待事件，发生在LGWR将log_buffer中的重做日志信息写入联机重做日志文件组的成员文件，LGWR在该事件上等待该写入过程的完成。
该事件等待时间过长，说明日志文件所在磁盘缓慢或存在争用。
从两个方面入手解决：
（1）将日志文件组放置到高速I/O磁盘上。
（2）尽可能的降低重做数量：
—尽可能使用Nologging选项，包括create table...as select...操作??????????????????????????????????????????
—热备份可能创建大量的重做信息，所以热备份应该在非高峰时间运行，并且尽可能将表空间排除在热备份模式外
?
LGWR是负责把Redo Log buffer写入Redo file的进程，当这个进程启动的时候，会把redo buffer里已经有的redo record写入redo file，而当用户commit或者rollback的时候，会触发这个进程，从而保证用户的提交的数据安全，只有写入到redo file，才能保证这个操作是可以恢复的。??
?
只有当某个事务所产生的重做记录全部被写入重做日志文件之后，oracle才认为这个事务已经成功提交.重做记录也可能会在事务提交之前就写入重做日志文件.
LGWR进程在开始写入下一个重做日志文件之前，必须确认这个即将被覆盖的重做日志文件已经完成如下工作：
* 如果数据库处于非归档模式,已写满的重做日志文件在被覆盖之前，其中所有重做记录所对应的事务的修改
操作结果必须已经全部被写入到数据文件中
* 如果数据库处于归档模式,已写满的重做日志文件在被覆盖之前，不仅要对应所有事务的修改操作结果全部被 写入到数据文件中，还需要等待归档进程完成对它的归档操作
?
常见的原因、诊断和动作
???? Oracle 在SGA中的日志缓冲区中记录事务和块的改变，这是成为生理日志(physiological logging)的方法。通过以各种时间进度将内容写入到日志文件，LGWR进程负责在日志缓冲区中留出空间。
metalink上的解释：
"log file sync" Reference Note
When a user session(foreground process) COMMITs (or rolls back), the session's redo information needs to be flushed to the redo logfile. The user session will post the LGWR to write all redo required from the log buffer to the redo log file. When the LGWR has finished it will post the user session. The user session waits on this wait event while waiting for LGWR to post it back to confirm all redo changes are safely on disk.
This may be described further as the time user session/foreground process spends waiting for redo to be flushed to make the commit durable. Therefore, we may think of these waits as commit latency from the foreground process (or commit client generally).
See Reducing Waits section below for more detailed breakdown of this wait event.
("log file sync" applies to ROLLBACK/UNDO in that once the rollback/undo is complete the end of the rollback/undo operation requires all changes to complete the rollback/undo to be flushed to the redo log)
可见log file sync是发生于commit之后的,而且从内容上看应该包含lgwr把log_buffer写入redolog.也就是说log file sync出现肯定会有与之对应log file parallel write出现，那为什么我看到的log file sync的次数要大于log file parallel write的次数呢？
此等待事件用户发出提交或回滚声明后,等待提交完成的事件,提交命令会去做日志同步,也就是写日志缓存到日志文件， 在提交命令未完成前,用户将会看见此等待事件,注意,它专指因提交,回滚而造成的写缓存到日志文件的等待.当发生此等待事件时,有时也会伴随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,而是应用程序过多的提交造成的.
?
ok~总结一下~
1.是不是只要有数据库操作就会有相应的等待时间？又没有可能因为数据库运行良好没有等待事件？
比如lgwr写日志的时候，会不会因为速度“足够快”而不产生log file parallel write等待？
2.log file sync 和 log file parallel write到底是什么关系？
log file sync 是不是只有在user commit和dbwr触发时才会产生？
3.log file sync出现是是不是肯定会伴随lgwr的触发？
谁能解释这3个问题呀？
?
我的理解：
1、不是，等待时间总是会有的，只是一种自我标识的机制。数据库运行状态的良好，依然会有，只是量的大小和影响大小而已。
lgwr写日志的时候，速度“足够快”也产生log file parallel write等待，除非快的量变引起了质变。。。
2、log file sync 是为了等lgwr，此时lgwr等 log file parallel write，io完成后lgwr结束等待，返回给user process，user结束log file sync等待。
Log file parallel write
This is the main event waited while writing the redo records to the current log file. The call to write the log buffer is only made in LGWR, and the write operation is parallelized per physical disk. However, the wait is not over until the last redo buffer is sent to the disk.
Log file sync
When a request is made to sync, the write by LGWR includes all the redo up to the specific RBA and the redo pointed to by that RBA that is not already on disk. The time it takes for LGWR to complete the write and then post the requestor is the log file sync wait event. Each user COMMIT or ROLLBACK must sync the redo with an infinite RBA, forcing a complete flush of the log buffer to the redo log file.
3、log file sync肯定会伴随lgwr的触发
