節點故障轉移後使 SQL 聯機的時間更長

在我們為 SQL 伺服器進行正常作業系統修補後，我們遇到了一個奇怪的問題。

根據最佳實踐，我們在被動上應用更新檔並進行節點故障轉移以使目前的被動、主動或反之亦然以完成修補。

通常，節點故障轉移是無縫的，並在一分鐘內完成。但是最近我們遇到了在節點故障轉移後需要 4 分鐘才能使 SQL 聯機的問題：

我正在檢查日誌和事件，但找不到原因：以下是目前的發現：

注意：SQL 伺服器在 VM 上執行

1. SQL Server 活動沒有增加
2. 數據庫是數據庫鏡像的一部分
3. 在此期間不會增加使用者連接或執行更長時間的使用者查詢
4. 所有數據庫的 VLF 低於 500
5. 沒有 CPU/記憶體壓力並且啟用了 LPIM。
6. 似乎在故障轉移期間長時間執行而被終止的程序是 EXEC sp_server_diagnostics 20 執行了過去 86745234 秒

請協助我還應該檢查什麼以找到根本原因？

編輯-我嘗試分析集群日誌並且可以看到 sql 離線已啟動，但我不確定它在內部花費至少 4 分鐘實際關閉 sql 並將其恢復。4 分鐘後，sql 錯誤日誌顯示數據庫的所有條目大約需要 10 秒。所以看起來 DB 可能沒有任何參與來減慢程序。

編輯-目前檢查時的一些 VLF 資訊

您的問題很可能是由於數據庫正在恢復以重做或撤消尚未強化到數據文件的事務。

一起避免恢復

在執行計劃的伺服器重啟或 FCI 的故障轉移之前，尤其是具有大量記憶體的 FCI ，我喜歡CHECKPOINT在每個數據庫上執行一個。這最大限度地減少了完全關閉所有數據庫所花費的時間，並且（當數據庫沒有完全關閉時）最大限度地減少重新啟動時的崩潰恢復時間。

我使用sp_ineachdbFirst Responder Kit執行此操作：

EXEC DBA.dbo.sp_ineachdb 'CHECKPOINT;`;

如果你討厭讓你的生活更輕鬆的免費程式碼，你可以用動態 SQL 做一些事情：

DECLARE @sql nvarchar(max) = N'';

SELECT @sql += N'CHECKPOINT ' + QUOTENAME(name) + '; '
FROM sys.databases;

EXEC sys.sp_executesql @stmt = @sql;

但是通過減少工作來更快地恢復

當然，正如Erik，Darling在評論中提到的那樣，確保您的 VLF 井井有條且大小合適。在崩潰恢復期間掃描這些 VLF 可能會給您帶來您所看到的所有痛苦。對於計劃內維護，您可以CHECKPOINT最大限度地減少或消除崩潰恢復。但是如果你有……呃……意外的崩潰和故障轉移，那麼崩潰恢復仍然會發生，而且你無能為力。

不那麼直接

我也有很多間接檢查站的運氣。我們已經在整個環境中推廣了這一點，並取得了很大的成功。

並遊說升級的權力

SQL Server 2019 包含一項名為Accelerated Database Recovery的功能，該功能可以加快恢復過程，尤其是在存在長時間執行的大型事務時。ADR 不僅用於崩潰後的恢復，還有助於其他需要恢復事務日誌的場景——包括可用性組二級重做和故障轉移集群實例故障轉移。

引用自：https://dba.stackexchange.com/questions/284296