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

Question

我的任务是为我们的 Sql Server 2005 数据库制定维护计划。我知道对于备份，我希望每 15 分钟执行一次完整的数据库备份和事务日志备份。我的问题是弄清楚我想做哪些其他任务以及我应该多久做一次。

所以，到目前为止，我已经想到了这一点。如果我的想法有任何缺陷或更好的方法，请纠正我。

1. 备份 - 所有表，完整备份（每日）
2. 备份 - 选定表，完整备份（每小时）
3. 备份 - 事务日志（每 15 分钟）
4. 检查数据库完整性（每天）
5. 重组索引（每日）
6. 更新统计数据（每日）
7. 收缩数据库（每周）
8. 重建指数（每周）
9. 维护清理（每日）

我记得前段时间（当我在另一份工作中制定类似计划时）读到其中一些任务不需要每天运行或不应该每天运行。至于哪些，它逃脱了我。我可以使用一些指导来创建更好的维护计划，以减少灾难中的数据丢失，但不会在高峰时段运行时对系统造成负担（并提高性能）。

Answer 1

乔希，

对于所有 DBA 来说，这是一项非常常见的任务，对于每个人和每台服务器，正确的答案都不同。与许多其他事情一样，这取决于您的需求。

您绝对不想像已经建议的那样运行“收缩数据库”。它对性能有害，下面的参考将向您展示原因。它会导致磁盘和索引碎片，这可能会导致性能问题。最好为数据和日志文件预先分配一个大的大小，这样自动增长就不会启动。

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

进行索引重组、更新统计信息和索引重建时，您需要注意如何执行此操作，否则最终将使用更多资源并最终出现性能问题。

当您重建索引时，索引的统计信息将使用全扫描更新，但如果您在此之后更新统计信息，那么这些将使用默认样本再次更新（这取决于几个因素，通常是表大小 > 8 时表的 5% MB），这可能会导致性能问题。根据您拥有的版本，您或许可以进行在线索引重建。执行此活动的正确方法是检查碎片量，并根据碎片量进行索引重建或索引重组 + 更新统计信息。而且您可能还想确定哪些表需要更频繁地更新统计信息并尝试更频繁地更新统计信息。

维护计划是可以的，但除非您可以登录 SSIS 并调整 MP，否则很难充分利用它们进行这些自定义。这就是为什么我宁愿不使用它们而使用Ola Hallengren 的比 MP 更强大的免费脚本。此外，我建议您阅读 Paul Randal 关于此主题的参考文章。

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

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

Answer 2

即使您已经接受了答案，我也会分享我的经验。也许它会有所帮助:-)。

1. 完整的每日备份（每日） - 很好，但不要忘记在预定义的时间后检查空间并删除旧文件。
2. 备份选定的表（每小时） - 不明白你为什么需要这个，你最好使用差异备份。如何仅备份某些表：SSIS、脚本、bcp？关于差异备份，不要太频繁地安排它，因为你会窃取日志备份的角色。
3. 事务日志备份（每 15 分钟一次）- 太好了，您确定所有数据库都需要吗？是否所有数据库都使用完整恢复模型？
4. 检查数据库完整性 - 是的，但您需要确保不会破坏您的环境。DBCC 检查语句在资源和扫描完整数据库方面非常自私，因此需要在下班时间安排它们。
5. 重新组织索引（每天） - 不要强迫它，仅在需要时才这样做。检查有关碎片的索引 DMV，并仅根据需要进行重组。我会在单个每周任务上移动所有索引和统计操作。
6. 更新统计数据（每日） - 请参阅我对上一个问题的回答。与其仅仅强制更新所有统计信息，不如每天检查统计信息的最后更新时间，并且仅在某些情况下才更新它们。
7. 收缩数据库（每周） - 哦，不。请阅读 Paul Randal关于文件收缩的文章。
8. 重建索引（每周） - 见 5。

9. 维护清理（每天）- 好的。

10. 您最好还添加一个任务来验证您的备份 - 有一个 RESTORE 命令版本（verifyOnly.. 如果我没记错的话） - 假设每周一次，尽管我更喜欢每天一次。

你提到你想在数据丢失的情况下被屏蔽，所以我说你需要在这个维护过程中添加系统数据库。并且还要注意在与服务器本身不同的机器上备份文件。在某处保留一个文件，说明万一您需要重建主数据库、msdb.. 等。祝你的任务好运！

Answer 3

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

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

如果在每天执行的差异备份期间驱动器被填满会发生什么？如果索引重建作业运行时间异常长怎么办？如果数据加载过程导致广泛的资源争用，使正常操作陷入困境，该怎么办？所有这些都是计划中的事件，但可能会对我们试图保护的流程造成相当大的破坏。

始终考虑不同的工作如何相互作用并为它们计时，以便在敏感或资源密集型任务中没有重叠。

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

它描述了如何在 SQL Server 中执行重要的维护任务——无风险。例如，您可以在维护作业中构建简单的检查，以验证可用资源以及操作在执行之前所需的内容。这允许您确保您的环境可以处理您将要执行的操作，并在资源不足时以有意义的错误中止。

Answer 4

1. 看起来不错

2. 您可能会从此处进行差异备份中受益。肯定地调查他们

3. 看起来不错

4. 看起来不错

5. 如前所述，数据库收缩是不好的，因为它们会造成数据和日志文件的物理碎片，从而导致更多的随机 IO 读取。

5、6 和 8：见下文。

这些确实是相辅相成的，因为索引依赖于最新的统计数据，并且这些操作的顺序非常重要。我采用的基准方法（诚然可能不适用于所有人）是我执行两轮索引维护。首先，我做聚集索引，然后是非聚集索引。我对两者采用的方法如下。如果索引足够大且碎片足够多（sys.dm_db_index_physical_stats），我将重建索引（包括完整扫描的统计更新）。如果索引太小而无法重建，或者碎片不足以进行重建（少于 100 页且碎片在 5% 到 15% 之间），我将首先执行索引重组。然后我将使用完整扫描执行统计更新。

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

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