richard的專欄（[email protecte
1、Log File Sync是從提交開始到提交結束的時間。Log File Parallel Write是LGWR開始寫Redo File到Redo File結束的時間。明確了這一點，可以知道，Log file sync 包含了log file parallel write。所以，log file sync等待時間一出，必先看log file parallel write。如果log file sync平均等待時間（也可稱為提交響應時間）為20ms，log file parallel write為19ms，那麼問題就很明顯了，Redo file I/O緩慢，拖慢了提交的過程。
2、 Log File Sync的時間不止log file parallel write。伺服器程序開始提交，到通知LGWR寫Redo，LGWR寫完Redo通知程序提交完畢，來回通知也是要消耗CPU的。除去來回通知 外，Commit還有增加SCN等等操作，如果log file sync和log file parallel write差距很大，證明I/O沒有問題，但有可能是CPU資源緊張，導致程序和LGWR來回通知或其他的需要CPU的操作，得不到足夠的CPU，因而產 生延遲。這 種情況下要看一下CPU的佔用率、Load，如果Load很高、CPU使用率也很高，哪就是由於CPU導致Log file sync響應時間加長。這種情況下，資料庫通常會有一些併發症，比如Latch/Mutex的競爭會比平常嚴重些，因為CPU緊張嗎，Latch /Mutex競爭一些會加巨的。
3、 log file sync和log file parallel write相差很大，但CPU使用率也不高，這種情況比較少見，這就屬於疑難雜症範疇了。I/O也很快，CPU也充足，log fie parallel write響應時間很短，但log file sync響應時間確很大。這是最難定位的情況，可以全面對比下Redo相關資料(v$sysstat中的資料）、Redo相關Latch的變化情況。比 如，redo synch time的平均響應時間，不是每次redo synch time都有提交，但每次提交必有redo synch time。如果redo synch time嚮應快，而log file sync慢，則說明Lgwr和程序的互相通知階段出了問題。還有redo entries，這個Redo條目數，真正含意是程序向Log Buffer中寫Redo的次數。redo log space wait time、redo log space requests資料和Log Buffer Space等待事件也要關注下。Log Buffer的大小通常不會影響Log File Sync，但通過Log Buffer的變化，可以瞭解Redo量的變化。關於Log Buffer對Log File Sync的影響，在新IMU機制下，Redo資料先在共享池中，提交時傳到Log Buffer中，如果這時有等待，等待時間是Log Buffer Space。從Log Buffer到磁碟，等待事件才是log file sync。老機制下也一樣，Log Buffer之前的等待是log buffer space，log buffer之後的等待才是log file sync。
4、控制檔案I/O有可能影響log file sync。此問題還沒來得及深入研究，只是以前在阿里的資料庫中觀察到這一現象。
5、Log File Sycn和Buffer Busy Waits。沒 有直接關係。是其他原因，比如Redo相關的Latch，導致了Log File Sync和Buffer Busy Waits同時出現。此時Log File Sync和Buffer Busy Waits都不是原凶，真正的原凶是Log Buffer訪問效能下降。
6、以同步模式向遠端DataGuard傳送Redo，也會導致Log File Sync。