Sql server 日志传送事务日志备份作业持续运行

作为灾难恢复解决方案的一部分，我们尝试为高事务负载数据库启用日志传送。当配置成功完成时，在日志传送配置完成后启动的第一个事务日志备份作业将持续运行并以指数级增长。有一次，第一个事务日志备份作业运行了12个小时，文件大小比数据库的27 GB完整备份文件大3倍。我们扼杀了这个过程。最近，我们尝试了一种使用差异的方法，如下所述，但事务日志备份作业仍然以不断增长的文件大小运行

此过程在周末低使用时间运行

• 上午7:46–日志传送配置开始

• 上午9:32–备份文件存储在网络共享文件夹中。文件大小为26.1 GB

• 晚上9:30–日志传送配置完成。 –我禁用日志传送备份、复制和恢复作业

• 晚上9:31–我输入命令以使用差异备份数据库

• 晚上9:33–差分完成，文件大小为768 MB。 –我重新启用备份和复制作业，以使该过程在差异化之后继续进行 –我将差异文件复制到辅助位置

• 晚上9:45–第一个事务日志备份作业开始

• 9:59 pm–复制差异文件后，我使用差异恢复辅助服务器上的数据库

• 晚上11:02–差速器的恢复仍在运行 –上午9:45创建的事务日志备份作业仍在运行，文件大小为28 GB，并且还在增长

由于事务日志备份作业从未完成，因此由于空间问题，我们最终终止了此进程

---

以前有人经历过这种情况吗？我们是否可以更改任何内容以缩短事务日志备份作业的处理时间？考虑到繁重的事务负载，我想知道是否最好为这个特定的数据库实现一个替代的灾难恢复解决方案。

我知道这可能很旧，但添加一些指针会对您有所帮助

1.当数据库设置为Bulklogged恢复模式时，Tlog也将包含数据文件的副本，因此您的Tlogs大小将很大

2.此外，您可能希望使用以下跟踪标志检查备份和恢复期间发生的情况

dbcc traceon（30043605，-1）

3.同样的跟踪标志也可以应用于恢复

4.此外，如果恢复需要花费很多时间，这可能是由于回滚了大量事务。有关更多详细信息，请参阅下面的链接

5.您还可以启用即时文件初始化来加速恢复，因为这将有助于立即增加数据文件

---

您还可以使用perfmon计数器检查是否存在网络延迟。

此数据库已完全恢复一段时间了吗？如果是，正常事务日志备份卷是多少？在配置日志传送的过程中是否存在“慢时间”？数据库文件的大小是多少，特别是事务日志？您以前是否在此数据库上执行过事务日志备份？如果是，那是多久以前的事了？