SQL Server事务日志被填满的原因是啥

Posted 2023-03-26

错误描述：数据库的事务日志已满。若要查明无法重用日志中的空间的原因 ，请参阅sys.databases 中的 log_reuse_wait_desc 列 。
首先引入一下事务日志的概念
事务日志是一个与数据库文件分开的文件。它存储对数据库进行的所有更改，并全部记录插入、更新、删除、提交、回退和数据库模式变化。事务日志还称作前滚日志或重做日志。
事务日志是备份和恢复的重要组件，也是使用 SQL Remote 或 [复制代理] 复制数据所必需的。
在缺省情况下，所有数据库都使用事务日志。事务日志的使用是可选的，但是，除非您因特殊原因而不使用，否则您应始终使用它。运行带有事务日志的数据库可提供更强的故障保护功能、更好的性能以及数据复制功能。
引发异常的原因：
a.未提交的事务
b.非常大的事务
c.操作：DBCC DBREINDEX 和 CREATE INDEX
d.在从事务日志备份还原时
e.客户端应用程序不处理所有结果
f.查询在事务日志完成扩展之前超时，您收到假的“Log Full”错误消息
g.未复制的事务
解决办法：
1.释放磁盘空间（菜鸟适用）；
2.把数据库移到内存充足的磁盘（原理同上）；
3.清空日志：DUMP TRANSACTION 库名 WITH NO_LOG；
4.截断事务日志：BACKUP LOG 库名 WITH NO_LOG； 参考技术A

执行一个超大的单事务，例：

删除一张大表数据

Microsoft SQL Server - 事务日志已满是啥意思？

【中文标题】Microsoft SQL Server - 事务日志已满是啥意思？

【英文标题】：Microsoft SQL Server - What does it mean that a Transaction Log is Full?Microsoft SQL Server - 事务日志已满是什么意思？

【发布时间】：2010-09-23 01:43:09

【问题描述】：

事务日志已满是什么意思？我将文件设置为在需要时增长 20%。我的驱动器上还剩 4GB。如何永久解决此问题？ 运行这些命令可以暂时解决问题：

DBCC SHRINKFILE('MyDatabase_log', 1) 使用 TRUNCATE_ONLY 备份日志 MyDatabase DBCC SHRINKFILE('MyDatabase_log', 1)

【问题讨论】：

表示事务日志已满。劲！忍不住了。

【参考方案1】：

另一个简单的答案是您的备份可能没有安排。在升级周期中，我们的数据库备份计划之一已从作业中删除。日志一直在增长，直到我们发现备份没有运行。

【参考方案2】：

有许多不同的方法可以解决这个问题。这取决于您的备份要求。

主要问题是您的事务日志没有定期备份，导致事务日志不断增长。

SQL Server 2005 有一个简单恢复模式（数据库本身的属性/选项），我主要在不需要每小时快照的 DEV 和 TEST 环境中使用它，事务日志只会增长足以处理服务器上运行的最大事务。此恢复模式不需要计划或维护计划。

在 SQL Server 2000 中，您基本上有一个计划备份脚本，该脚本运行您使用的相同命令，大约每小时一次：

BACKUP LOG MyDatabase WITH TRUNCATE_ONLY

对于生产环境，我们通常会在数据库维护计划中安排每小时一次的事务日志备份和每天一次的完整备份。这样可以将事务日志截断到合理的大小（显然，这个大小可以保存 1 小时的事务数据）。

【参考方案3】：

您必须备份事务日志而不仅仅是数据库，否则日志将继续增长，直到您用完空间。

【参考方案4】：

事务日志是 SQL 服务器“记录”它所做的每一个更改的地方，因此如果出现问题（从软件崩溃到电源故障，再到小行星撞击……也许不是小行星撞击），它可以通过“撤消”自上次一致的“检查点”以来所做的所有更改来“恢复” - 回到数据库的最后一次“一致”状态......在那个检查点。每次事务完成（或“提交”）时，已存储在事务日志中的所有更改都被标记为“ok”，并且 CheckPopint 标记允许在这些更改之后向前移动，以便将来恢复之后只会“撤消”更改到某个点。发生这种情况后，不再需要从检查点之前的事务日志中的所有条目从系统崩溃中恢复……但仍然可能需要它们从硬盘崩溃中恢复，所以……

正如另一位先生所提到的，您在服务器上设置的“恢复模型”控制了在检查点之前对事务日志条目的影响。在简单模式下，它们会在检查点发生时被删除，但如果主数据磁盘崩溃，您将面临风险，因为您的事务日志不会包含自上次备份以来写入磁盘的更改。

在其他恢复模式中，在您进行备份之前不会删除事务日志条目，从而保护您免受此风险...

所以，一般来说，当这个问题发生时，这是因为服务器处于设置的“正常”（不简单）恢复模式之一（增量或完整）并且他们没有进行备份......。在这种情况下，交易日志一直在增长……而且在增长……有点像电视上的前列腺广告……

【讨论】：

您对事务日志的解释不正确。每次使用来自已提交事务的所有未写入更改更新数据文件时，都会将检查点写入事务日志。在恢复时（这意味着每次启动 SQL Server），服务器都会查找最后一个检查点。在检查点和日志结尾之间提交的每个事务都被重做。从未提交的事务将被忽略。

@Guge，为什么要重做已提交并写入磁盘的事务？并且从未提交的事务不能被忽略，它们需要回滚！

【参考方案5】：

听起来您没有适当的备份策略。执行任何备份（完整备份、差异备份或事务日志）都将截断日志，另外还有一个好处是可以保存一个点，以便在发生故障时从中恢复。您可以运行数据库维护向导来帮助您设置定期运行的备份计划。

如果你真的根本不关心你的数据（在这种情况下，我想知道你为什么有一个数据库），那么你可以将数据库的恢复模式设置为“简单”，这将阻止 TLog完全增长。

最后一件事：如果您正在执行批量加载操作，您可能还会考虑在执行批量操作时更改为“Bulk-Logged”。

【参考方案6】：

经常备份，每次备份数据库都会清除事务日志。

【讨论】：

不，不是。您必须备份事务日志而不是数据库。

【参考方案7】：

我不会实现 20% 的增长率。当它需要增长时，这可能会产生重大影响。如果它曾经增长到，比如说，100GB，它必须在下一次增长时增长 20GB - 准备好让你的系统变慢，而不是在这种情况发生时......相反，我会将它设置为固定速率 - 比如 100MB .当然，我们不知道当前的尺寸来做出更准确的建议。

【参考方案8】：

您应该查看SQL Server Recovery models。简短的回答是将恢复模式更改为“简单”，但这对备份/恢复有影响。

【讨论】：

对恢复没有影响，每次启动 SQL Server 时都会发生这种情况，但对恢复有影响。