背景 客戶收到了SQL專家雲告警郵件，在凌晨2點到3點之間帶有資源等待的會話數暴增，請我們協助分析。 現象 登錄SQL專家雲，進入活動會話的趨勢分析頁面，下鑽到2點鐘一個小時內的數據，看到每分鐘的等待數都在100左右，2點15分時達到200。 轉到活動會話原始數據頁面，看到大量會話都在等待，等待類型 ...
背景
客戶收到了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的空間，避免頻繁的自動增長。
- 定期檢查數據文件的空間，一次性增長一定的空間，避免頻繁的自動增長。
其它
除非磁碟空間嚴重不足，否則不要收縮數據文件，詳細請參考：資料庫自動收縮造成的阻塞。
