半夜收到報警短信，服務器磁盤空間不足，爬起來檢查一番，發現由于索引重建導致，而且該磁盤下仍有自動增長的數據文件，由于該服務器上其他盤符有剩余空間，于是打算將該磁盤下的數據文件限制增長，并新增幾個數據文件在其他有空閑空間的磁盤下，于是操作步驟如下：

第一步：檢查Alwayson各輔助節點的相同盤符是否同樣有磁盤空間(可以使用EXEC master..xp_fixeddrives來查看)

第二步：檢查各輔助節點下是否存在對應文件夾，沒有的手工創建

第三步：在主節點對數據庫上新增數據文件。

三步打完手工，順便檢查了下其他服務器，準備回去夢周公的時候，短信又報警了，Alwasyon數據延遲，而且是在同步模式的輔助節點上延遲，頓時小手一哆嗦，差點把電腦給摔了，立馬排查原因，輔助節點磁盤空間充足，對應目錄也已創建成功，并且其中一個數據庫的新增文件已在輔助節點上創建，但還有一個數據庫的新增文件沒有創建出來，也是懷疑當前時間索引維護導致大量日志積壓從而引起Alwasyon延遲，于是果斷關閉主節點上的索引維護，繼續使用Alwasyon控制面板觀察，發現輔助節點的重做隊列大小在逐漸增大，看來關閉索引維護并沒啥卵用，繼續排查問題。。。

問題的表象是日志重做隊列在增大，既然排除主節點“生產”大量日志的情況，那么就是輔助節點“消費”這些日志出現問題，接著排查IO壓力，輔助節點IO還算正常，唯一導致IO壓力的就一個完整備份作業在執行，完整備份作業，這和日志重做似乎沒啥沖突，但是別忘了剛才的操作是新增數據文件，罪魁禍首及時完整備份。由于數據庫比較大，完整備份需要花費幾十分鐘才能完成，為保證完整備份能備份所有數據文件的數據，SQL SERVER會在完整備份期間會阻止對數據庫新增文件，而輔助節點上“重做”日志便是對數據庫新增文件，于是完整備份“阻塞”日志重做，并給我們一個日志“重做”速率趕不上日志“生成”速率的假象。

總結：在Alwasyon的場景下新增數據文件，不僅要考慮輔助節點上的磁盤空間和對應文件目錄的問題，還應該檢查一下輔助節點是在運行完整備份，并且在操作結束后，一定要注意檢查對應文件是否在輔助節點上創建，并Alwayson的同步狀態是否正常。

PS: 如果輔助節點處于異步模式，且在輔助節點上沒有對應盤符或文件目錄，輔助節點重做"新增文件"這部分日志便會出錯，導致對應數據庫數據庫"掛起"，處于未同步狀態，此時輔助節點不會再向主節點發送"請求"，此時觀察日志發送隊列大小和日志重做隊列大小沒有任何意義。

PS2: 如果搭建了日志傳送，那么還需要考慮新增文件對日志傳送的影響，可能需要手動還原特定日志來指定新增文件的還原路徑

--================================================================

大半夜干活不容易，沒個妹子提神怎么行