我有点尴尬地承认，这种行为是由一个称为内部应用程序的一部分的存储过程造成的。 但是，即使修复了这个bug，我仍然不知道为什么它是由备份触发的！
这是违规的一段代码：
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个，所以肯定是个问题。
数据库的日志文件通常在80mb左右，如果我尝试在SQL Server 2005上的数据库上启动日志传送，则数据库连续扩展到10几千兆字节，没有任何停止的迹象。DBCC SHRINKFILE没有任何作用。
我已经成功地在几个数据库上实现了日志传送，但是在SQL Server 2005的特定数据库上有奇怪的行为。通常这个数据库大约有80MB的数据和80MB的日志文件，总大小约为160MB。 在一天的过程中，它的大小通常不会变化很多。 当我尝试使用日志传送向导启动此数据库上的日志传送时，问题就开始了。
向导到达备份数据库的第一步，达到100％完成。 然后停止/暂停在这里，永远不会到达下一步。 没有错误消息生成和SSMS本身是响应。 看起来这个巫师永远是从字面上理解的。 我停下来杀了这个过程，但是伤害已经开始了。 从这个时刻起，直到日志文件备份和收缩时，日志文件每隔5分钟以100mb左右的速度继续扩展。
用户似乎不受影响（谢天谢地）。
任何想法的原因和解决scheme？
您是否尝试过使用NORECOVERY STANDBY选项进行源备份和恢复到目标服务器，然后执行日志传送安装？ 我已经使用它来绕过“向导”进行完整备份并将其恢复到目标服务器的需要。
它确定地听起来像事务日志正在发生。
你看过日志运送状态报告吗？ 这可能会让你知道这个数据库挂起时发生了什么。 具体来说，你会想知道当它试图复制日志时会发生什么。
你是否经常备份事务日志文件？ （你应该）
这听起来像你有虚拟日志文件（VLF）碎片。 我build议阅读： 8个步骤来提高事务日志吞吐量
鉴于你的症状，我猜测日志文件的增长实际上是正确的。 数据库通常是简单的恢复模式？ 运行分析器很短的时间againts这个数据库，你可能会发现很多更新（或删除或插入）发生。
我的想法是这样的，
通常SQL服务器正在重新使用日志空间。 一旦开始日志传送过程，虽然SQL服务器不能再释放日志直到它被发送（或至less备份准备好被发送）。 日志传送过程会在您完全备份用于初始化伙伴数据库时立即启动，这就是您的症状在备份发生后立即出现的原因。 备份不会引起问题，无论更新频繁运行如何。