背景
客戶收到了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的空間，避免頻繁的自動增長。
- 定期檢查資料檔案的空間，一次性增長一定的空間，避免頻繁的自動增長。
其它
除非磁碟空間嚴重不足，否則不要收縮資料檔案，詳細請參考：資料庫自動收縮造成的阻塞。