数据库的事务日志已满

我有一个长时间运行的进程，在整个持续时间内保持打开一个事务。数据库的事务日志已满

我无法控制它的执行方式。

因为事务在整个持续时间内保持打开状态，所以当事务日志填满时，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及更高版本）。延迟事务实际上是一个活动事务，其回滚由于某些不可用的资源而被阻止。有关延期交易原因以及如何将其移出延期状态的信息，请参阅延期交易。

我误解了一些东西吗？

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

刚启动了与设定为30GB初始日志文件的大小的过程。这将需要几个小时才能完成。

- = - = - = - 最后的更新 - = - = - = -

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

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

谢谢大家的意见。

来源

2013-07-16 Jimbo

重新“...并备份了日志”....如果数据库处于简单模式，您将无法备份日志，日志备份不适用于简单模式。它是否被批量记录？ – SqlACID

我备份了整个数据库并对其进行了缩小，导致日志缩小到1MB。然后，我将日志文件的大小最初增加到20GB，现在增加到30GB。 – Jimbo

这是一次性脚本还是定期发生的工作？

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

来源

2013-07-16 11:35:01

我不会说这是一项一次性工作，但我们必须这样做是很少见的。我没有创建第二个日志文件，但我确实将当前日志文件的初始大小增加到30GB。在我上次运行时，它被设置为20GB，但仍然失败。 – Jimbo

考虑到我只有一个驱动器可以使用，会有第二个日志文件比以前更好吗？ – Jimbo

现在我记得，附加文件主要使我们能够访问另一个更大的驱动器。 –

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

来源

2013-07-16 11:21:54

是的。它设置为自动增长10％，不受限制。问题是自动增长在存在未完成事务时不起作用。 – Jimbo

你知道这笔交易有多大吗？尝试设置事务日志大小大于估计值，无论如何，如果磁盘分配不是问题，请在开始时分配足够的空间以用于数据和日志。它提高了性能。不要我们*自动增长10％*，由少数几个GB来做，所以性能会足够好。 –

SQL Server *将在事务处理期间自动增长日志，如果它需要更多空间来完成该事务。 –

这是一种老派的方法，但是如果您在SQL中执行迭代更新或插入操作，而且运行很长时间，则定期（以编程方式）调用“检查点”是个好主意。调用“检查点”会导致SQL向磁盘写入所有这些仅限内存的更改（脏页面，它们被调用）以及存储在事务日志中的项目。这具有定期清理您的事务日志的效果，从而防止像所描述的问题。

来源

2013-07-16 12:17:33 Brian

不幸的是，我无法控制过程的执行方式。 Dynamics CRM是一个Microsoft应用程序，组织导入过程是该应用程序的一部分。 – Jimbo

明白...祝你好运 – Brian

以下内容将截断日志。

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

来源

2014-04-05 14:43:26 Pinal

嘿Pinal，这个功能从SQL Server 2008和以上版本完全删除：http://www.brentozar.com/archive/2009/08/backup-log-with-truncate-only-in -sql-server-2008/ – Conor

对于更高版本，请尝试备份日志 TO DISK = N'NUL：' – HansLindgren

我有这个错误一次，它最终成为服务器的硬盘驱动器用完磁盘空间。

来源

2014-06-05 13:59:18 PretoriaCoder

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

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

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

完成。

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

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

来源

2014-07-14 03:16:34 user3774600

不，这不能解决问题。问题在于日志文件在长时间运行过程中增长，直到磁盘空间用完。通过将日志文件临时移到另一个具有1TB可用空间的驱动器进行更正。您正在进行一项长时间运行的流程 - 即保持打开一个事务 - 的过程中，您无法收缩日志文件。这个过程全权负责文件的增长。 – Jimbo

正如@Jimbo所说，这并不能解决OP的问题。它可能释放一些当前未使用的空间，但一旦长时间交易再次运行，空间将再次被占用（甚至可能更早失败） – Marcel

完美！谢谢！ –

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

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

为了克服这种行为，我建议你检查这个The transaction log for database ‘SharePoint_Config’ is full due to LOG_BACKUP，它显示了解决问题的详细步骤。

来源

2016-07-06 00:04:05 DevoWorx

数据库的事务日志已满

回答

相关问题