问题解决了（有点……）
我有点不好意思承认，这种行为是由内部应用程序中调用的存储过程引起的。然而，即使修复了错误，我仍然不知道为什么它会被备份触发！
这是有问题的代码：
SELECT DISTINCT T.*, TL.RunDate
FROM TaskLog TL
INNER JOIN Task T ON TL.TaskID = T.ID
WHERE TL.RerunFlag = 1
UPDATE TaskLog SET RerunFlag = 0
将最后一行更改为：
UPDATE TaskLog SET RerunFlag = 0 WHERE RerunFlag = 1
问题更新
我对数据库进行了完整备份，结果导致日志文件开始不受控制地增长。因此，问题不在于日志传送过程本身，而在于第一步 - 即备份数据库。我检查了 VLF 的数量，昨天超过 400 个，目前接近 200 个，所以这肯定是一个问题。
问题的简单陈述：
如果我尝试在 SQL Server 2005 上的数据库上启动日志传送，数据库的日志文件通常约为 80mb，并且会不断扩展到数十 GB，并且没有停止的迹象。DBCC SHRINKFILE 没有效果。
详细说明：
我已经成功地在多个数据库上实施了日志传送，但在 SQL Server 2005 上的一个特定数据库上出现了奇怪的行为。通常，这个数据库的数据量约为 80mb，日志文件量为 80mb，总大小约为 160mb。它的大小在一天中通常不会有太大变化。当我尝试使用日志传送向导启动这个数据库的日志传送时，问题就开始了。
向导进入第一步，即备份数据库，并达到 100% 完成。然后它在此处停止/暂停，并且从未进入下一步。没有生成任何错误消息，SSMS 本身也有响应。看起来向导似乎永远都在运行。我停止并终止了该过程，但损害已经开始。从此刻起，直到日志文件备份并缩小时，日志文件一直以每 5 分钟约 100mb 的速度扩大。
用户似乎没有受到影响（谢天谢地）。
对原因和解决方案有什么想法吗？
答案1
您是否尝试过使用 NORECOVERY STANDBY 选项将源备份还原到目标服务器，然后进行日志传送安装？我曾使用这种方法绕过“向导”进行完整备份并将其还原到目标服务器的需要。
答案2
这听起来确实像是事务日志中发生了一些事情。
你看过日志传送状态报告？ 这可能会让您了解当数据库挂断时会发生什么。具体来说，您需要弄清楚当它尝试复制日志时会发生什么。
答案3
您是否定期备份事务日志文件？（您应该）
听起来您有虚拟日志文件 (VLF) 碎片。我建议阅读：提高事务日志吞吐量的 8 个步骤
答案4
考虑到您的症状，我猜日志文件的增长实际上是正确的。数据库通常是简单的恢复模型吗？对该数据库运行一小段时间的探查器，您可能会发现发生了大量更新（或删除或插入）。
我的想法是这样的，
通常 SQL Server 会重新使用日志空间。但是，一旦启动日志传送过程，SQL Server 就无法再释放日志，直到日志传送完毕（或至少备份好准备传送）。只要您进行完整备份以初始化合作伙伴数据库，日志传送过程就会启动，这就是为什么备份发生后症状就会出现的原因。备份不会导致问题，问题在于频繁运行的更新。