数据库的事务日志已满

Question

我有一个长时间运行的进程,可以在整个持续时间内保持打开一个事务.

我无法控制执行方式.

由于事务在整个持续时间内保持打开状态,因此当事务日志填满时,SQL Server无法增加日志文件的大小.

因此该过程因错误而失败"The transaction log for database 'xxx' is full".

我试图通过增加数据库属性中的事务日志文件的大小来防止这种情况,但我得到了相同的错误.

不确定我接下来应该尝试什么.这个过程持续了几个小时,因此不容易进行反复试验.

有任何想法吗？

如果有人感兴趣,该过程是组织导入 Microsoft Dynamics CRM 4.0.

有足够的磁盘空间,我们有简单的日志记录模式,并在启动进程之前备份了日志.

- = - = - = - = - UPDATE - = - = - = - = -

感谢所有评论到目前为止.以下是让我相信日志因开放交易而不会增长的原因:

我收到以下错误...

Import Organization (Name=xxx, Id=560d04e7-98ed-e211-9759-0050569d6d39) failed with Exception:
System.Data.SqlClient.SqlException: The transaction log for database 'xxx' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases

所以按照这个建议,我去了" log_reuse_wait_desc column in sys.databases"并且它保持了值" ACTIVE_TRANSACTION".

根据微软的说法:http: //msdn.microsoft.com/en-us/library/ms345414(v = sql.105).aspx

这意味着以下内容:

事务处于活动状态(所有恢复模型).•日志备份开始时可能存在长时间运行的事务.在这种情况下,释放空间可能需要另一个日志备份.有关详细信息,请参阅本主题后面的"长时间运行的活动事务".

•延迟事务(仅限SQL Server 2005 Enterprise Edition及更高版本).延迟事务实际上是一个活动事务,由于某些不可用资源,其回滚被阻止.有关延迟事务的原因以及如何将它们移出延迟状态的信息,请参阅延迟事务.

我误解了什么吗？

- = - = - = - 更新2 - = - = - = -

刚刚开始,初始日志文件大小设置为30GB.这将需要几个小时才能完成.

- = - = - = - 最终更新 - = - = - = -

问题实际上是由消耗所有可用磁盘空间的日志文件引起的.在最后一次尝试中,我释放了120GB,它仍然使用了所有这些并最终失败了.

我之前没有意识到这种情况发生了,因为当这个过程在一夜之间运行时,它就会在失败时回滚.这次我能够在回滚之前检查日志文件大小.

谢谢大家的意见.

Answer 1

要解决此问题,请将Recovery Model更改为Simple,然后将Shrink Files Log更改为

1. 数据库属性>选项>恢复模型>简单

2. 数据库任务>收缩>文件>日志

完成.

然后在数据库属性>文件>数据库文件>路径中检查数据库日志文件大小

要检查完整的sql server日志:在SSMS>数据库>管理> SQL Server日志>当前打开日志文件查看器

Answer 2

我有一次这个错误,它最终成为服务器的磁盘空间不足的硬盘驱动器.

Answer 3

这是一次性脚本,还是经常发生的工作？

过去,对于暂时​​需要大量空间用于日志文件的特殊项目,我创建了第二个日志文件并使其变得庞大.项目完成后,我们删除了额外的日志文件.

Answer 4

您是否为日志文件启用了" 启用自动增长和无限制文件增长"？您可以在"数据库属性>文件"中通过SSMS编辑这些

Answer 5

这是一种旧式的方法,但是如果你在SQL中执行迭代更新或插入操作,这是长时间运行的,那么定期(以编程方式)调用"checkpoint"是个好主意.调用"checkpoint"会导致SQL将所有那些仅限内存的更改(脏页,它们被调用)和存储在事务日志中的项写入磁盘.这样可以定期清理事务日志,从而防止出现上述问题.