1. 程式人生 > >log file sync(日誌檔案同步) 與 Log file parallel write 等待事件

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 synclog file parallel write事件的平均等待時間。頻繁的提交會弄亂資料庫佈局和IO子系統。解決辦法是將日誌檔案放裸裝置上或繫結在RAID 0RAID 0+1中,而不是繫結在RAID 5中。.過大的日誌緩衝區過大的日誌緩衝區也可能延長log file sync等待。大型的日誌緩衝區減少後臺寫入的數量,允許LGWR變得懶惰,並導致更多的重做條目堆積在日誌緩衝區中。同時可以調整引數_LOG_IO_SIZE引數,其預設值是LOG_BUFFER1/31MB,取兩者之中較小的值。換句話說,你可以具有較大的日誌緩衝區,但較小的_LOG_IO_SIZE將增加後臺寫入,從而減少log file sync的等待時間。

注意:你必須絕對不將引數_WAIT_FOR_SYNC設定為FALSE,即使是在一個開發資料庫或測試資料庫中,因為不能保證提交的事務在例項失敗時可以恢復。人們使用這種特性來避開基準測試。一般情況下,log file sync等待是非常頻繁的時間。它非常簡短,終端使用者一般不會注意到它。然而,許多這樣的事件可能產生較長的響應時間並在v$system_eventv$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...操作                                          
—熱備份可能建立大量的重做資訊,所以熱備份應該在非高峰時間執行,並且儘可能將表空間排除在熱備份模式外