作为我们DR解决方案的一部分，我们尝试为繁重的事务负载数据库启用日志传送。配置成功完成后，在日志传送配置完成后启动的第一个事务日志备份作业将连续运行并按指数级增长。有一次，第一个事务日志备份作业运行了12个小时，文件大小比数据库的27 GB完整备份文件大3倍。我们杀了这个过程。最近，我们尝试了使用差异的方法，如下所述，但事务日志备份作业仍然以不断增长的文件大小运行。
此过程在周末低使用时间内运行
7:46 am - 日志传送配置启动
上午9:32 - 备份文件存储在网络共享文件夹中。文件大小为26.1 GB
晚上9:30 - 日志传送配置完成。 - 我禁用日志传送备份，复制和还原作业
9:31 pm - 我用差异
9:33 pm - 差异完成，文件大小为768 MB。 - 我重新启用备份和复制作业，以便在差异后继续进行该过程 - 我将差异文件复制到辅助位置
9:45 pm - 第一个事务日志备份作业启动
9:59 pm - 复制差异文件后，我使用差异恢复辅助数据库
晚上11:02 - 差异的恢复仍在运行 - 上午9:45创建的事务日志备份作业仍在运行，文件大小为28 GB，并且仍在增长。
由于空间问题，我们最终终止了此过程，因为事务日志备份作业从未完成。
之前有没有人遇到过这种情况？有什么我们可以改变以改善事务日志备份作业的处理时间吗？鉴于繁重的事务负载，我想知道为这个特定的数据库实现替代DR解决方案是否最好。
答案 0 :(得分：0)
我知道这可能很旧，但添加一些可以帮助你的指针。
1.当数据库设置为Bulklogged恢复模型时，Tlog也将包含数据文件的副本，因此您的Tlogs大小将很大
2.此外，您可能希望使用以下跟踪标记检查备份和恢复期间发生的情况。
dbcc traceon（3004,3605，-1）
3.同样可以应用跟踪标志来恢复
4.如果恢复需要很长时间，这可能是由于回滚的巨额交易所致。请参阅以下链接了解更多详情
http://www.sqlskills.com/blogs/paul/why-could-restoring-a-log-shipping-log-backup-be-slow/
5.您还可以启用即时文件启动以加速恢复，因为这有助于立即增加数据文件
您还可以使用perfmon计数器检查是否存在网络延迟。