作为我们 DR 解决方案的一部分，我们尝试为繁重的事务负载数据库启用日志传送。当配置成功完成时，日志传送配置完成后启动的第一个事务日志备份作业会持续运行，并且大小呈指数增长。有一次，第一个事务日志备份作业运行了 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，并且仍在增长。
由于空间问题，我们最终终止了这个进程，因为事务日志备份作业从未完成。
有没有人经历过这种情况？我们有什么可以改变的以改善事务日志备份作业的处理时间吗？鉴于繁重的事务负载，我想知道是否最好为这个特定的数据库实施替代 DR 解决方案。