我有一个长时间运行的进程，该进程在整个持续时间内保持打开的事务。
我无法控制其执行方式。
由于事务在整个持续时间内保持打开状态，因此当事务日志填满时，SQL Server 无法增加日志文件的大小。
因此该过程失败并出现错误 "The transaction log for database 'xxx' is full" .
我尝试通过增加数据库属性中事务日志文件的大小来防止这种情况发生，但我得到了同样的错误。
不确定下一步应该尝试什么。这个过程要持续几个小时，所以要反复试验并不容易。
有什么想法吗？
如果有人感兴趣，该过程是 Microsoft Dynamics CRM 4.0. 中的组织导入
有足够的磁盘空间，我们将日志设置为简单日志记录模式，并在开始进程之前备份了日志。
-=-=-=-=-更新-=-=-=-=-
感谢大家迄今为止的评论。以下是让我相信日志不会因开放事务而增长的原因:
我收到以下错误...
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，但它仍然用完了所有空间，最终失败了。
我之前没有意识到这种情况发生，因为当该进程运行过夜时，它会在失败时回滚。这次我能够在回滚之前检查日志文件大小。
感谢大家的意见。
最佳答案
要解决此问题，请将恢复模式更改为简单，然后压缩文件日志
1. 数据库属性 > 选项 > 恢复模型 > 简单
2. 数据库任务 > 收缩 > 文件 > 日志
完成。
然后检查您的数据库日志文件大小 数据库属性 > 文件 > 数据库文件 > 路径
要检查完整的 sql server 日志:打开日志文件查看器 SSMS > 数据库 > 管理 > SQL Server 日志 > 当前
关于sql - 数据库的事务日志已满，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/17674973/