建议使用 Ola Hallengren 脚本的 SQL Server 备份计划

Question

我们正在构建一个新的 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 备份的计划有意义吗？

Answer 1

[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 数据库一样担心它。

我希望这有助于您为您的业务制定合适的策略。这就是推动这些决定的动力。