log file sync(日誌檔案同步)等待事件具有一個引數:buffer#。在Oracle Database 10g中，這種等待事件位於Commit等待下面。當處理log file sync等待事件時，注意下面的思想：◎ log file sync 等待時間和事務中指(提交或回滾)相關◎當程序在log file sync事件上花費大量時間時，這通常表明過多的提交或短事務。

常見的原因、診斷和動作
     Oracle 在SGA中的日誌緩衝區中記錄事務和塊的改變，這是成為生理日誌(physiological logging)的方法。通過以各種時間進度將內容寫入到日誌檔案，LGWR程序負責在日誌緩衝區中留出空間

觸發LGWR程序的條件有：
  1. 使用者提交
  2. 有1/3重做日誌緩衝區未被寫入磁碟
  3. 有大於1M的重做日誌緩衝區未被寫入磁碟
  4. 3秒超時
  5. DBWR 需要寫入的資料的SCN大於LGWR記錄的SCN，DBWR 觸發LGWR寫入。

觸發DBWR程序的條件有：
 1. DBWR超時，大約3秒
 2. 系統中沒有多餘的空緩衝區來存放資料
 3. CKPT 程序觸發DBWR

LGWR是負責把Redo Log buffer寫入Redo file的程序，當這個程序啟動的時候，會把redo buffer裡已經有的redo record寫入redo file，而當用戶commit或者rollback的時候，會觸發這個程序，從而保證使用者的提交的資料安全，只有寫入到redo file，才能保證這個操作是可以恢復的。  

只有當某個事務所產生的重做記錄全部被寫入重做日誌檔案之後，oracle才認為這個事務已經成功提交.重做記錄也可能會在事務提交之前就寫入重做日誌檔案.

LGWR程序在開始寫入下一個重做日誌檔案之前，必須確認這個即將被覆蓋的重做日誌檔案已經完成如下工作：
* 如果資料庫處於非歸檔模式,已寫滿的重做日誌檔案在被覆蓋之前，其中所有重做記錄所對應的事務的修改
操作結果必須已經全部被寫入到資料檔案中
* 如果資料庫處於歸檔模式,已寫滿的重做日誌檔案在被覆蓋之前，不僅要對應所有事務的修改操作結果全部被 寫入到資料檔案中，還需要等待歸檔程序完成對它的歸檔操作

由使用者提交和回滾初始化的寫入稱為同步寫入；其餘的寫入成為後臺寫入。

一旦程序進入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...操作                                          
—熱備份可能建立大量的重做資訊，所以熱備份應該在非高峰時間執行，並且儘可能將表空間排除在熱備份模式外