24x7 vs夜间窗口

在哪里可以找到有关如何更好地进行24x7作业的资源？具有大型数据库的大公司如何做到这一点？我们的夜间工作，例如

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

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

维护24x7全天候数据库是一个相当大的话题，需要考虑很多选择。这个广泛的主题有许多要考虑的项目，但是我们可以尝试并基于一些重点。

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

后备

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

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

索引/统计维护

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

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

如果您没有处理这些最佳实践的自定义脚本，那么最好的选择是使用Ola Hallengren的Maintenance脚本。这些非常容易设置和配置，并且内置了许多准则。

DBCC一致性检查

根据您的总体工作量，您可能会发现DBCC检查会破坏您的操作。有两种常见的方法可以最大程度地减少DBCC对数据库的影响：

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

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

批处理作业/ ETL

这实际上取决于您如何设计流程。您的ETL总是会干扰活动的OLTP表（就像其他任何应用程序一样），因此请牢记以下几点：

• 将此类工作安排在您的其他维护工作周围，并在活动少的时期进行。
• 调整工作的大小，以便为性能而分批处理，并且批处理的大小不会太大，以至于您的表锁定了几个小时。频谱末端的示例：逐行（RBAR）与一百万行删除。
• 使用阶段表，并在适当的情况下脱机处理数据。仅在绝对必要时触摸带电的东西。

结论

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

其他资源：

SQL Skills VLDB维护最佳实践