![SQL 数据库日志文件不断增长](https://linux22.com/image/527079/SQL%20%E6%95%B0%E6%8D%AE%E5%BA%93%E6%97%A5%E5%BF%97%E6%96%87%E4%BB%B6%E4%B8%8D%E6%96%AD%E5%A2%9E%E9%95%BF.png)
问题解决了(有点……)
我有点不好意思承认,这种行为是由内部应用程序中调用的存储过程引起的。然而,即使修复了错误,我仍然不知道为什么它会被备份触发!
这是有问题的代码:
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 就无法再释放日志,直到日志传送完毕(或至少备份好准备传送)。只要您进行完整备份以初始化合作伙伴数据库,日志传送过程就会启动,这就是为什么备份发生后症状就会出现的原因。备份不会导致问题,问题在于频繁运行的更新。