我的任务是为Sql Server 2005数据库设计维护计划。我知道要进行备份，我希望每15分钟执行一次每日完整数据库备份和事务日志备份。我的问题是弄清楚我还想做哪些其他任务以及应该多久执行一次。如果我的想法有任何缺陷，或者有更好的解决方法，请纠正我。备份（每小时）
备份-事务日志（每15分钟一次）
检查数据库完整性（每天）
重组索引（每天）
更新统计信息（每天）
收缩数据库（每周）
重建索引（每周）
维护清理（每天）

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

评论

当前数据库已超过30 GB，因此我认为缩小将有所帮助。

#1 楼

Josh，

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

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

我不理解您的＃2。选定表完全备份。您可以详细说明吗？

要重新组织索引，更新统计信息和重建索引，您需要谨慎执行此操作，否则最终将使用更多资源并最终导致性能下降问题。

重建索引时，将使用全扫描更新索引的统计信息，但是如果此后再更新统计信息，则将使用默认样本再次更新这些统计信息（通常取决于几个因素）如果表大小> 8 MB，则占表的5％），这可能会导致性能问题。根据您使用的版本，您也许可以进行在线索引重建。进行此活动的正确方法是检查碎片的数量，并取决于是否进行索引重建或索引重组+更新统计信息。另外，您可能想确定哪些表需要更频繁地更新统计信息，并尝试更频繁地更新统计信息。可以登录到SSIS并调整MP。这就是为什么我宁愿不使用它们，而使用Ola Hallengren的免费脚本比MP更加健壮。另外，我建议您赶上Paul Randal所引用的有关该主题的文章。

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

评论

Sankar，谢谢您的投入。我以为每小时对某些表进行备份（省去那些不经常更改的表）可能是一种更好的方法，可以节省一些小时备份的时间。这里最大的问题是我真的想要15分钟的事务日志备份，因为在我们这种情况下数据丢失可能会产生法律后果。至于完整的备份频率，最好是每小时一次，但是恐怕会给系统增加过多的负担。在发布之前，我确实已经看过该脚本，但是还没有机会尝试。

–乔什
2011年5月12日在17:23

#2 楼

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


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

（每周一次）重建索引-请参阅5.
（每日）维护维护-可以的。一个验证您的备份的任务-有一个RESTORE命令版本（verifyOnly ..如果我没记错的话）-假设每周一次，尽管我每天都喜欢。

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

#3 楼

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

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

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

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

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

#4 楼


似乎很好
在这里进行差异备份可能会受益。如前所述，请确保仔细查看它们
似乎很好
如前所述，数据库收缩是不好的，因为它们会造成数据和日志文件的物理碎片，从而导致更多的随机IO读取。 />
5、6和8：请参见下文。

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

希望这对您有所帮助！

#5 楼

我对您的“数据丢失可能会在此处造成法律后果”评论表示怀疑。闪存和最少的麻烦）比您可以脱离Internet的任何脚本都快得多，也更好。

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

不要忘记，如果要在重大故障后恢复备份，您可能已经承受了巨大的压力和压力。您不需要额外的负担即可轻松地挖掘和编写具有12个事务日志文件的RESTORE DATABASE语句...并祈祷它不会让您失望...我可以使用DPM在5分钟内将350Gb数据库恢复/还原到任何时间。具有GUI界面。值得的是，在我的书中。

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

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