oracle log file switch (checkpoint incomplete) 等待事件

這個等待事件在繁忙的系統很容易出現，要想解決這個問題就得了解爲啥會出這個問題。

說到redolog就必須得說下oracle 日誌體系，oracle 默認必須有3組日誌，每組日誌是循環寫的，oracle在寫入數據的時候確定是先寫日誌後寫數據文件，一旦寫日誌出現了等待，那麼系統確定會很是慢，影響很大。redolog日誌比較特殊，它是順序寫入的，因此oracle官方也不建議把redolog方在asm條帶化存儲中。咱們知道在文件系統層面的順序寫對應磁盤就是隨機IO，因此SSD盤對隨機IO提高效果不大，條帶化的存儲對順序寫的文件效果也不大。

回到oracle數據庫上來，若是數據庫開了歸檔，那麼一條數據從redlog buffer寫到redolog，這個過程期間也會產生等待，最典型的就是redolog sync 和redolog paralle write 。

 

Log File Sync是從提交開始到提交結束的時間。Log File Parallel Write是LGWR開始寫Redo File到Redo File結束的時間。  Log File Parallel Write 也會影響 Log File Sync。 這邊log file sync 平均等待時間是 1MS， 後文中Log File Parallel Write 也是1ms 所以判斷系統IO沒有問題。

 若是 此時Log File Parallel Write 平均等待時間件很高， 這種狀況通常是IO出問題了，致使log 寫到磁盤緩慢。 

 若是 Log File Sync的平均等待時間很長，可是 Log File Parallel Write 時間很短，這種狀況查通常檢查2點。

 

 1 commit的進程和lgwr以前經過CPU調度來協調的， 會不會CPU資源緊張致使協調過慢？ 若是是的。那就會伴隨邏輯讀高，塊忙， latch....等待事件反應CPU吃緊， 這份AWR報告中並無這樣的特徵。 另外host cpu idle 上面也沒有反應CPU吃緊。

2 若是日誌緩衝區過小，致使一次寫入的量很大，也會致使這種現象。

經過AWR報告，已經系統系統查詢並非以上幾點。

此時不妨停下來思考一下，什麼是log file switch (checkpoint incomplete)？

log file switch (checkpoint incomplete)指的是當redo須要向下一組redo group切換的時候，發現下組日誌是active的，也就是說下組日誌中對應的一些buffer cache中的髒塊還沒有寫入到數據文件中，所以必須等待這些髒塊被完畢後，才能夠複用下一組redo group。若是數據庫開了歸檔，那麼這時候這個日誌組必須得先寫歸檔才能被覆蓋，這個時候數據庫就處於假死狀態。

解決這個問題通常有幾個方法：

一、增長redolog group 數量；

二、增長dbwr的進程；

三、提升磁盤IO能力；