交易日志会在SQL Server中自动收缩吗？

Question

当SQL Server数据库处于简单模式时，您不必关心事务日志bakcups。但是在简单的模式下，事务日志似乎像在完整模式下一样增长。在某个时间点是否会自动截断？还是我必须手动截断/收缩？

Answer 1

它会自动截断，但这与收缩截然不同。截断为重复使用而收回日志空间，从物理上缩小了文件大小以将空间释放回操作系统。如果您的日志已增长到当前的大小，则可能会缩小它会再次增长。

我建议您了解系统的典型和最大日志使用情况。可以手动运行下面的查询（不是我的Glen Berrys DMV脚本），也可以通过代理作业将输出捕获到表中。如果您将其记录到桌子上一周左右，则将获得典型用法的图片，更重要的是，当过程导致日志超出您的期望时。

SELECT 
     db.[name] AS [Database Name]
   , db.recovery_model_desc AS [Recovery Model]
   , db.log_reuse_wait_desc AS [Log Reuse Wait Description]
   , ls.cntr_value AS [Log Size (KB)]
   , lu.cntr_value AS [Log Used (KB)]
   , CAST(
        CAST(lu.cntr_value AS FLOAT) / CAST(ls.cntr_value AS FLOAT) 
        AS DECIMAL(18,2)
     ) * 100 AS [Log Used %]
   , db.[compatibility_level] AS [DB Compatibility Level]
   , db.page_verify_option_desc AS [Page Verify Option]
   , db.is_auto_create_stats_on, db.is_auto_update_stats_on
   , db.is_auto_update_stats_async_on, db.is_parameterization_forced
   , db.snapshot_isolation_state_desc, db.is_read_committed_snapshot_on
FROM sys.databases AS db
   INNER JOIN sys.dm_os_performance_counters AS lu 
     ON db.name = lu.instance_name
   INNER JOIN sys.dm_os_performance_counters AS ls 
     ON db.name = ls.instance_name
WHERE lu.counter_name LIKE N'Log File(s) Used Size (KB)%' 
   AND ls.counter_name LIKE N'Log File(s) Size (KB)%'
   AND ls.cntr_value > 0 
OPTION (RECOMPILE);

事务日志截断 描述何时和为什么发生对数截断的原因。

如果从交易日志中从未删除日志记录，它将最终填充物理日志文件可用的所有磁盘空间。日志截断将在逻辑日志中自动释放空间，以通过事务日志重复使用。

可能延迟日志截断的因素 是理解为什么您的日志可能无法截断并因此比预期大的有用参考。

Answer 2

不，不

• 它不会收缩或截断（从物理LDF意义上，它将在逻辑上做到）
• 它必须是那样的大小，所以你不缩小它

如果收缩，它将再次增长，您将有一个零碎的文件

Answer 3

如前所述，不，它不会自动缩小。它会清理一些垃圾。

原因是，在完整的恢复模型中，您告诉SQL您想对时间点恢复进行TLOG备份，因此它可以保留针对数据库进行的所有交易的记录。

由于您告诉它，您需要时间恢复点，因此需要进行完整的备份和TLOG备份。当您完成TLOG备份时，它将冲洗日志内容（除尾端）并重新开始。

如果您将这些文件视为容器，可能会有所帮助。

我的建议是，如果Tlogs变得庞大且难以管理，请削减完整的备份。切换到 简单的 恢复模型和 收缩 TLOG文件。切换回完整的恢复模型，并执行碎片维护*。像其他人一样，这并不是最好的做法，并且会导致高水平的分裂。

在那之后计划并开始备份制度。

---

* 索引重建/重组操作和磁盘级碎片整理. 。这不是日志维护的一部分：您可以通过备份来维护t日志。它们是在接近容量时生长的容器。重建/重组可以帮助从不正确的日志管理中恢复，从而导致大量使用。