log file sync
	1、事務過度的提交，即應用程式過度commit或者rollback。
		事務過度提交事務過度提交是引起log file sync等待事件的主要原因之一。預設情況下，當事務提交時，LGWR程式會將事務相關的日誌條目立即寫至redolog中，直到日誌寫成功之後才顯示提交成功。所以事務提交越頻繁，觸發LGWR程式寫操作越頻繁，引起log file sync等待時間的可能性越大。所以當由於事務過度提交引起log file sync等待事件時，最好的解決方法是修改應用，將小事務變成大事務。可在很多情況下，修改應用不是很簡單的事情，需要應用廠商配合。當應用廠商配合程度不足時，我們就需要在DB端想辦法了。所幸的是從Oracle 10g開始，Oracle推出了新的資料庫引數commit_write用於控制LGWR程式寫日誌操作，其預設值為空，表示wait和immediate。也可以將其線上修改（即引數值修改後不需要重啟資料庫就能生效）成nowait和batch，表示事務提交時，LGWR程式並不馬上將事務相關條目寫至日誌檔案中，而是非同步模式將相關條目批次（batch）寫至日誌檔案中。所以採用這種方法，在緩減了log file sync等待事件的同時，資料庫異常當機後可能會引起資料丟失，所以要引起注意！當然使用臨時表或者NOLOGGING選項，儘可能少產生redo日誌，也是解決log file sync等待事件的方法之一。
	2、儲存I/O資源緊張，導致lgwr程式寫速度緩慢。
		儲存I/O資源緊張LGWR程式寫redolog特徵是連續順序小I/O寫，儲存的IOPS能力對其影響最大。當儲存I/O資源緊張時，LGWR程式寫日誌的速度就受到明顯影響，從而出現log file sync等待事件。如果要確定是否是儲存I/O資源緊張導致log file sync等待事件，我們通常情況下只要檢查以下兩方面：

（1）檢查儲存的I/O資源是否緊張，如在AIX系統中可以透過topas命令觀察磁碟的繁忙程度，如圖一所示：

（2）檢查系統每次等待log file parallel write等待事件和log file sync等待事件的時間差，如果兩者時間接近，則說明儲存I/O資源緊張是引起log file sync等待事件的主要原因。log file parallel write等待事件和log file sync等待事件的關係如圖二所示： 我們可以透過V$EVENT_HISTOGRAM檢視觀察log file parallel write等待事件消耗時間的分佈情況，如下所示：

```
SQL> select event, wait_time_milli,wait_count from v$event_histogram where event = 'log file parallel write';

EVENT                   WAIT_TIME_MILLI  WAIT_COUNT
---------------------------------------------------
log file parallel write     1                22677
log file parallel write     2                  424
log file parallel write     4                  141
log file parallel write     8                  340
log file parallel write     16                1401
log file parallel write     32                 812
log file parallel write     64                 391
log file parallel write     128                 21
log file parallel write     256                  6
```

當由於儲存I/O資源緊張而導致log file sync等待事件時，我們可以採取以下措施：

1、如果有空閒的物理磁碟，且這些物理磁碟的I/O效能能滿足系統要求，那麼將logfile線上遷移至空閒物理盤中。如果空間允許，還可以考慮將資料庫的UNDO表空間線上遷移至其他盤，從而釋放I/O壓力。

2、如果線上日誌設定了多組member，為了減少LGWR寫日誌操作，可以考慮刪除其他member，只保留一組。

