log file sync(日誌檔案同步) 與 Log file parallel write 等待事件

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以執行後臺寫入的大量重做條目，但使用者會話從來不需要等待後臺寫入的完成。然而，一旦使用者會話提交或回滾它的事務且_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...操作                                          
—熱備份可能建立大量的重做資訊，所以熱備份應該在非高峰時間執行，並且儘可能將表空間排除在熱備份模式外