使用 Ola Hallengren 腳本的建議 SQL Server 備份計劃
我們正在建構一個新的 AlwaysOn SQL Server 2016 數據庫集群，我正在使用 Ola Hallengren ( https://ola.hallengren.com ) 備份腳本設置備份，我正在尋找一些最佳執行時間的建議以下任務：
DatabaseIntegrityCheck - SYSTEM_DATABASES DatabaseIntegrityCheck - USER_DATABASES IndexOptimize - USER_DATABASES我目前計劃使用以下計劃進行備份：
DatabaseBackup - SYSTEM_DATABASES - FULL @ 23:30 every day DatabaseBackup - USER_DATABASES - FULL @ 23:00 every day DatabaseBackup - USER_DATABASES - DIFF @ Every hour starting at 00:00 to 22:00 DatabaseBackup - USER_DATABASES - LOG @ Every 5 mins starting at 00:03 to 23:59:59通過閱讀建議是在備份之前進行數據庫完整性檢查，所以我認為可能在主備份前 30 分鐘，然後在已知的小負載時間執行索引優化。作為 SQL Server 備份的計劃是否有意義？
$$ T $$他的建議是在備份之前進行數據庫完整性檢查，所以我認為可能是在主備份前 30 分鐘，然後在已知的小負載時間執行索引優化。作為 SQL Server 備份的計劃是否有意義？
一些想法：
- 索引維護可能不像您想像的那麼頻繁。通常，索引碎片對現代硬體的性能影響非常小，尤其是當您考慮到與索引重建有關的所有日誌都必鬚髮送到您的可用性組輔助伺服器時。我建議考慮使用 Ola 的維護解決方案每天（甚至更頻繁地）更新統計資訊，並確保您使用他網站上的這個範例（注意
NULLs 表示索引碎片）：D. 更新所有使用者數據庫的修改統計資訊
EXECUTE dbo.IndexOptimize @Databases = 'USER_DATABASES', @FragmentationLow = NULL, @FragmentationMedium = NULL, @FragmentationHigh = NULL, @UpdateStatistics = 'ALL', @OnlyModifiedStatistics = 'Y'
- 如果您發現索引碎片確實會導致性能問題，或者您只是想讓它們保持體面的狀態，您可以不那麼頻繁地安排它。根據數據庫和索引大小，可能每週一次或每月一次。
- 這導致我在備份前 30 分鐘回答您的“猜測”以進行一致性檢查。在您真正讓流程執行之前，您不會知道。如果您的每月索引維護需要三個小時，那麼您需要在統計數據更新之前啟動它。如果 CHECKDB 需要五個小時，則安排它在 AG 輔助伺服器上執行，或者將數據庫還原到獨立伺服器並在那裡執行（搜尋“解除安裝 CHECKDB”）。
- 在我看來，每小時進行一次差異備份是多餘的。我通常每天做一次，可能一天兩次，具體取決於環境。你有你的日誌備份，你需要記住差異不是增量的。它們將繼續增長直到下一次完整備份，因為它們會跟踪自上次完整備份以來的所有更改。在某些情況下，差異備份可能會超過完整備份的大小。在這些情況下，您需要評估完整備份是否優於差異備份。
- 您是否有足夠的磁碟空間來保存 5 分鐘的事務日誌備份？這是業務需要的（SLA、RTO、RPO）嗎？6分鐘能跑嗎？在三個月的時間裡，額外的一分鐘會對您儲存的文件數量產生很大影響。我經常發現我的大多數客戶對 10 分鐘或 15 分鐘日誌備份的權衡感到滿意。
- 可以每天進行完整備份，但根據您的保留策略以及恢復時間目標和恢復點目標，您可能對每週完整備份使用者數據庫、每天完整備份系統數據庫以及差異可以在必要時填補空白。
最終，這一切都取決於企業需要什麼來滿足內部和外部的服務水平協議。如果可以在兩個小時內從 OLTP 源重新生成報告/OLAP 樣式數據庫，那麼您無需像 OLTP 數據庫那樣擔心它。
我希望這可以幫助您為您的業務制定適當的策略。這就是推動這些決定的原因。
你的數據庫有多大？您將備份保留多長時間？
DatabaseBackup - SYSTEM_DATABASES - FULL @ 23:30 every day這是必須的，因為您的主數據庫不能有 DIFF 備份，所以這是每天備份它的唯一方法。
DatabaseBackup - USER_DATABASES - FULL @ 23:00 every day DatabaseBackup - USER_DATABASES - DIFF @ Every hour starting at 00:00 to 22:00我通常每週一次和每天一次。但這就是複雜的地方。
大多數數據庫都可以很好地處理這個問題，但是您可能有一些 10TB 的怪物，每天只有幾百 MB 的更改，這需要特殊處理。或者，您可能擁有每天完全循環的 1TB 數據庫，而 DIFF 備份是在浪費時間。
我的意見是標準化，然後在一周後匯總和繪製 msdb.dob.backupset 數據，以確定最壞中最壞的情況，然後為這些數據設置特殊步驟。如果您乾淨整潔，請創建一個審核流程文件和腳本，每月執行一次。有腳本 可以確定這一點，但最好的時間利用是吸它看看。
DatabaseBackup - USER_DATABASES - LOG @ Every 5 mins starting at 00:03 to 23:59:59這很好，但即使根本沒有發生任何事情（75k 未壓縮，6k 壓縮），每個數據庫每天也會生成 288 個日誌文件。這些數字會根據您環境的大小和保留期迅速增加。
但最糟糕的部分是恢復它們。我不知道您是否曾經連續恢復 288 個日誌文件備份（當然是使用腳本），但即使其中沒有任何內容，它們也將花費超過幾秒鐘的時間來完成每個備份。我不知道瓶頸在哪裡（SAN、SMB 協議、網路延遲、伺服器、SQL 恢復程式碼或什麼），但相信我，它加起來通常是在最糟糕的時候，“應用程序剛剛破壞了一切我們現在需要徹底恢復！”
即使這樣。即使您只有一台帶有 50 個數據庫的伺服器。如果您的伺服器出現問題，並且您必須在當天恢復 14,400 個日誌備份，而不是其他所有內容……腳本編寫不是問題。延誤是！
當然，將此與“您失去 15 分鐘或數據”與“您失去 5 分鐘數據”進行權衡，您的結果可能會有所不同。
無論您採用哪種方式，都會遇到一件事，那就是堆積起來的愚蠢的文本日誌。是的，我會稱它們為愚蠢的，因為在 CommandLog 中發現錯誤很痛苦，然後必須掃描該目錄中的一百萬個文本文件才能弄清楚發生了什麼。
不過享受吧。我們使用 Hallengren。但如果我們今天可以重做，我們可能會改用 Minion。許多相同的物理問題仍然存在，但我相信管理和故障排除可能更容易。