在立即将其标记为重复之前，我已阅读Mike Walsh的“ 为什么事务日志保持增长或空间不足？，但我认为这无法解决我的情况。我浏览了十几个类似的问题，但相关的问题大多只是说“重复”并指出了麦克的问题。
详细信息：我在SQL Server 2008 R2上有一堆约500MB的数据库，全部处于简单恢复模式（不是我的选择），每晚进行完整备份，并具有约200MB的数据文件和约300MB的日志文件。日志不会立即增长到300MB，而是会在几个月后缓慢增长。至少根据sp_who2和活动监视器，它们中的任何一个都没有打开的事务。如果我右键单击数据库并选择属性，它会告诉我大约有50MB可用空间。特别是在备份之后，整个日志是否不应该免费？在简单模式下，只要没有未完成的事务，日志是否不应该免费？
log_reuse_wait_descfrom sys.databases说“什么都没有”，根据上面提到的问题和答案，它说它不应该等待任何东西来重用空间。
如果我执行“ DBCC SHRINKFILE”，则日志文件会缩小到1MB，因此它愿意回收空间。我可以设置一些可以每周缩小日志并防止事情失控的事情，但是我对为什么SQL Server可以做到这一点感到困惑。
我可以理解是否有一些需要300MB记录的疯狂交易，但是我们没有做任何极端的事情，只是基本的OLTP。来自Mike的问题/答案：
简单恢复模型-通过上面的介绍，最简单的是首先讨论简单恢复模型。在此模型中，您要告诉SQL Server-可以使用事务日志文件进行崩溃和重新启动恢复（您确实没有选择。在这里查找ACID属性，应该很快就可以理解），但是一旦您没有，出于崩溃/重新启动恢复目的而不再需要它，请继续并重用日志文件。
SQL Server在简单恢复中侦听此请求，并且仅保留进行崩溃/重新启动恢复所需的信息。一旦SQL Server确定它可以恢复，因为数据已经被硬化到数据文件中（或多或少），则已硬化的数据将不再在日志中被使用，并被标记为截断-这意味着它将被重新使用。
它一直在说应该重新使用日志空间，但是随着几个月来的缓慢增长，似乎并没有。
我想念什么？是否可以阻止SQL Server将数据识别为“已强化”并释放日志？
（编辑） 行动后报告-又一点知识是危险的
在发现这是一个“普遍的问题”之后，感觉就像我对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或更小），但这导致了第二项...
第二，我对原木生长的感觉是随着时间的推移逐渐变慢。但是，实际上，日志在夜间迅速增长，负责为该第三方应用程序应用补丁的人正在应用补丁。修补程序是作为单个事务完成的，因此根据修补程序，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;
这表明在某些晚上，客户不使用数据库时，日志正在增长。这导致了与应用补丁的人的对话以及谜底的答案。
再次感谢提供帮助的人，帮助我找到答案。