SQL Server ->> 記Alwayson高可用副本同步失敗後續恢復的效能調優爭議
繼續上一篇SQL Server ->> AlwaysOn高可用副本同步失敗 講到說現在公司的Azure雲生產環境的一臺alwayson的高可用副本同步中斷，中斷後自然就是恢復，恢復肯定從中斷的日誌鏈條恢復。
首先兩臺機器都是Azure雲，IP網段是一個網段，連通性是沒有問題。要恢復同步上篇隨筆也講了，就是重啟SQL Server服務，讓SQL Server自己自然redo日誌就行了。
負責伺服器運維的SA同事是10月26號晚上10點左右重啟了SQL Server服務的，上篇博文也說了，高可用副本中斷同步其實是10月23號凌晨2點15分的時候中斷，也就是起碼堆積了3天多快4天的日誌等待redo。所以整個恢復過程會非常慢。
接下來就是問題了，由於日誌非常多，對整臺副本伺服器的效能影響非常大，影響最大的我認為當然是磁碟IO。
這裡開始有爭議點，SA同事微信群裡發出下面兩張截圖說是日誌接近760G，恢復程序比較慢。我覺得這點也不太準確，首先我知道中斷幾天導致日誌堆積等待redo沒錯，但是不能以日誌檔案大小來判斷。日誌檔案大小是佔用磁碟空間的表現，不代表等待恢復的佇列有760G大小。要判斷有多少日誌待恢復，還是要通過 SQL Server ->> AlwaysOn 監控指令碼 這篇裡面的第二條監控指令碼比較準確說明問題。這是爭議點之一。
下面這張圖是26號晚上11點的時候看到，日誌檔案的讀操作非常恐怖，幾乎慢符合的讀日誌記錄去redo
這個時候要注意觀察SQL Server日誌，有沒有報錯資訊，提示還剩多長時間。
由於中斷了得有三天多，加上週末的時候我們資料庫一張表對一些過期的資料進行更新（上億行資料），日誌體積相當恐怖。一直到第二天早上10點還沒有追上日誌同步。
第二天早上10點多的時候我用監控指令碼查看了一下alwayson副本的redo queue還堆積了幾十個G的日誌佇列，通過 SQL Server ->> AlwaysOn 監控指令碼 裡面的監控指令碼可以看到有50G的日誌佇列堆積。
雖然說通過redo rate預估只是需要30分鐘就可以完成，但是這點是建立在沒有新的日誌增加的情況下，我們重啟服務的時間點是早上10點，這個時間點我們的應用程式在不斷往資料庫寫入更新資料，不可能說停止應用程式讓副本去慢慢恢復。
這個時候出現第二個爭議點：
SA同事看到redo的速度跟不上日誌增加的資料，一直追不上去，認為說這臺機器的記憶體只有60G（主節點是120G），他通過OS_Performance_counter這個DMV看到PLE只有120秒（主節點是1000吧）。同時又通過Windows的performance monitor看到F盤的磁碟響應時間是200ms以上（正常情況下應該是個位數才是健康值）。認為說是記憶體壓力傳導到IO，導致IO響應速度慢。爭議點就在這：記憶體壓力導致IO慢。
我是對這點持不一樣的意見的。首先PLE這個counter的確是衡量記憶體壓力的一個重要指標值（我做DBA的時候也是經常會檢視這個統計值），它說明資料頁存留在緩衝區多久時間後就會被刷出緩衝區。