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及更高版本）。延迟事务实际上是一个活动事务，由于某些不可用资源，其回滚被阻止。有关延迟事务的原因以及如何将它们移出延迟状态的信息，请参阅延迟事务。

我误解了什么吗？

- = - = - = - UPDATE 2 - = - = - = -

刚刚启动进程，初始日志文件大小设置为30GB。这将需要几个小时才能完成。

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

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

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

感谢大家的投入。

Answer 1

要解决此问题，请将恢复模式更改为简单，然后收缩文件日志

1。 数据库属性＆gt;选项＆gt;恢复模型＆gt;简单

2。 数据库任务＆gt;收缩＆gt;文件＆gt;登录

完成。

然后检查您的db日志文件大小 数据库属性＆gt;文件＆gt;数据库文件＆gt;路径

检查完整的sql server日志：打开日志文件查看器 SSMS＆gt;数据库＆gt;管理＆gt; SQL Server日志＆gt;电流

Answer 2

我曾经遇到过这个错误，最终导致服务器的磁盘空间耗尽。

Answer 3

这是一次性脚本，还是经常出现的工作？

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

Answer 4

您是否为日志文件启用了启用自动增长和无限制文件增长？您可以在“数据库属性＆gt;文件”

中通过SSMS编辑这些内容

Answer 5

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

Answer 6

以下内容将截断日志。

USE [yourdbname] 
GO

-- TRUNCATE TRANSACTION LOG --
DBCC SHRINKFILE(yourdbname_log, 1)
BACKUP LOG yourdbname WITH TRUNCATE_ONLY
DBCC SHRINKFILE(yourdbname_log, 1)
GO

-- CHECK DATABASE HEALTH --
ALTER FUNCTION [dbo].[checker]() RETURNS int AS BEGIN  RETURN 0 END
GO

Answer 7

如果您的数据库恢复模型已满，并且您没有日志备份维护计划，则会收到此错误，因为事务日志因LOG_BACKUP而变满。

这将阻止对此数据库执行任何操作（例如收缩），并且SQL Server数据库引擎将引发9002错误。

为了克服这种情况，我建议您查看此The transaction log for database ‘SharePoint_Config’ is full due to LOG_BACKUP，其中显示了解决问题的详细步骤。

Answer 8

加上上面的答案，我还想提一下，如果可能的话，你也可以释放服务器来解决这个问题。如果由于数据库溢出而导致服务器已满，您可以从构建您的数据库的服务器中删除一些不必要的文件。至少这暂时解决了问题并让您查询数据库

Answer 9

我遇到了错误：“由于从数据库表中删除旧行以释放磁盘空间时，由于'ACTIVE_TRANSACTION'，数据库'...'的事务日志已满。我意识到，如果该数字在我的情况下，要删除的行数大于1000000。因此，我不使用1 DELETE语句，而是使用DELETE TOP（1000000）....语句划分了删除任务。

例如：

而不是使用以下语句：

DELETE FROM Vt30 WHERE Rt < DATEADD(YEAR, -1, GETDATE())

反复使用以下语句：

DELETE TOP(1000000) FROM Vt30 WHERE Rt < DATEADD(YEAR, -1, GETDATE())

Answer 10

我的问题通过多次执行受限删除（如

）解决了

之前

DELETE FROM TableName WHERE Condition

之后

DELETE TOP(1000) FROM TableName WHERECondition

Answer 11

该问题的答案不是从表中删除行，而是由于活动事务而占用的tempDB空间。这种情况通常发生在运行合并（upsert）时，我们尝试插入更新和删除事务。唯一的选择是确保将数据库设置为简单恢复模型，并将文件增加到最大空间（添加另一个文件组）。尽管这有其自身的优缺点，但这是唯一的选择。

您拥有的另一个选项是将merge（upsert）分为两个操作。一个执行插入操作，另一个执行更新和删除操作。

Answer 12

尝试一下：

USE YourDB;  
GO  
-- Truncate the log by changing the database recovery model to SIMPLE.  
ALTER DATABASE YourDB
SET RECOVERY SIMPLE;  
GO  
-- Shrink the truncated log file to 50 MB.  
DBCC SHRINKFILE (YourDB_log, 50);  
GO  
-- Reset the database recovery model.  
ALTER DATABASE YourDB
SET RECOVERY FULL;  
GO

希望对您有帮助。

Answer 13

这是我的英雄代码。我已经遇到了这个问题。并使用此代码解决此问题。

 USE master;

    SELECT 
        name, log_reuse_wait, log_reuse_wait_desc, is_cdc_enabled 
    FROM 
        sys.databases 
    WHERE 
        name = 'XX_System';

    SELECT DATABASEPROPERTYEX('XX_System', 'IsPublished');


    USE XX_System;
    EXEC sp_repldone null, null, 0,0,1;
    EXEC sp_removedbreplication XX_System;


    DBCC OPENTRAN;
    DBCC SQLPERF(LOGSPACE);
    EXEC sp_replcounters;



    DBCC SQLPERF(LOGSPACE);

Answer 14

尝试：

如果可能，请重新启动服务 MSSQLSERVER 和 SQLSERVERAGENT 。

数据库的事务日志已满

14 个答案:

尝试：