在立即标记为重复之前，我已阅读 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 …