Question

在我的团队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。根据{{3}}上代码的定义，我需要执行日志备份，然后日志可以自动截断，从而允许对数据库进行进一步操作。这是正确的假设吗？这是由错误编码的触发器引起的，还是更多的例行维护任务，是由数据库上的大量事务引起的？

编辑：

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

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

Answer 1

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

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

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

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

1 个答案: