未知时间未备份后如何缩小 SQL Server 中的日志文件？

Question

我最近接管了一个已经使用了 2-3 年的数据库的管理，并且它没有任何事务日志维护计划。 DB 文件为 8 GB，但事务日志文件高达 54 GB。我开始备份日志文件，我需要回收该驱动器空间。我已经将我的数据库与我公司内构建了适当维护计划的其他站点进行了比较，它们的事务日志大约为 4 GB，这是我所期望的。这是我第一次遇到这个问题。

我执行了数据库的完整备份，并设置了初始事务日志维护计划，但我需要缩小这个 *.ldf 文件，因为它太不成比例了。我搜索了 Stack Overflow 留言板，希望能找到类似的情况。基于该研究，我尝试了 DBCC SHRINKFILE，但这并没有产生我预期的结果。我将数据库恢复到原始（超大日志文件到位）并尝试了完全-简单-完全恢复技术来截断日志，但仍然无法回收空间。我什至尝试删除 .ldf 并完成清除（恢复挂起）状态的过程。我回到DBCC CHECKDB修复功能，但是在清除（Recovery Pending）状态后，我根本无法备份事务日志。我开始收到一个 msg 42000 错误 50000，它也引用了错误 3013。最后，我删除了整个混乱并将其恢复到原来的状态。我已尝试尽可能详细，如有必要，我很乐意澄清或阐述。正如我所说，这是我第一次遇到这样的事情，但我总是从头开始我的项目。这是我第一次跳进别人建造的东西中间，但我拿到它时就坏了。

ALTER DATABASE [DBName] SET EMERGENCY;

GO

ALTER DATABASE [DBName] set single_user

GO

DBCC CHECKDB ([DBName], REPAIR_ALLOW_DATA_LOSS) WITH ALL_ERRORMSGS;

GO 

ALTER DATABASE [DBName] set multi_user 

GO

我的预期结果是一个未损坏的事务日志，它的大小适合我的数据库。让这成为一个警示故事，提醒人们在接受管理别人的错误之前提出所有问题。

Answer 1

如果您使用的是 2008 年或更早的版本，您可以尝试使用“BACKUP LOG WITH TRUNCATE_ONLY”

否则将数据库切换到简单恢复，这将清除日志。 然后运行 ​​DBCC SHRINKFILE 来缩小文件本身的大小。