sql-server - 数据库事务日志满的潜在原因及解决方法

标签 sql-server database tsql sql-server-2005-express transaction-log

<分区>

在我的团队 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<br/> 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

最佳答案

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

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

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

关于sql-server - 数据库事务日志满的潜在原因及解决方法，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/13975905/