![](http://img.blog.itpub.net/blog/2022/10/11/e1a229b19c588d95.png?x-oss-process=style/bb)

圖一

![](http://img.blog.itpub.net/blog/2022/10/11/d044092c0cc8cb8e.png?x-oss-process=style/bb)

圖二
	3、CPU資源緊張，lgwr程式獲得不了響應的CPU時間片。
		CPU資源緊張主機CPU資源緊張從而導致LGWR程式獲得不了CPU時間片也可能導致log file sync等待事件。某系統由於主機CPU資源緊張，而出現較多的log file sync等待事件，CPU資源如圖一所示： 資料庫的AWR報告顯示log file sync等待比較嚴重，如圖二所示： 事實上，LGWR程式寫儲存的速度並不慢，log file parallel write等待事件每次才等待2ms，如圖三所示： 針對CPU資源緊張而導致log file sync等待事件，有以下幾種解決方案：

1、增加CPU資源，最佳化消耗CPU資源的語句，這是效果最為明顯的解決方法，但同時成本也較高。

2、在作業系統級別使用renice命令提交LGWR程式優先順序，如果存在多顆CPU，為減少LGWR程式輪詢CPU時間，可以將其繫結在某顆CPU上執行。

3、在資料庫級別設定隱含引數_high_priority_processes提高LGWR程式優先順序。_

![](http://img.blog.itpub.net/blog/2022/10/11/13f1038967b31d66.png?x-oss-process=style/bb)
			圖一

![](http://img.blog.itpub.net/blog/2022/10/11/c491d3f1e9dc51cd.png?x-oss-process=style/bb)

圖二

![](http://img.blog.itpub.net/blog/2022/10/11/306f11a874934565.png?x-oss-process=style/bb)

圖三
	4、RAC節點之間SCN同步。
		RAC節點之間SCN同步在RAC資料庫中為了一致性讀，需要將Commit SCN同步/傳播到所有的節點上。SCN同步/傳播的主要方法有兩種：Lamport SCN 和 immediate commit propagation。其中immediate commit propagation這種方式就也被稱為BOC（Broadcast On Commit）。

Oracle 10gR1 及以下版本預設使用Lamport SCN，Lamport SCN方式即一個節點上的commit SCN 不保證立刻同步/傳播到所有節點，也就是說可能延時同步/傳播，對於一些實時性要求高的RAC資料庫Lamport SCN方式是不可取的。如果希望commit SCN 立刻同步/傳播到所有節點，手動修改引數MAX_COMMIT_PROPAGATION_DELAY=1。從Oracle 10gR2開始預設使用immediate commit propagation (BOC)，即一個節點上的commit SCN 立刻同步/傳播到所有節點（受隱含引數_immediate_commit_propagation控制，預設為true）。immediate commit propagation (BOC)的原理如下：_

（1） user session 執行提交（commit），user session會通知LGWR程式將redo buffer中的資訊寫入到redo log file。

（2） LGWR程式收到user session通知後，將redo buffer中的資訊寫入redo log file，同時LGWR程式 將COMMIT SCN 同步/傳播給遠端的資料庫例項的LMS 程式。

（3） 遠端資料庫例項的LMS將commit SCN同步到本地SCN，然後通知commit例項的LMS程式，表示SCN 同步已經完成。

（4） 當commit 例項的LMS程式接收到所有遠端資料庫例項的LMS程式的通知後，commit 例項的LMS程式再通知本地的LGWR 所有節點SCN同步已經完成。

（5） LGWR程式 在完成了IO 操作和LMS程式通知後，LGWR程式通知user session commit 成功。user session在沒有收到LGWR程式通知前，一直處於等待log file sync。RAC節點之間SCN傳遞的指標可以在AWR報告中觀察，如圖一所示： 當log file sync等待事件是由於RAC節點之間SCN同步引起的，其解決方法如下：

1、檢查LMS程式數量是否足夠。

2、檢查系統CPU資源是否足夠。

3、檢查RAC節點之間的私有通訊是否正常。

4、設定隱含引數_immediate_commit_propagation為false，禁用immediate commit propagation特性。_

![](http://img.blog.itpub.net/blog/2022/10/11/2280a633561d7b11.png?x-oss-process=style/bb)
			圖一
	5、RAC節點之間CR塊傳遞。
		RAC節點之間CR塊傳遞Oracle為了保證Instance Recovery例項恢復機制，而要求每一個current block在本地節點local instance被修改後(modify/update) 必須要將該current block相關的redo 寫入到logfile 後（要求LGWR必須完成寫入後才能返回)，才能由LMS程式傳輸給其他節點使用。如圖一所示： 某客戶資料庫出現log file sync等待事件，正是由於這種機制引起的。AWR報告如圖二所示： 當出現這種情況時，其解決方法如下：

1、修改應用盡量減少跨節點取資料。

2、修改隱含引數_cr_server_log_flush為fasle（預設為true），關閉CR塊節點傳輸特性。

![](http://img.blog.itpub.net/blog/2022/10/11/4288c980fea7dcd7.png?x-oss-process=style/bb)

圖一

![](http://img.blog.itpub.net/blog/2022/10/11/dfc8a442012c1b1b.png?x-oss-process=style/bb)

圖二
	6、控制檔案爭用。
		控制檔案爭用LGWR程式寫日誌的同時會在控制檔案中記錄寫進度。當控制檔案爭用而出現enq: CF–contention等待事件時，前臺程式可能會出現LOG FILE SYNC等待。AWR報告部分資料如圖一所示： 由於LGWR程式寫日誌的過程中需要更新控制檔案。當RMAN操作比較頻繁時（如利用RMAN批次刪除歸檔)，伺服器程式也會更新控制檔案，所以多個會話同時更新控制檔案時可能會引起enq:CF–contention等待事件。當LGWR程式獲得不了CF鎖時，可能導致LOG FILE SYNC等待。這個案例再次表明了Oracle是一臺巨大的同步機器，看起來風馬牛不相及的東西，往往存在著相互因果關係。

![](http://img.blog.itpub.net/blog/2022/10/11/1bc3f3e51ecc91cb.png?x-oss-process=style/bb)

圖一

log file sync等待事件處理思路

相關文章