哪些因素會影響 SQL Server 恢復完成的時間

在最近規劃的 AWS RDS 故障轉移中，我們經歷了大約 20 分鐘的較長恢復時間。AWS 提供了一些關於原因的提示。

大型事務或冗長的恢復過程會增加故障轉移時間。

數據庫本身並沒有大量使用大型事務，所以我認為這不是罪魁禍首。因此，我有興趣了解哪些因素可能導致漫長的恢復過程？

• SQL Server版本有影響嗎（我們是2016）
• 數據庫的大小有影響嗎？

恢復過程大約需要 20 分鐘，我們希望採取措施將其縮短到 10 分鐘左右。

更新：

我沒有提到的一件事是，由於多年的糟糕設計，大約 50% 的數據庫大小是由於儲存文件的 blob，例如 html 或 XML。這會對恢復時間有任何影響嗎？

由於您沒有使用 SQL Server 2019，因此 ADR 將不適用。幾乎所有情況下都應考慮的一般準則很少，它們如下：

1. 使交易盡可能小。
2. 酌情控制與應用程序團隊或供應商聯絡的長期交易。
3. 盡可能頻繁地備份事務日誌以減少分析階段。

可以選擇更改目標恢復時間，但這也有一些不利之處。您應該在啟用它們之前考慮它們。

從 MS 站點，如果您避免以下情況，則不需要 ADR：

誰應該考慮加速數據庫恢復 以下類型的客戶應該考慮啟用 ADR：

• 具有長時間執行事務的工作負載的客戶。
• 已經看到活動事務導致事務日誌顯著增長的客戶。
• 由於 SQL Server 長時間執行恢復（例如 SQL Server 意外重啟或手動事務回滾）而導致數據庫長時間不可用的客戶。

從關於在數據庫中使用 blob 類型的問題的評論和新增內容來看，是的，擁有這些數據類型會顯著延遲數據庫的任何檢查點。相反，您應該使用 Brent Ozar 先生解釋的 CAS 儲存類型：

https://www.brentozar.com/archive/2015/03/no-more-blobs/

希望這可以幫助您做出正確的決定。

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