24x7 vs 夜间时间窗口

Question

我在哪里可以找到有关如何更好地转向 24x7 运营的资源？拥有大数据库的大公司是如何做到这一点的？我们的夜间工作，例如

1. 清除旧数据
2. 重新索引
3. 更新统计

所有这些似乎都会对我们的系统造成严重影响（即在线用户和实时数据馈送）。我已经在亚马逊上查找了与此主题相关的任何书籍，但到目前为止还没有找到任何内容。

Answer 1

维护 24x7 数据库是一个相当大的主题，需要考虑很多选项。这个广泛的主题有很多项目需要考虑，但我们可以尝试根据一些高点进行接触。

您首先要确定的是，虽然许多操作是 24x7 的，但通常有时活动较少。您可以利用这些时间来运行维护，从而减少对数据库的干扰。第二个是您需要为完全中断（例如服务包或数据库迁移）预留一些时间，因此您需要与您的管理层协商完整的维护窗口。对于特定项目，您需要为每一个项目考虑和计划，并适当地利用您的工具。重要的是你必须计划每一个，我提供的任何例子都非常“你的里程可能会有所不同”。

备份

备份通常不会对工作负载产生巨大影响，但必须考虑在内，因为它们会消耗大量 I/O。您需要适当地安排这些活动并监控完成所需的时间。这里最大的障碍是，在 24x7 的操作中，您可能无法在一周的每个晚上进行完整的夜间备份。您需要结合日志备份来计划何时可以进行完整、何时进行差异以及这两者的保留期。

例如，我在周日晚上（最低活动）运行所有数据库的完整备份，在所有其他晚上（周一至周六）运行差异。我在磁盘上保留了过去两周的完整信息和差异，以及过去两天的日志。这为我提供了足够的恢复灵活性，但如有必要，我可能必须从磁带中恢复备份。

索引/统计维护

这是您必须处理的最常见的主动维护类型。你无法避免它，但你可以减轻它的影响。最初的经验法则是您应该只对需要它的对象进行维护。一般准则是仅重建大于 30% 的碎片和大于 1000 页的索引。如果您有自动更新统计信息，这将处理您的大部分统计信息维护工作，但保持同步的夜间工作并不是一个坏主意。

如果您拥有企业版，您还可以访问其他一些用于管理维护的选项。最重要的是Online Index Rebuilds，它允许您在索引仍在使用时重建索引（本质上，它并排构建索引，然后将其交换）。您还可以利用分区对“大”表的来减少所需的重建时间。

对于此类维护，如果您没有处理这些最佳实践的自定义脚本，最好的选择是使用Ola Hallengren 的维护脚本。这些都相当容易设置和配置，并且内置了许多这些指南。

DBCC 一致性检查

根据您的整体工作负载，您可能会发现 DBCC 检查对您的操作具有破坏性。有两种常用方法可以最大限度地减少 DBCC 对数据库的影响：

• PHYSICAL_ONLY- 运行此选项将在物理页面级别检查您的数据库并避免更具侵入性的全面检查。这将包括确定最可能的腐败类型。
• 检查恢复的副本 - 如果您有空间，您可以将数据库恢复到另一个实例并针对恢复的副本运行 DBCC 检查。这将讲述有关您的实时数据库的相同故事，但您显然不会干扰活动。这里的其他一些替代方案是针对日志传送副本或镜像数据库运行 DBCC。

这篇博文提供了有关您的选择的更多详细信息。

批处理作业/ETL

这实际上取决于您如何设计流程。你的 ETL 总是会干扰实时 OLTP 表（就像任何其他应用程序一样），所以要记住一些关键：

• 在您的其他维护和低活动期间安排此类工作。
• 调整工作的大小，以便对性能进行批处理，并且批处理不会太大而导致表锁定数小时。频谱末端的示例：逐行痛苦 (RBAR) 与单个百万行删除。
• 在适当的情况下使用阶段表并离线处理数据。仅在绝对必要时才触摸带电的东西。

结论

同样，这里有很多地方需要介绍。这不是一个全面的指南，而是一些方法的高级概述。我什至还没有讨论高可用性选项（例如可用性组和故障转移群集）。您将需要查看每个项目并制定如何处理它的计划。在许多方面，您还需要在前进的过程中迭代和完善您的工作。

其他资源：

SQL Skills VLDB 维护最佳实践