轉自：http://www.killdb.com/2014/04/20/log-file-sync-%E7%AD%89%E5%BE%85%E8%B6%85%E9%AB%98%E4%B8%80%E4%BE%8B%E5%AD%90.html

這是3月份某客戶的情況，原因是伺服器硬體故障後進行更換之後，業務翻譯偶爾出現提交緩慢的情況。我們先來看下awr的情況。

我們可以看到，該系統的load profile資訊其實並不高，每秒才21個transaction。先來看看top5events：

從top 5event，我們可以發現，log file sync的avg wait非常之高，高達124ms。大家應該知道，對於絕大多數情況

下，log file sync的平均等待時間是小於5ms的，這個值有點高的離譜。

我們知道，產生log file sync等待的原因有很多。關於log file sync，tanel Poder大神寫過一篇很牛的pdf，大家可以參考下。

這裡我主要引用大神的圖，來簡單描述產生log file sync的原因可能有哪些，首先我們來看下從前端程序提交到最後得到反饋時，以及中間處理的整個流程情況：

從上圖中，我們可以清楚的看到整個流程。這裡可以進行簡單的描述：

1、當user發起一個commit後；

2、前端程序（即Server 程序）會post一個資訊給lgwr程序，告訴它，你應該去寫redo buffer了。

3、當LGWR程序得到指示後，開始呼叫作業系統函式進行物理寫，在進行物理寫的這段時間內，會出現

log file parallel write等待。這裡或許有人會有疑問，為什麼12c之前只有一個lgwr程序，這裡卻是parallel

write呢？這裡需要說明一下，lgwr程序在將redo buffer中的資料寫出到log file檔案中時，也是以batch方式

程序的（實際上，dbwN程序也是batch的模式），有相關的隱含引數控制。

4、當LGWR完成wrtie操作之後，LGWR程序會返回一個資訊給前端程序（Server程序），告訴它，我已經寫完了，

你可以完成提交了。

5.   user 完成commit操作。

這裡補充一下，這是由於Oracle 日誌寫優先的原則，假設在commit之前redo buffer的相關entry資訊不立即寫到redo

log file中，那麼如果資料庫出現crash，那麼這是會丟資料的。

從上面的流程圖，我們其實也可以看到，log file sync和log file parallel write可以說是相互關聯的。換句話講，如果log file parallel write的時間很長，那麼必然導致log file sync等待時間拉長。

我們假設log file parallel write 等待很高，那麼著可能通常是物理磁碟IO的問題，如下：

我們從上圖可以發行，如果LGWR程序在完成IO操作的過程中時間過長，那麼將導致log file parallel write等待升高。

實際上，在整個當用戶發出commit到完成commit的過程中，涉及到很多環節，並不是僅僅只有物理IO會影響log file sync/log file parallel write。還有CPU也會影響Log file sync和log file parallel write。我們再來看個圖：

我們可以看到，上述流程中的4個環節都涉及到CPU的排程，如果在整個事務commit的過程中，系統CPU出現極度緊張，那麼這可能會導致LGWR程序無法獲得CPU，會進行排隊等待，顯然，這勢必將導致log file sync或log file parallel write等待

的升高。

備註：Oracle中還可以通過隱含引數_high_priority_processes 來控制程序獲取CPU的優先順序。在一個cpu相對缺乏的系統中，可以通過設定該引數來進行緩解。

最後我們再回到這個案例中來，客戶這裡的環境，我們是可以排除CPU問題。那麼最大的嫌疑可能就是儲存本身的問題，導致IO很慢，然而，實際上這也是可以排除的，大家其實應該注意到前面的Top 5 event了，log file parallel write的平均等待

時間並不高，如果是儲存IO問題，那麼這個event的平均等待時間應該是比較高才對。

我們可以看到log file sync和log file parallel write的waits都是差不多的。但是log file parallel write的avg wait time僅僅只有4ms，這是一個正常的值。也就是說可以我們排除儲存IO問題。

那麼問題是什麼呢 ？我們利用Oracle MOS提供的指令碼來查詢下log file sync和log file parallel write等待的分佈情況：

大家可以簡單的計算一下，其實log file sync和log file parallel write 等待事件，幾乎99%左右的平均等待時間都是

小於等於4ms的，這是屬於正常的情況；然而有少數的情況其等待時間是很長的，例如log file sync最高的單次等待

時間高達1秒，由於偶爾的等待很高，因此將整個log file sync的平均等待時間拉高了。

到最後，問題就比較清楚了，我認為這是由於主機和儲存之間的鏈路可能出現異常或不穩定導致。臨時的解決方法

將redo logfile 挪到本地磁碟，解決了該問題。

後記：經客戶後面確認，確實是儲存光纖線介面鬆了。 哈哈