如何解決SQL SERVER Always on 生產故障問題

如何解決SQL SERVER  Always on 生產故障問題，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

最近忙的要死，手底下各種優化，數據庫系統，各種問題，恨不得長上8只手干這些活，而偏偏屋漏偏逢連夜雨，SQL SERVER  ALWAYS ON  又出了問題，SQL SERVER 目前公司使用的是 WINDOWS 2016 ENTERPRISE +  SQL SERVER 2016 ENTERPRISE ALWAYS ON 的集群，來支撐公司部分業務。

SQL SERVER ALWAYS ON 作為成熟的SQL SERVER 集群解決方案已經在很多企業中應用，但任何系統都不是完美的，故障也是有的，這兩天運維的同事和我說，SQL SERVER  ALWAYS ON  的日志不在截取，瘋狂的增長。 其實我聽到這個消息后，并不緊張，因為以前我供職的某家公司，使用的SQL SERVER 2012 也有這樣的問題，最后雖然沒有找到根本原因，但問題是解決了。 

OK ，我們先看看SQL SERVER 的日志，SQL SERVER 的日志文件是LDF,對于外行來說，它就是一個文件，但實際上，對DBA來說他是一個可循環的 capped collection (此概念為MONGODB的一個概念，這里引用一下雖然不完全相同，但意思是這個意思)。

下面就是 一個LDF 的文件結構，每個文件里面有 多個 VLF 塊，而這些塊時可以復用的，也就是當 CHECK POINT 將 dirty data  FLUSH 到數據文件后，其實這些LOG 在某些層面上已經對數據庫沒有太大意義，是可以被DUMP掉的。

但為什么有時候，日志不能被截斷，并且日志不能被reuse 

1  VLF 塊中有沒有被 CHECK POINT 的日志 ，也就是活動日志，例如一個大事務，一直沒有做完，那么這個VLF的文件塊時不會被覆蓋的，直到數據刷到數據文件后，才可以被CHECK POINT ，這個VLF 才可以被重用

2 VLF 的尾部必須是 FREE  VLF ，如果碰巧你的 有 4個 VLF 而恰巧  TAIL 和 HEAD  在一個 VLF 中，那這樣的日志也是不能被收縮的，除非數據寫到VLF1 ，舉個例子，如果有一個壁虎，如果讓他釋放自己的空間，你說他是愿意從頭砍下去，還是從尾部砍下去。所以下面的情況也是不能收縮日志。

另外我們還要明白，收縮日志有沒有必要，在我看來，還好，因為日志如果漲到800G （不是因為錯誤，或者各種爛 DML）造成的，那就可以不釋放，因為他會REUSE 空間的，你SHRINK他后，早晚還是要占用空間，而且和系統交換空間也有損耗，干嘛呢。

如果你想看你的日志文件到底什么狀態，鍵入 dbcc loginfo 就可以知道了，狀態為 2的 是激活的，不可以SHRINK的文件

我們回到為什么日志不能被截取，其實這個說法不準確，應該是問日志為什么一直在激活的狀態，而不能背釋放，在我們這次故障中，明顯就是 ALWAYS ON 的日志沒有在從庫上被應用完畢。造成的問題

查詢數據庫一直是在 AVALIABILITY_REPLCA 的狀態，一般這樣狀態都是因為從庫有問題造成，例如從庫宕機，從庫由于查詢（一般從庫查詢，都是大查詢，OLAP的需求），造成日志無法應用，或者一些稀奇古怪的問題。

這里的經驗我們要重新啟動從庫即可，另外在從庫的錯誤日志中我發現了

下面的錯誤日志：

Error: 19432, Severity: 16, State: 0. Always On Availability Groups transport has detected a missing log block for availability database "database_name". LSN of last applied log block is (xxxx:xxxxxxx:x). Log scan will be restarted to fix the issue. This is an informational message only. No user action is required.

按照微軟官方的 FIX （微軟官方對錯誤的解釋和解決）

我們需要打上 SQL SERVER 2016 SP1  SP2的補丁來解決問題。

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業資訊頻道，感謝您對億速云的支持。