SQL Server维护计划-任务和计划的最佳实践

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

因此，到目前为止，我已经牢记这一点。如果我的想法有任何缺陷或更好的解决方法，请纠正我。

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

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

乔希

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

最肯定的是，您不想像已经建议的那样运行“收缩数据库”。它对性能的影响以及下面的参考文献将向您说明原因。它会导致磁盘以及索引碎片，这可能会导致性能问题。最好为数据和日志文件预先分配较大的大小，以免自动增长。

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

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

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

维护计划还可以，但是除非您可以登录SSIS并调整MP，否则很难从这些计划中获得最大的收益。这就是为什么我宁愿不使用它们，而使用Ola Hallengren的免费脚本比MP更加健壮。另外，我建议您赶上Paul Randal在该主题上引用的文章。

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

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

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

1. 完整的每日备份（每天）-很好，但一定要在预定的时间后检查空间并删除旧文件。
2. （每小时）备份选定的表-不明白为什么需要此表，最好进行差异备份。如何只备份某些表：SSIS，脚本，bcp？关于差异备份，不要安排得太频繁，因为您会抢占日志备份角色。
3. 事务日志备份（每15分钟）-很好，您确定所有数据库都需要吗？是否所有数据库都使用完整恢复模型？
4. 检查数据库完整性-是的，但是您需要确保不会杀死环境。DBCC检查语句在资源上很自私，可以扫描整个数据库，因此需要在非工作时间进行计划。
5. 重新组织索引（每天）-不要强制执行索引，仅在需要时执行。检查有关碎片的索引DMV，并仅根据需要进行重组。我将所有索引和统计操作转移到一个每周任务上。
6. 更新统计信息（每天）-请参阅我对上一个问题的回答。每天不仅要强制更新所有统计信息，还应该检查统计信息的最新更新时间，并且仅在某些情况下才对其进行更新。
7. 缩小数据库（每周一次）-哦，不。请阅读Paul Randal 关于文件缩小的文章。
8. 重建索引（每周）-参见5。

9. 维护清理（每天）-可以。

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

您提到要在数据丢失的情况下被屏蔽，所以我想说您需要在此维护过程中添加系统数据库。并且还要注意将文件备份到与服务器本身不同的计算机上。将文件保存在某个地方，以防万一您需要重建主数据库，msdb..etc。祝您工作顺利！

答案较晚，但可能对其他读者有用。

请记住，您可以创建许多维护或报告任务，这些任务带有与之相关的未知风险。

每天执行差异备份时，如果驱动器已装满，会发生什么情况？如果索引重建作业运行时间异常长怎么办？数据加载过程是否引起广泛的资源争用，使正常操作瘫痪怎么办？所有这些都是有计划的事件，但是会严重破坏我们要维护的流程。

始终考虑不同作业的交互方式和时间安排，以使敏感或资源密集型任务不会重叠。

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

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

1. 似乎还好

2. 您可以从此处进行差异备份中受益。肯定地看着他们

3. 似乎还好

4. 似乎还好

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

5、6和8：请参阅下文。

由于索引依赖于最新的统计信息，因此它们确实并存，并且这些操作的顺序非常重要。我采用的基准方法可能并不适合所有人，但我采用的基准方法是执行两轮索引维护。首先，我先进行聚簇索引，然后进行非聚簇索引。我为这两种方法采用的方法如下。如果索引足够大且足够分散（sys.dm_db_index_physical_stats），我将重建索引（包括具有完整扫描的统计信息更新）。如果索引太小而无法重建，或者碎片不足以进行重建（少于100页且碎片在5％到15％之间），我将首先执行索引重组。然后，我将使用全面扫描进行统计信息更新。

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

我希望这可以有所帮助！

我对您的“数据丢失可能会在这里产生法律后果”发表评论。

然后，您绝对想要获得一个功能强大的第三方工具（如DPM），它比任何可以通过Internet进行脚本运行的速度都要快得多，并且处理起来要好得多，可以更好地处理备份（并从灾难事件中快速恢复并最小化麻烦）。

拥有备份是一回事。知道如何在紧急情况下使用它们是另一回事。

不要忘记，如果要在发生重大故障后恢复备份，您可能已经承受了巨大的压力和压力。您不需要额外的负担，即可轻松地挖掘和编写具有12个事务日志文件的RESTORE DATABASE语句...并祈祷它不会让您失望...

在我的工作场所，我可以使用DPM在5分钟内将350Gb数据库恢复/恢复到上个星期的任何时间。具有GUI界面。值得，在我的书中。

对于其余的内容，一定要研究Ola Hallengren的索引脚本，并根据需要调整参数。我个人而言，我将它与计划的任务结合在一起，使它每天晚上运行一个小时而无需重新扫描，因此它每次都处理最差的索引，并在每个星期六或列表中的所有索引时强制对碎片进行完全重新扫描已进行碎片整理。

最后，我将自己的声音添加到“永远不会自动缩小文件”组中。File Shrink只是在发生不正常事件而导致日志或DB文件（无限循环等）超负荷时偶尔使用的工具。它不应该是维护工具。如果您有磁盘空间压力，那么无论如何收缩只会延迟不可避免的情况。