问Server维护计划-任务和调度方面的最佳实践

EN

乔什

对于所有DBA来说，这是一项非常常见的任务，对每个DBA和每个服务器来说，正确的答案并不相同。和很多其他的事情一样，这取决于你需要什么。

最明确的是，您不想像前面提到的那样运行“收缩数据库”。它的邪恶表现和下面的裁判将告诉你为什么。它会导致磁盘和索引碎片，这会导致性能问题。您更好的做法是预先分配一个大的大小的数据和日志文件，以便自动增长不会启动。

我不明白你选择的2号表是完全备份的。你能详细说明一下吗？

进入索引重组、更新统计信息和索引重建时，您需要注意如何做到这一点，否则您将最终使用更多的资源，并最终导致性能问题。

当您重新生成索引时，索引的统计信息将使用will扫描更新，但如果在此之后更新统计信息，则这些统计信息将再次使用默认示例(这取决于几个因素，通常是表大小>8MB时表的5% )进行更新，这可能会导致性能问题。根据您所拥有的版本，您可能可以进行联机索引重建。进行此活动的正确方法是检查碎片的数量，并根据这一点进行索引重建或索引重新组织+更新统计。此外，您还可能希望识别哪些表需要更频繁地更新统计数据，并尝试更频繁地更新统计数据。

维护计划是可以的，但如果不能登录到SSIS并调整MP‘，就很难从它们中获得最好的效果，这就是为什么我不喜欢使用比MP更健壮的Ola Hallengren的免费剧本。此外，我建议继续阅读Paul Randal关于这个主题的参考文章。

参考文献：http://technet.microsoft.com/en-us/magazine/2008.08.database.aspx

这不是对你问题的全面回答，而是一个很好的起点。如果您有任何其他问题/评论，请告诉我们。

迟答，但可能对其他读者有用。

请记住，您可以创建许多维护或报告任务，这些任务与它们相关的风险是看不见的。

当驱动器在每天执行的差异备份中被填满时，会发生什么情况？如果一个指数重建工作运行时间异常长，该怎么办？如果数据加载过程导致广泛的资源争用，从而使正常操作陷入瘫痪，又如何呢？所有这些都是计划好的事件，但却会对我们试图维护的进程造成相当大的破坏。

请始终考虑不同的作业是如何交互的，并对它们进行时间安排，以便在敏感任务或资源密集型任务中不存在重叠。

我建议先读这篇文章：http://www.sqlshack.com/removing-the-risk-from-important-maintenance-tasks-in-sql-server/

它描述了如何在Server中执行重要的维护任务--无风险。例如，您可以在维护作业中构建简单的检查，以验证可用资源以及在执行操作之前所需的操作。这使您能够确保您的环境能够处理您将要做的事情，如果资源不足，则使用有意义的错误中止。

1. 看上去很好
2. 在这里执行差异备份可能会有好处。一定要调查他们
3. 看上去很好
4. 看上去很好
5. 如前所述，数据库收缩是不好的，因为它们会造成数据和日志文件的物理碎片，从而导致更多的随机IO读取。

5、6和8:见下文。

由于索引依赖于最新的统计数据，这些操作的顺序非常重要，因此这些操作实际上是并行的。我使用的基线方法，当然不是对每个人都适用，就是执行两轮索引维护。首先，我执行聚集索引，然后执行非聚集索引。我对这两种方法都采用了以下方法。如果一个索引足够大，并且足够分散(sys.dm_db_index_physical_stats)，我将重新构建索引(其中包括一个带有完整扫描的统计信息更新)。如果索引太小，无法重建，或者对重建不够零碎(不足100页，碎片在5%至15%之间)，我将首先执行索引重新组织。然后，我将执行一个完整扫描的统计数据更新。如果索引还不够零碎，不足以维护这些索引，我仍然将使用完整的扫描来更新统计数据。

现在，这涵盖了索引统计，但忽略了对列统计做任何事情。每周，我将更新列统计。

我希望这在某种程度上有所帮助！