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

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

编辑:

查询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团队需要)设置维护计划,以便定期执行日志备份.