为什么我不能在完全恢复模式下缩小日志文件

Question

我有一个 302MB 的日志文件。

我做了一个日志备份，它使日志文件大部分都是免费的（我可以通过磁盘使用标准报告看到这一点）

如果我试着跑

DBCC SHRINKFILE (N'AdventureWorks2014_Log' , 0, TRUNCATEONLY)

或者

DBCC SHRINKFILE (N'AdventureWorks2014_Log' , 0)

该文件仍显示为 302MB。

我知道我可以将数据库更改为简单恢复，然后运行上述命令之一并设置回完全恢复（然后进行完全备份以确保数据库未处于伪简单恢复模式）

但是，为什么我不能在完全恢复模式下缩小文件？

我知道收缩不是你应该做的事情，但在我现实世界的数据库中，因为没有人备份过它已经增长到 30GB 的事务日志，现在已经实施了定期日志备份以防止这个级别的增长

Answer 1

但是，为什么我不能在完全恢复模式下缩小文件？

它按设计工作。您只需要更多地了解正在发生的事情，这样您就可以决定要采取的适当措施。

那，或者你只是想在错误的时间缩小它（见我下面的注释#7）。

首先，“日志文件”有点用词不当：SQL 使用事务日志作为它所做的一切的“工作空间”，因此它的大小总是非零。根据我的经验，我通常希望 tran 日志在数据文件大小的 10% 到 25% 之间，具体取决于您使用的恢复模式以及数据库上的活动类型。你没有提到你的数据文件的大小，所以我无法判断 302MB 是否大（坦率地说，对我来说听起来不是很大）。

关于恢复模式，这里的关键问题是：如果您必须恢复数据库（由于紧急情况），您是否需要“时间点”恢复？还是恢复到最新的完整备份就足够了？

撇开一些不寻常的情况（复制/CDC/镜像/可用性组），您的恢复模式选择更多的是业务决策，而不是技术决策。在任何一种模式下，SQL Server 都将事务日志用于进程内事务，不同之处在于接下来会发生什么：

• 完全恢复模式：当交易完成时，它坚持围绕在移植日志，直到你执行事务日志备份。这往往会使日志更大（取决于您运行日志备份的频率），但这意味着您可以在发生灾难时进行“时间点”恢复：您可以恢复最新的完整备份，然后使用tran 日志备份“前滚”到灾难发生之前。
• 简单恢复模式：当一个事务完成时，它在 tran 日志中使用的空间可以立即供以后的事务重新使用。这使事务日志文件（相对）较小，但意味着在发生灾难时您唯一的选择是从最新的完整备份恢复。

在某些公司中，您将对所有生产数据库使用 FULL，对所有 QA/DEV 环境使用 SIMPLE。或者，某些特定的数据库（例如用于报告和/或数据处理的数据库）不需要完全恢复，因为您只需重新运行前一天的处​​理即可恢复最新状态。但就像我说的，这是一个业务决策/风险分析问题，而不是真正的技术问题。

因此，如果您不需要时间点恢复，请将其切换到简单模式，并保持原样。

如果您确实需要时间点恢复，则将其切换到完整模式，并根据您的业务风险/恢复需求全天运行定期的 tran 日志备份。每小时很受欢迎，但有些人更频繁地推荐它们。

我之前提到的最后一点：一旦您选择了正确的恢复模式，您可能仍然需要缩小过大的日志。需要牢记以下几点：

1. 再次确保您选择了正确的恢复模式
2. 如果您在 FULL 模式下运行，请确保您经常运行 tran 日志备份
3. 为日志选择一个合理的目标大小，切勿尝试将其缩小为零。我通常根据数据文件的总大小（或至少是数据文件中的已用空间）来缩放它
4. 阅读并理解有关 VLF 大小的重要建议。这可能会提供有关决定合理日志大小的更多指导，或者为您提供更好的方法来使日志达到​​该大小。
5. 从不使用SHRINKDATABASE，一直使用SHRINKFILE
6. 在简单模式和完整模式下，都有可能SQL 当前正在将日志文件的末尾用于活动事务。如果是这样，那么它不会像你想要的那样缩小。几分钟后再次缩小它，如果交易完成，第二次应该会更好。
7. 在完全恢复模式下有一个特别顽固的 tran 日志，我很幸运这样做SHRINKFILE，紧接着是事务日志备份，紧接着是另一个SHRINKFILE.

Answer 2

如果您使用完整恢复模型，根据定义，您需要事务日志备份。如果您不需要它们，那么拥有完整恢复模型是没有用的。

你不应该以你的方式收缩。此外它还会降低性能。

我建议进行事务日志备份，然后决定是否需要完整备份或可以转到简单恢复模型。

此外，您还可以使用 dm_exec_sessions 检查活动事务，并查看索引上的碎片级别，看看是否有一些配置对收缩没有帮助。