介紹
物理故障、操作系統故障或 SQL Server 故障都可能導致兩個可用性副本之間的會話失敗。 可用性副本不會定期檢查 Sqlservr.exe 所依賴的組件來驗證這些組件是在正常運行還是已出現故障。 但對於某些類型的故障，受影響的組件將向 Sqlservr.exe 報告錯誤。 由另一個組件報告的錯誤稱為“硬錯誤 ”。 為了檢測可能忽略的其他故障，Always On 可用性組實施了自己的會話超時機制。 以秒為單位指定會話超時期限。 此超時期限是一個服務器實例在考慮斷開另一實例的連接之前，等待接收來自該實例的 PING 消息的最長時間。 兩個可用性副本之間發生會話超時時，可用性副本將假定已發生故障並聲明一個“軟錯誤”。
一、硬錯誤導致的故障
可能的硬錯誤原因包括（但不限於）下列幾種情況：
- 連接或網線斷開
- 網卡出現故障
- 路由器更改
- 防火牆更改
- 端點重新配置
- 事務日志駐留的驅動器丟失
- 操作系統或進程故障
例如，如果主數據庫中的日志驅動器停止響應或失敗，操作系統會通知 Sqlservr.exe 出現嚴重錯誤。
某些組件（如網絡組件和某些 IO 子系統）使用它們自己的超時設置來確定故障。 這些超時設置獨立於 Always On 可用性組，后者不了解它們，並且完全不能識別其行為。 在這些情況下，超時延遲會延長發生故障與可用性副本收到所引發硬錯誤之間的時間。
二、軟錯誤導致的故障
可能導致會話超時的情況包括（但不限於）下列各項：
- 諸如 TCP 鏈接超時、數據包被刪除或損壞或數據包順序錯誤等網絡錯誤。
- 操作系統、服務器或數據庫處於掛起狀態。
- Windows 服務器超時。
- 計算資源不足，例如 CPU 或磁盤超負荷運轉，事務日志填滿，或系統用完內存或線程。 在這些情況下，需要增加超時期限、降低工作負荷或更換硬件以處理相應的工作負荷。
三、回話超時機制
由於軟錯誤不能由服務器實例直接檢測到，因此，軟錯誤可能導致一個可用性副本無限期等待會話中另一個可用性副本的響應。 為了防止發生這種情況， Always On 可用性組實施了會話超時機制，此機制基於以下條件：所連接的可用性副本會在每個打開的連接上按固定間隔發送 ping。 在超時期限內收到 ping 指示連接仍是開放的且服務器實例正在通過此連接進行通信。 收到 ping后副本將重置此連接上的超時計數器。主副本和輔助副本相互 ping 以指示它們仍處於活動狀態， 會話超時限制是用戶可配置的副本屬性，默認值為 10 秒。
如果在會話超時期限內沒有收到來自另一個副本的ping，該連接將超時、連接將關閉；超時的副本進入 DISCONNECTED 狀態。 即使為同步提交模式的副本，事務也將不等待該副本重新連接暫時將該輔助副本切換到異步提交模式。在該輔助副本重新與主副本連接后，它們將恢復同步提交模式。
四、故障轉移級別條件
參考：https://msdn.microsoft.com/zh-cn/library/ff877884(v=sql.120).aspx
總結
無法檢測到主數據庫之外的數據庫中的故障。 此外，也不太可能檢測到數據磁盤故障，除非數據庫因為數據磁盤故障而重新啟動，僅在出現軟錯誤時，才對可用性副本執行有效的錯誤檢查。
| 備注： 作者：pursuer.chen 博客：http://www.cnblogs.com/chenmh 本站點所有隨筆都是原創，歡迎大家轉載；但轉載時必須注明文章來源，且在文章開頭明顯處給明鏈接。 《歡迎交流討論》 |