为什么事务日志在带有夜间备份的简单恢复模式下继续增长

Question

在立即标记为重复之前，我已阅读 Mike Walsh 的《为什么事务日志不断增长或空间不足？，但我认为它没有回答我的情况。我浏览了十几个类似的问题，但相关的问题大多只是说“重复”并指向迈克的问题。

详细信息：我在 SQL Server 2008 R2 上有一堆约 500MB 的数据库，都处于简单恢复模式（不是我的选择），每晚完整备份，包含约 200MB 的数据文件和约 300MB 的日志文件。日志不会立即增长到 300MB，而是在几个月的过程中缓慢增长。至少根据 sp_who2 和活动监视器，它们中的任何一个都没有打开的事务。如果我右键单击数据库并选择属性，它会告诉我有大约 50MB 可用空间。特别是在备份之后，整个日志不应该是免费的吗？在 SIMPLE 模式下，只要没有打开的事务，日志就不应该是免费的吗？

log_reuse_wait_descfromsys.databases说“NOTHING”，根据上面引用的问题和答案说它不应该等待任何东西来重用空间。

如果我做'DBCC SHRINKFILE'，日志文件缩小到1MB，所以它愿意回收空间。我可以设置一些每周缩小日志并防止事情失控的东西，但我很困惑为什么 SQL Server 会让我这样做。

我可以理解是否有一些疯狂的事务需要 300MB 来记录它，但我们没有做任何极端的事情，只是基本的 OLTP。来自迈克的问题/答案：

简单恢复模型 - 有了上面的介绍，最容易先讨论简单恢复模型。在此模型中，您是在告诉 SQL Server - 我对您使用您的事务日志文件进行崩溃和重新启动恢复感到满意（您在那里确实别无选择。查找 ACID 属性，这应该很快就有意义），但是一旦您没有不再需要它用于崩溃/重启恢复目的，继续并重用日志文件。

SQL Server 在 Simple Recovery 中侦听此请求，并且仅保留执行崩溃/重新启动恢复所需的信息。一旦 SQL Server 确定它可以恢复，因为数据已加固到数据文件（或多或少），已加固的数据在日志中不再需要并被标记为截断 - 这意味着它会被重新使用。

它一直说日志空间应该被重用，但是随着几个月的缓慢增长，它似乎不是。

我错过了什么？是否有什么原因使 SQL Server 无法将数据识别为“硬化”并释放日志？

(编辑) 行动后报告 - AKA 一点点知识是危险的

在发现这是一个“热门问题”后，我觉得我欠了一个解释 7 个月前发生的事情以及我学到的东西，希望能挽救一些其他人的悲伤。

首先，当您查看数据库的属性时，您在 SSMS 中看到的可用空间是数据文件中的可用空间。您可以通过在数据库上运行以下命令来查看这一点，您会发现 SSMS 报告的可用空间是 FileSizeMB 和 UsedSpaceMB 之间的差异：

SELECT
    DB.name,
    MF.physical_name,
    MF.type_desc AS FileType,
    MF.size * 8 / 1024 AS FileSizeMB,
    fileproperty(MF.name, 'SpaceUsed') * 8/ 1024 AS UsedSpaceMB,
    mf.name LogicalName
FROM
    sys.master_files MF
    JOIN sys.databases DB ON DB.database_id = MF.database_id
WHERE   DB.name = 'yourdatabasename'

这确实证实了在正常情况下我们使用的日志空间很少（20MB 或更少），但这导致了第二项......

其次，我对日志增长的看法是随着时间的推移缓慢增长。然而，实际上，在负责为这个 3rd 方应用程序应用补丁的人正在应用补丁的那个晚上，日志迅速增长。补丁是作为单个事务完成的，因此根据补丁的不同，200MB 的数据需要 300MB 的日志。跟踪该事件的关键是来自 Aaron Bertrand 在https://sqlblog.org/2007/01/11/reviewing-autogrow-events-from-the-default-trace的查询

DECLARE @path NVARCHAR(260);

SELECT 
    @path = REVERSE(SUBSTRING(REVERSE([path]), 
    CHARINDEX('\', REVERSE([path])), 260)) + N'log.trc'
FROM    sys.traces
WHERE   is_default = 1;

SELECT 
   DatabaseName,
   [FileName],
    SPID,
    Duration,
    StartTime,
    EndTime,
    FileType = CASE EventClass 
       WHEN 92 THEN 'Data'
       WHEN 93 THEN 'Log'
    END
FROM sys.fn_trace_gettable(@path, DEFAULT)
WHERE
    EventClass IN (92,93)
ORDER BY
    StartTime DESC;

这表明当客户不使用数据库时，日志在某些晚上会增长。这导致了与应用补丁的人和谜团的答案的对话。

再次感谢提供帮助让我得到答案的人。

Answer 1

我们不可能猜测是什么导致了它，但 SQL Server 并不仅仅为了它而将日志文件增长到 300 MB，它增长到 300 MB，因为在上次收缩操作后的某个时刻，它需要大量日志空间（无论是由于一些大的单个事务还是许多较小的并发事务）。你必须跟踪日志文件增长事件（我在这里和这里讨论过这个）来尝试缩小发生这种情况的时间或原因（如果你的日志文件增长设置是 300 MB 或其他东西，那么它会增长 300 MB一旦它需要超过 1 MB 的空间来容纳活动事务）。

无论如何，您为什么认为一旦达到 300 MB 就需要缩小日志文件？您是否真的仔细阅读了迈克问题的所有答案？日志文件不会自行缩小，因为将日志文件缩小到 1MB - 只是为了在您最大的事务期间可以再次增长 - 完全是在浪费时间。在此期间，您打算如何处理所有这些可用空间？

Answer 2

您当前的所有测试 ( DBCC SHRINKFILE, log_reuse_wait_desc) 只是证明您现在正在适当地重用事务日志的虚拟日志文件。但是，当您的事务日志文件上发生自动增长事件时，这是对无法重用日志的反应。

通常情况下，这不是一种持续的情况（正是您目前看到的缺乏症状的情况）。即使在简单的恢复模型中，也有一些事情可能会导致这种行为。

最好的办法是设置一个数据收集作业来定期log_reuse_wait_desc为您的数据库提取数据，并定期将其记录在某处。然后，您应该能够对导致缺乏日志重用的原因进行逆向工程。

它一直说日志空间应该被重用，但是随着几个月的缓慢增长，它似乎不是。

正如我上面所指出的，这不是一般的持续状态，导致缺乏事务日志重用（节省一些角落情况下，如制作粗糙的交易），所以你必须要找准当这时代的发生。轻量级诊断数据收集应该是一个好的开始。