我一直认为sql事务日志跟踪数据库中完成的所有事务，因此它可以帮助恢复数据库文件，以防意外断电或类似的事情 那么，在正常使用中，当数据被提交并写入磁盘时，它被清除，因为mdf文件中的所有数据都很好且安全。 看到ldf文件增长并阅读一些我理解情况并非如此，它会继续增长，直到：缩小日志。 仅在此时清除所有提交的事务并缩小日志文件。我找到了一些应该这样做的sp，但是还发现了你首先必须备份数据库的理论？ 最后一步对我没有意义，所以任何人都可以告诉我这是正确的，如果是这样，为什么会这样？
答案 0 :(得分：5)
想象一下，您（或某人）在生产数据库中触发delete from very_important_table。 Sql Server愉快地删除，提交事务，并且如你所说，将“忘记”关于事务。
稍后有人会注意到数据已经消失（毕竟这是你的very_important_table）。在这种情况下，你会感谢sql Server 不忘记了事务，所以你可以将数据库恢复到（无意）删除之前的时间点！至少（如上所述）如果您使用“完全恢复”模式。
这是事务日志保留所有这些信息的原因之一。
现在，什么时候扔掉日志会“安全”？你做了备份后 - 哈哈！ Sql Server假定您将备份保存在安全的地方，这意味着它不再需要挂起日志。这就是为什么在缩小事务日志之前必须进行备份的原因。
但是我认为缩小交易日志应该是紧急情况的一部分。在正常操作中，您应该“知道”（或猜测）事务日志在一定时间内将获得多大（读取：在日志备份之间的间隔！）并为其分配那么大的空间（加上一些空间可能是一个好处）理念）。然后你禁用自动增长（或至少调整它）并设置一个警告，当交易增长“太大”时（如果你给它50％或100％的净空，你可以说你设置的大小的80％）。如果出现问题，你有时间做出反应。
记住（正如其他人写的那样）：（日志）备份不会“缩小”日志文件，只是“清空”它。您仍会在文件系统上看到相同的文件大小，但文件系统中有可用空间（DBCC SQLPERF(logspace)会显示此信息。）
如果您启用了自动增长功能，日志将在您不知道的情况下填充磁盘，并且磁盘已满 - bam - 您无法执行任何操作（在最坏的情况下甚至不备份或缩小日志！）。
我想说的是以下内容：这不是一个简单的话题。请注意！
也许这篇微软文章将提供一个起点：How to Stop the transaction log of a SQL Server database from growing unexpectedly
修改：此问题是否更适合serverfault？
答案 1 :(得分：2)
这取决于备份恢复模式。
可能在this KB article中找到您想要或需要知道的所有内容。
通过使用简单的恢复模型， 你可以恢复你的数据库 最新的数据库备份。 通过使用完整恢复模型或 大量日志恢复模型，你 可以恢复您的数据库 通过恢复发生故障时 您的数据库与事务日志 文件备份。
基本上这就是说你要么拥有不保留事务日志的简单模型（行为与你预期的一样），要么事务日志累积自备份以来的所有更改，以便通过使用备份加上日志你可以重建一切到失败点（即超过备份时刻）。
答案 2 :(得分：2)
要恢复数据库，您基本上可以执行以下操作：
出于这个原因，事务日志只需要保存自上次获取数据“快照”以来的所有事务的记录（即自那时起的最后一次完整备份+增量），以便它们一起形成一个几乎完整的记录，以便进行时间点恢复，因此，您不需要在之前备份时间的事务日志条目。
（我知道，这有点过于简单了，因为你会在发生故障后首先备份你的事务日志。另外事实上你的事务日志可能是空的，即使物理文件的大小没有改变）。 / p>
答案 3 :(得分：1)
你有数据库状态x，然后你添加事务y，然后你将事务缩减2倍，所以你只有x +（y / 2）数据库状态。除非你有备份，否则你无法解释y中丢失的一半。换句话说，总是需要备份。唯一真正的例外是，如果您在输入记录时复制数据库，并且可以在缩小事务日志时暂停这样的复制过程。
答案 4 :(得分：1)
仅供参考：当您缩小事务日志时，只会释放新事务的空间，但它不会回收文件系统上的空间。
另外，正如我输入的其他帖子所提到的那样，恢复模型起着重要作用，因为SQL Server将截断每个检查点的事务日志。