SQL Server：巨大的日志文件，我们知道原因，但我们能做些什么

Question

我们有这个每天完全备份的 SQL Server 数据库。最近我们注意到这个数据库的 LOG 文件很大（> 50 GB）。我做了一些研究，我发现这是因为我们没有记录事务日志。

所以我知道为什么我的日志这么大，但我想知道我能做些什么。

说明：我们希望对常规事务日志备份使用“完整”恢复选项。我们意识到我们现在不是正确的，一旦我们可以将事务日志调整到合理的大小，就会解决这个问题。

理想的路线是进行日志备份，然后执行 aDBCC Shrink将文件缩小到正常大小。但是，如果我在数据库的完整备份上执行此操作，则需要几秒钟并创建 5 GB 的日志备份并将事务日志缩小到几 MB。

如果我在生产环境中执行此操作，则需要很长时间，而且似乎创建的文件要大得多。我估计这将是大约 50 GB。我有什么办法可以解决这个问题，因为服务器没有另外 50 GB，所以不能以这种方式进行日志备份。

由于我们没有进行常规日志备份，所以我想我们每天只有一个恢复点（每晚进行完整备份），所以有没有办法删除日志并在另一个中释放 50 GB 的日志文件道路？

或者在这种情况下，您是否还有其他可能对我有帮助的选择？

Answer 1

您已经说过它当前处于 FULL 恢复模式，并且您想保持这种状态，但是您没有说您是否可能需要回滚到今天之前的任何时间点。

这是您的两个选择：

1. 如果您可能需要恢复到过去的某个时间点，则需要完全备份现有的（巨大的）tran 日志（并保留备份文件）。所以继续运行那个 tran 日志备份。是的，这将需要很长时间，是的，它将需要大量磁盘空间。但是一旦完成，每个新的 tran 日志备份都会小而快，并且只包含上次成功日志备份的事务。您将能够将日志缩​​小到合理的范围。

2. 如果你不期待永远需要回滚到前一个点的时间（例如，如果灾难发生，你只是恢复反正每晚之前完全备份的一个），而你只关心未来可能的点式-time 恢复，然后切换到 SIMPLE，缩小日志，切换回 FULL，运行完整备份，然后开始日志备份。这将清除已完成交易的巨大积压。

明确地说，SIMPLE 和 FULL 恢复模式都允许您恢复到任何先前的完整（或差异）备份。完整恢复模式允许您恢复到两次完整备份之间的中间点。

因此，假设您的夜间完整备份发生在晚上 8 点，并且您的数据库在第二天上午 10 点发生了不可挽回的损坏或数据被意外删除。使用 SIMPLE 模式（或没有可用的 tran 日志备份），您唯一的选择是恢复前一天晚上 8 点的完整备份。使用完全恢复模式（如果您已经采取并保留了 tran 日志备份），您可以将数据库恢复到问题发生前的上午 9 点 59 分 59 秒。

当然，如果您根本不需要时间点恢复（这是一个报告或处理数据库，您可以在其中简单地恢复完整数据，然后重新导入/重新处理来自其他来源的所有后续数据），那么您只需切换到 SIMPLE 模式完全忘记日志备份（尽管 SQL 仍然使用 tran 日志来处理正在进行的事务，然后在它们完成时标记空间以供重用）。

但这是一个商业决策，而不是技术决策。与您的经理或业务利益相关者交谈。

Answer 2

如果您只想每天备份一次并进行完整备份。
将数据库置于 SIMPLE 恢复模式并收缩日志文件，然后让它处于 SIMPLE 恢复模式。
这样日志文件的大小就会减小。

USE [master]
GO
ALTER DATABASE [myDB] SET RECOVERY SIMPLE WITH NO_WAIT
DBCC SHRINKFILE (N'myDB_Log' , 0)
GO

之后，如果您希望进行事务备份，
只需将其恢复为完整恢复模式，
进行完整（或差异）备份并开始事务备份。

另请注意，如果您启用了镜像或始终开启，则此功能将不起作用。
您可能必须取消镜像或暂停镜像才能实现这些操作。