数据库中事务日志已满的潜在原因和解决方案[关闭]

Posted 2023-02-16

【中文标题】数据库中事务日志已满的潜在原因和解决方案[关闭]

【英文标题】：Potential causes and solutions for the transaction log in database being full [closed]

【发布时间】：2012-12-08 04:38:43

【问题描述】：

在我的团队 ASP.NET 应用程序的数据访问层中，我通过使用 .NET SQLClient 对我们的数据库运行存储过程。添加新代码以允许对数据库进行插入操作后，我测试了代码，并收到以下异常：

The transaction log for database 'DBName' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases

我确认在 MS SQL Server Management Studio 中尝试插入操作时收到了相同的消息。我很担心，因为我最近在数据库中添加了三个两个触发器，以基于插入和更新某些表来执行一些数据插入，并且我认为我可能会导致无限循环或类似性质的东西。

但是，根据其他在线问题的实例，这似乎不是一般由触发器或旋转查询引起的问题。我查询了log_reuse_wait 和log_reuse_wait_desc 列并返回了以下内容：

2 | LOG_BACKUP

另外，查询SELECT [name], recovery_model_desc, log_reuse_wait_desc FROM sys.databases 返回：

name | recovery_model_desc| log_reuse_wait_desc

DBName|   FULL            | LOG_BACKUP

其中第一列是log_reuse_wait，第二列是log_reuse_wait_desc。 根据msdn 上代码的定义，我需要执行日志备份，然后可以自动截断日志，以便对数据库进行进一步的操作。这是一个正确的假设吗？这可能是由错误编码的触发器引起的，还是更多的日常维护任务，由数据库上的大量事务引起？

编辑：

查询select type_desc, size, max_size from sys.database_files 返回：

   type_desc | size | max_size
1| ROWS      |  512 | -1
2| LOG       |  64  |  -1

【问题讨论】：

你知道你对这个数据库的备份策略吗？

“select type_desc, size, max_size from sys.database_files”返回什么？

是的，这就是文档所说的以及您需要做的。如果触发器添加、更新或删除，则将被记录。如果触发器不必要地添加、更新或删除，则将被不必要地记录。问题是你需要一个完整的恢复模型吗？

我相信每天都有一个自动备份的任务集，生成一个 .bak 文件。恢复模型列指示它是“完整”备份？我想。我看了看，我相信服务器已经用完了磁盘空间，所以可能阻止了根据需要生成备份，因此不允许截断事务日志？

除了 FULL 之外，还有哪些其他选项？备份与数据库相关的所有内容不是最佳做法吗？还是 FULL 也存储其他信息？

【参考方案1】：

如果您的数据库处于完全恢复模式，则日志不会被截断（截断是一个糟糕的词，我希望他们选择其他内容）直到执行日志备份。基本上，当您将数据库置于 FULL 恢复模式时，您就是在告诉 SQL Server 您需要时间点恢复。为了做到这一点，SQL Server 需要来自上次完整（或差异）备份的完整日志链，并且为了做到这一点，它不会重新使用（“截断”）日志空间，直到您备份了日志.

这是处于完全恢复模式的数据库的例行操作问题。如果您不需要时间点恢复，请将您的数据库设置为 SIMPLE 恢复模式 - 这将自动重用日志空间，但您只能恢复到上次的完整/差异备份。

如果您确实需要时间点恢复，那么您需要（嗯，您的 DBA 团队需要）设置一个定期执行日志备份的维护计划。

【讨论】：

谢谢，我相信这告诉我我需要什么。