详细信息：我在SQL Server 2008 R2上有一堆约500MB的数据库，全部以简单恢复模式（不是我的选择）进行，每晚进行完整备份，其中包含约200MB的数据文件和约300MB的日志文件。日志不会立即增长到300MB，而是会在几个月后缓慢增长。至少根据sp_who2和活动监视器，它们中的任何一个都没有打开的事务。如果我右键单击数据库并选择属性，它将告诉我大约50MB的可用空间。特别是在备份之后，整个日志是否不应该免费？在简单模式下，只要没有未完成的交易，日志就不应该免费吗？
如果我做'DBCC SHRINKFILE'，日志文件会缩小到1MB，所以它愿意回收空间。我可以设置一些可以每周缩小日志并防止事情失控的事情，但是我对为什么SQL Server会让我这样做感到困惑。
我可以理解是否有一些问题需要300MB记录的疯狂交易，但我们没有做任何极端的事情，只是基本的OLTP。来自Mike的问题/答案：
简单恢复模型-通过上面的介绍，最简单的是首先讨论简单恢复模型。在此模型中，您要告诉SQL Server-可以使用事务日志文件进行崩溃和重新启动恢复（您确实没有选择。在这里查找ACID属性，应该很快就可以理解），但是一旦您没有，出于崩溃/重新启动恢复目的而不再需要它，请继续并重用日志文件。
SQL Server在简单恢复中侦听此请求，并且仅保留进行崩溃/重新启动恢复所需的信息。一旦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或更少），但这导致了第二项...
第二，我对原木生长的感觉是随着时间的推移逐渐变慢。但是，实际上，日志在夜间迅速增长，负责为该第三方应用程序应用补丁的家伙正在应用补丁。修补程序是作为单个事务完成的，因此，根据修补程序，200MB数据需要300MB日志。跟踪下来的关键是来自Aaron Bertrand在https://sqlblog.org/2007/01/11/reviewing-autogrow-events-from-the-default-trace的查询。 br />
这表明在某些晚上，客户不使用数据库时，日志正在增长。这导致了与那个应用补丁的人的对话以及答案的奥秘。
#1 楼
我们无法猜测是什么原因造成的，但是SQL Server不仅将日志文件增加到300 MB，还增加到300 MB，因为自上次收缩操作以来的某个时刻，它需要大量的日志空间（无论是由于某个大的单个事务还是许多较小的并发事务）。您必须跟踪日志文件增长事件（我在这里和这里讨论过），以尝试缩小发生这种情况的时间或原因（同样，如果您将日志文件增长设置设置为300 MB左右，那么它将增长300 MB）一旦它需要超过1 MB的空间来容纳活动的事务。实际上，您是否完整地阅读了麦克的问题的所有答案？日志文件不会自动缩小，因为将日志文件缩小到1MB（这样就可以在最大事务中再次增长）是完全浪费时间的。同时，您将如何处理所有可用空间？评论
我认为我们没有做任何需要300MB日志的事情，但是即使这样做，一旦完成，它也不会显示为数据库的可用空间吗？在SQL Server Management Studio中查看数据库上的属性时，大小是数据和日志的大小，我希望可用空间是数据和日志的可用空间。日志中的可用空间不会显示吗？它没有显示为免费，似乎仍在使用中，但是数据库上没有任何活动。
–DerekCate
14年8月13日在17:07
不，一旦完成，它不会自动成为可用空间。提交的事务不会被清零，它们的空间只是被标记为可供重用。
–亚伦·伯特兰（Aaron Bertrand）
14年8月13日在17:08
@DerekCate“我认为我们没有做任何需要300MB日志的事情” ...您会惊讶的是，绑定事务日志的重用并不需要太多时间。不要从工作量的角度考虑它，因为这并不总是原因。
–托马斯·斯金格
14年8月13日在17:12
好的，为了确认我正确理解了这一点，即使当前不需要，300MB日志也不会显示为可用空间，而是可以重用。在某个时候，它需要300MB的空间来处理某些事务。好吧，有新东西要研究。谢谢！
–DerekCate
14年8月13日在17:20
要考虑的另一件事：仅当日志已满70％时，才会对简单恢复数据库的自动检查点进行排队。因此，根据时间的不同，您可能不需要太多的日志活动来导致增长。
–保罗·怀特♦
14年8月14日在6:43
#2 楼
您当前的所有测试（DBCC SHRINKFILE，log_reuse_wait_desc）都只是在证明您现在正在适当地重用事务日志的虚拟日志文件。但是，当您的自动增长事件发生在事务日志文件上时，是对日志无法重用的一种反应。通常，这不是一个持续的情况（确切地说，这看起来是对的）现在没有您当前看到的症状）。即使在简单的恢复模型中，也有很多事情会导致此问题。
最好的选择是设置一个数据收集作业，以常规方式为您的数据库提取
log_reuse_wait_desc，并定期进行日志记录。这个地方。然后，您应该能够对导致缺乏日志重用的原因进行反向工程。一直在说应该重用日志空间，但是随着几个月的增长缓慢，但事实并非如此。
如上所述，通常不是导致缺乏事务日志重用的持续状态（保存一些特殊情况，例如已构建的交易），因此您必须查明发生这种情况的时间。轻量级的诊断数据收集应该是一个好的开始。
评论
如果他看到50MB的可用空间和300MB的日志，那么fn_DBLOG（）会为他提供一些有关增加日志大小的见解？
–肯尼斯·费舍尔
14年8月13日在18:05
#3 楼
您是否在数据库上启用了自动收缩功能？和/或您是否安排了执行维护计划以执行索引重建？
自动收缩后再进行索引维护会产生大量日志。
如果存在诸如GUID上的聚集索引之类的数据库设计问题，则索引维护本身也将产生大量日志量。
评论
数据库上未启用自动收缩功能，我们希望避免索引碎片brentozar.com/archive/2009/08/…。我们确实进行了每周完整性检查，但是我认为没有任何索引重建工作，我必须对此进行研究。除此之外，没有GUID，每个表都有一个标识列作为主键。
–DerekCate
2014年8月14日12:31
#4 楼
create table #dblog (Databasename varchar(100),
logsize float,
logspace%] float,
[Status] int)
insert into #dblog
EXEC ('DBCC sqlperf(logspace)')
select * from #dblog
alter table #dblog
add [lgspace used GB] float;
update #dblog
set [lgspace used GB ] = (logsize*[logspace%]/1024)
update #dblog
set [logsize] =([logsize]/1024)
alter table #dblog
drop column [Status];
select * from #dblog
drop table #dblog
评论
实际上，我本人在具有SIMPLE恢复模型的客户站点数据库之一中也观察到了类似现象。日志还没有增长（但是无论如何），但是日志文件中的已用空间每天晚上确实会增长一点点。它在数据库备份运行时发生。我还没有弄清楚是什么原因造成的，也没有发现是不是问题。