背景
客戶收到了SQL專家云告警郵件，在凌晨2點到3點之間帶有資源等待的會話數暴增，請我們協助分析，
現象
登錄SQL專家云，進入活動會話的趨勢分析頁面，下鉆到2點鐘一個小時內的資料，看到每分鐘的等待數都在100左右，2點15分時達到200，
轉到活動會話原始資料頁面，看到大量會話都在等待，等待型別是LATCH_EX，等待資源是LOG_MANAGER，資料庫都是MIIS****，SQL陳述句是INSERT、UPDATE、DELETE等寫入的陳述句，
等待資源是LOG_MANAGER，說明資料庫MIIS****的日志檔案在發生變化，轉到資料庫空間頁面，發現日志檔案從2點鐘開始增長，2點20時增長到90GB，3點時降到初始值（因為3點有自動收縮日志檔案的計劃任務），
分析
首先要分析的是什么陳述句導致資料庫日志檔案的暴增，進入慢陳述句匯總頁面，匯總2點鐘一個小時內的慢陳述句， 根據執行時間、CPU消耗、讀次數、寫次數等指標排序， 找到一個非常大的SQL陳述句，2點開始執行，2點18分結束，這是遷移歷史資料的作業，把當前時間一年前資料遷移到歷史表（插入到歷史表，然后從當前表中洗掉），作業很久以前被停止了，昨天才開啟，因為要遷移的資料很多，導致了日志檔案的暴增，
接下來分析LOG_MANAGER的等待，日志檔案空間不夠時就會觸發自動增長，檔案增長時，寫入資料的會話必須等待，此時會看到Latch等待型別，增長花費的時間越長，等待的時間越長，造成的性能抖動越嚴重，
從2點鐘開始日志檔案頻繁自動增長，日志檔案的自動增長增量設定為10%，隨著日志檔案的空間越來越大，每次增加會達到幾GB甚至更多，基于磁盤的性能，最少造成十幾秒的性能抖動，
解決
- 修改資料檔案和日志檔案的自動增長為200MB， 每次自動增長很快就能完成，基本不會有性能抖動，
- 調整自動收縮日志檔案的維護計劃，每次收縮的時候預留10GB的空間，避免頻繁的自動增長，
- 定期檢查資料檔案的空間，一次性增長一定的空間，避免頻繁的自動增長，
其它
除非磁盤空間嚴重不足，否則不要收縮資料檔案，詳細請參考：資料庫自動收縮造成的阻塞，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/541326.html
標籤：其他