数据库完全备份维护任务在数据库之间有很大的延迟

Question

我有几个数据库服务器，它们使用相同的基本维护任务来完成每天晚上的全部备份。间歇地，通常需要4或5小时的备用作业会突然花费13至15小时。起初，我认为网络很忙，或者运营团队很早就开始了夜间处理，但是我一直在深入研究这个问题，我注意到了一些奇怪的事情。

维护任务被设置为对所有数据库进行备份，忽略脱机数据库。它将备份保存到数据域服务器。这是预期会发生的事，而且通常是这样的：

• 晚上9点，备份工作开始。
• 系统数据库首先备份，并占用合并2分钟。
• DB1备份在晚上11点左右启动，需要1.5到2.5小时。
• DB2备份启动，需要2.5-3.5小时
• 工作于凌晨1时至3时结束。

查看MSDB中的备份集历史，这就是我所看到的

• 晚上9点，备份工作开始。
• 系统数据库首先备份，并占用合并2分钟。
• DB1备份在晚上11点左右启动，需要1.5到2.5小时。
• 启动DB2备份的tsql命令开始执行
• 延迟7-9小时
• 根据DB2的历史记录，MSDB.dbo.backupset备份实际上已经启动，需要2.5-3.5小时
• 工作于上午八时至下午十二时结束。

据我所知，凌晨2点之前没有任何活动会导致锁或争用，而且延迟似乎不定期地发生。

我的问题是，从执行tsql到实际启动备份，是什么导致了这么大的延迟？

编辑Rough Server规范: VM虚拟机(专用于所有资源) Windows Server2012 R2 Server 2014 SP2 CPU: 16核心内存:225 16

Answer 1

您是否在数据域设备上对普通CIFS共享执行本机SQL备份？

还是使用"DDBoost“代理直接备份到MTREE？

如果是后者，我们在DDBoost v2.0代理上也会出现类似的问题(尽管使用tran日志备份，而不是fulls)，该代理在升级到v3.5 (最新版本)之后就消失了。

还有几个其他的想法要排除：

1. 确保您没有执行“验证备份”，这只是确保它可以从磁盘重新读取整个备份文件(这几乎没有什么用处，并且只需要与原始备份一样长的时间)。见这个相关的问题。
2. 看起来你的盒子应该有足够的内存，但是要确保操作系统不缺内存。第三方备份代理和SSIS包运行在SQL内存空间之外，因此检查您的最大内存设置，并检查任务管理器或perfmon中的内存计数器。

Answer 2

这有时是由于从未被清除的MSDB.dbo.backupsethistory表所致。Server将一行插入到该表中，然后在备份过程中返回并更新该行。

如果您的MSDB处于非常慢的存储状态，并且无法将其缓存在内存中，而且它有很多历史记录，那么访问该表可能是您最大的瓶颈。我写了一篇名为布伦特的备份瓶颈: MSDB的博文，讲述了一次非常糟糕的事件。

要检查这一点，请运行服务提供商_闪电战 (免责声明:我编写的免费开源脚本)，其中一个警告是未清除MSDB历史记录，如果您存储了60天以上的历史记录，它会发出警告。

要修复它，请在维护计划中添加一个历史清理任务。但是，如果您在这个位置--更新此表需要花费很长时间--那么清除历史可能也要花费很长时间。您可能需要自己手动运行服务提供商_洗净_工作历史，一次啃掉一点历史记录，以保持较低的停机时间。