log file sync(日志文件同步)等待事件具有一個參數(shù):buffer#。在Oracle Database 10g中，這種等待事件位于Commit等待下面。當處理log file sync等待事件時，注意下面的思想：
◎ log file sync 等待時間和事務(wù)中指(提交或回滾)相關(guān)
◎ 當進程在log file sync事件上花費大量時間時，這通常表明過多的提交或短事務(wù)。
常見的原因、診斷和動作
Oracle 在SGA中的日志緩沖區(qū)中記錄事務(wù)和塊的改變，這是成為生理日志(physiological logging)的方法。通過以各種時間進度將內(nèi)容寫入到日志文件，LGWR進程負責在日志緩沖區(qū)中留出空間。
觸發(fā)LGWR進程的條件有：
1. 用戶提交
2. 有1/3重做日志緩沖區(qū)未被寫入磁盤
3. 有大于1M的重做日志緩沖區(qū)未被寫入磁盤
4. 3秒超時
5. DBWR 需要寫入的數(shù)據(jù)的SCN大于LGWR記錄的SCN，DBWR 觸發(fā)LGWR寫入。
觸發(fā)DBWR進程的條件有：
1. DBWR超時，大約3秒
2. 系統(tǒng)中沒有多余的空緩沖區(qū)來存放數(shù)據(jù)
3. CKPT 進程觸發(fā)DBWR
LGWR是負責把Redo Log buffer寫入Redo file的進程，當這個進程啟動的時候，會把redo buffer里已經(jīng)有的redo record寫入redo file，而當用戶commit或者rollback的時候，會觸發(fā)這個進程，從而保證用戶的提交的數(shù)據(jù)安全，只有寫入到redo file，才能保證這個操作是可以恢復(fù)的。
只有當某個事務(wù)所產(chǎn)生的重做記錄全部被寫入重做日志文件之后，oracle才認為這個事務(wù)已經(jīng)成功提交.重做記錄也可能會在事務(wù)提交之前就寫入重做日志文件.
LGWR進程在開始寫入下一個重做日志文件之前，必須確認這個即將被覆蓋的重做日志文件已經(jīng)完成如下工作：
* 如果數(shù)據(jù)庫處于非歸檔模式,已寫滿的重做日志文件在被覆蓋之前，其中所有重做記錄所對應(yīng)的事務(wù)的修改
操作結(jié)果必須已經(jīng)全部被寫入到數(shù)據(jù)文件中
* 如果數(shù)據(jù)庫處于歸檔模式,已寫滿的重做日志文件在被覆蓋之前，不僅要對應(yīng)所有事務(wù)的修改操作結(jié)果全部被 寫入到數(shù)據(jù)文件中，還需要等待歸檔進程完成對它的歸檔操作
由用戶提交和回滾初始化的寫入稱為同步寫入；其余的寫入成為后臺寫入。log file sync
等待只和同步寫入有關(guān)。換句話說，用戶進程可能正在處理一個大型的事務(wù)并生成許多觸發(fā)LGWR以執(zhí)行后臺寫入的大量重做條目，但用戶會話從來不需要等待后臺寫入的完成。然而，一旦用戶會話提交或回滾它的事務(wù)且_WAIT_FOR_SYNC參數(shù)是TRUE時，進程提交LGWR并在log file sync事件上等待LGWR將當前重做條目(包括提交標記)刷新到日志文件。在這種日志同步期間，LGWR進程在log file parallel write事件上等待同步寫入的完成，同時用戶會話在log file sync事件上等待同步進程的完成。
一旦進程進入log file sync等待，就有兩種可能性。
一種可能性是LGWR在日志同步完成時提交前臺進程時。
另一種情況是在等待已超時的時候(一般在1秒內(nèi))，在這個時刻，前臺進程檢查當前日志SCN(System Change Number,系統(tǒng)改變號)，確定它的提交是否已經(jīng)傳遞到磁盤。如果是的話，進程繼續(xù)處理，否則進程就重新進入等待。
高log file sync等待事件的3個主要原因。
①．高提交頻率
解決方法是簡單的消除不必要的提交，事務(wù)是工作單元。工作單元應(yīng)該是全部成功或全部失敗。
②．緩慢的I/O子系統(tǒng)
較高的IO吞吐良可以改善log file sync和log file parallel write事件的平均等待時間。頻繁的提交會弄亂數(shù)據(jù)庫布局和IO子系統(tǒng)。解決辦法是將日志文件放裸設(shè)備上或綁定在RAID 0或RAID 0+1中，而不是綁定在RAID 5中。
③．過大的日志緩沖區(qū)
過大的日志緩沖區(qū)也可能延長log file sync等待。大型的日志緩沖區(qū)減少后臺寫入的數(shù)量，允許LGWR變得懶惰，并導致更多的重做條目堆積在日志緩沖區(qū)中。同時可以調(diào)整參數(shù)_LOG_IO_SIZE參數(shù)，其默認值是LOG_BUFFER的1/3或1MB，取兩者之中較小的值。換句話說，你可以具有較大的日志緩沖區(qū)，但較小的_LOG_IO_SIZE將增加后臺寫入，從而減少log file sync的等待時間。
注意：
你必須絕對不將參數(shù)_WAIT_FOR_SYNC設(shè)置為FALSE，即使是在一個開發(fā)數(shù)據(jù)庫或測試數(shù)據(jù)庫中，因為不能保證提交的事務(wù)在實例失敗時可以恢復(fù)。人們使用這種特性來避開基準測試。
一般情況下，log file sync等待是非常頻繁的時間。它非常簡短，終端用戶一般不會注意
到它。然而，許多這樣的事件可能產(chǎn)生較長的響應(yīng)時間并在v$system_event和v$session_wait
視圖中獲得顯著的等待統(tǒng)計。使用下面的查詢來找到當前的會話，這些會話從登陸開始就花費大量的處理時間在log file sync事件上等待。
Log file parallel write
log file parallel write 事件是LGWR進程專屬的等待事件，發(fā)生在LGWR將log_buffer中的重做日志信息寫入聯(lián)機重做日志文件組的成員文件，LGWR在該事件上等待該寫入過程的完成。
該事件等待時間過長，說明日志文件所在磁盤緩慢或存在爭用。
從兩個方面入手解決：
（1）將日志文件組放置到高速I/O磁盤上。
（2）盡可能的降低重做數(shù)量：
—盡可能使用Nologging選項，包括create table...as select...操作
—熱備份可能創(chuàng)建大量的重做信息，所以熱備份應(yīng)該在非高峰時間運行，并且盡可能將表空間排除在熱備份模式外
