Sql ошибка transaction log is full

I have a long running process that holds open a transaction for the full duration.

I have no control over the way this is executed.

Because a transaction is held open for the full duration, when the transaction log fills, SQL Server cannot increase the size of the log file.

So the process fails with the error "The transaction log for database 'xxx' is full".

I have attempted to prevent this by increasing the size of the transaction log file in the database properties, but I get the same error.

Not sure what I should try next. The process runs for several hours so it’s not easy to play trial and error.

Any ideas?

If anyone is interested, the process is an organisation import in Microsoft Dynamics CRM 4.0.

There is plenty of disk space, we have the log in simple logging mode and have backed up the log prior to kicking off the process.

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

Thanks all for the comments so far. The following is what led me to believe that the log would not grow due to the open transaction:

I am getting the following error…

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

So following that advice I went to «log_reuse_wait_desc column in sys.databases» and it held the value «ACTIVE_TRANSACTION«.

According to Microsoft:
http://msdn.microsoft.com/en-us/library/ms345414(v=sql.105).aspx

That means the following:

A transaction is active (all recovery models).
• A long-running transaction might exist at the start of the log backup. In this case, freeing the space might require another log backup. For more information, see «Long-Running Active Transactions,» later in this topic.

• A transaction is deferred (SQL Server 2005 Enterprise Edition and later versions only). A deferred transaction is effectively an active transaction whose rollback is blocked because of some unavailable resource. For information about the causes of deferred transactions and how to move them out of the deferred state, see Deferred Transactions.

Have I misunderstood something?

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

Just kicked off the process with initial log file size set to 30GB. This will take a couple of hours to complete.

-=-=-=- Final UPDATE -=-=-=-

The issue was actually caused by the log file consuming all available disk space. In the last attempt I freed up 120GB and it still used all of it and ultimately failed.

I didn’t realise this was happening previously because when the process was running overnight, it was rolling back on failure. This time I was able to check the log file size before the rollback.

Thanks all for your input.

title description author ms.author ms.date ms.service ms.subservice ms.topic helpviewer_keywords

Troubleshoot full transaction log error 9002

Learn about possible responses to a full transaction log in SQL Server and how to avoid the problem in the future.

MashaMSFT

mathoma

09/14/2021

sql

supportability

troubleshooting

logs [SQL Server], full

troubleshooting [SQL Server], full transaction log

9002 (Database Engine error)

transaction logs [SQL Server], truncation

back up transaction logs [SQL Server], full logs

transaction logs [SQL Server], full log

full transaction logs [SQL Server]

[!INCLUDE SQL Server]

Option 1: Run the steps directly in an executable notebook via Azure Data Studio

[!NOTE]
Before attempting to open this notebook, check that Azure Data Studio is installed on your local machine. To install, go to Learn how to install Azure Data Studio.

[!div class=»nextstepaction»]
Open Notebook in Azure Data Studio

Option 2: Follow the step manually

This topic discusses possible responses to a full transaction log and suggests how to avoid it in the future.

When the transaction log becomes full, [!INCLUDEssDEnoversion] issues a 9002 error. The log can fill when the database is online, or in recovery. If the log fills while the database is online, the database remains online but can only be read, not updated. If the log fills during recovery, the [!INCLUDEssDE] marks the database as RESOURCE PENDING. In either case, user action is required to make log space available.

[!NOTE]
This article is focused on SQL Server. For more specific information on this error in Azure SQL Database and Azure SQL Managed Instance, see Troubleshooting transaction log errors with Azure SQL Database and Azure SQL Managed Instance. Azure SQL Database and Azure SQL Managed Instance are based on the latest stable version of the Microsoft SQL Server database engine, so much of the content is similar though troubleshooting options and tools may differ.

Common reasons for a full transaction log

The appropriate response to a full transaction log depends on what conditions caused the log to fill. Common causes include:

  • Log not being truncated
  • Disk volume is full
  • Log size is set to a fixed maximum value or autogrow is disabled
  • Replication or availability group synchronization that is unable to complete

How to resolve a full transaction log

The following specific steps will help you find the reason for a full transaction log and resolve the issue.

1. Truncate the Log

A very common solution to this problem is to ensure transaction log backups are performed for your database which will ensure the log is truncated. If no recent transaction log history is indicated for the database with a full transaction log, the solution to the problem is straightforward: resume regular transaction log backups of the database.

Log truncation explained

There’s a difference between truncating a transaction log and shrinking a transaction log. Log Truncation occurs normally during a transaction log backup, and is a logical operation which removes committed records inside the log, whereas log shrinking reclaims physical space on the file system by reducing the file size. Log truncation occurs on a virtual-log-file (VLF) boundary, and a log file may contain many VLFs. A log file can be shrunk only if there’s empty space inside the log file to reclaim. Shrinking a log file alone can’t solve the problem of a full log file, instead, you must discover why the log file is full and can’t be truncated.

[!WARNING]
Data that is moved to shrink a file can be scattered to any available location in the file. This causes index fragmentation and might slow the performance of queries that search a range of the index. To eliminate the fragmentation, consider rebuilding the indexes on the file after shrinking. For more information, see Shrink a database.

What is preventing log truncation?

To discover what is preventing log truncation in a given case, use the log_reuse_wait and log_reuse_wait_desc columns of the sys.databases catalog view. For more information, see sys.databases (Transact-SQL). For descriptions of factors that can delay log truncation, see The Transaction Log (SQL Server).

The following set of T-SQL commands will help you identify if a database transaction log isn’t truncated and the reason for it. The following script will also recommend steps to resolve the issue:

SET NOCOUNT ON
DECLARE @SQL VARCHAR (8000), @log_reuse_wait tinyint, @log_reuse_wait_desc nvarchar(120), @dbname sysname, @database_id int, @recovery_model_desc varchar (24)


IF ( OBJECT_id (N'tempdb..#CannotTruncateLog_Db') is not null)
BEGIN
    DROP TABLE #CannotTruncateLog_Db
END


--get info about transaction logs in each db. Use a DMV which supports all supported versions

IF ( OBJECT_id (N'tempdb..#dm_db_log_space_usage') is not null)
BEGIN
    DROP TABLE #dm_db_log_space_usage 
END
SELECT * INTO #dm_db_log_space_usage FROM sys.dm_db_log_space_usage where 1=0

DECLARE log_space CURSOR FOR SELECT NAME FROM sys.databases
OPEN log_space 

FETCH NEXT FROM log_space into @dbname

WHILE @@FETCH_STATUS = 0
BEGIN

	set @SQL = '
	insert into #dm_db_log_space_usage (
	database_id, 
	total_log_size_in_bytes, 
	used_log_space_in_bytes, 
	used_log_space_in_percent, 
	log_space_in_bytes_since_last_backup
	)
	select
	database_id, 
	total_log_size_in_bytes, 
	used_log_space_in_bytes, 
	used_log_space_in_percent, 
	log_space_in_bytes_since_last_backup
	from ' + @dbname +'.sys.dm_db_log_space_usage'

	
	BEGIN TRY  
		exec (@SQL)
	END TRY  

	BEGIN CATCH  
        SELECT ERROR_MESSAGE() AS ErrorMessage;  
	END CATCH;

	FETCH NEXT FROM log_space into @dbname
END

CLOSE log_space 
DEALLOCATE log_space 

--select the affected databases 
SELECT 
    sdb.name as DbName, 
    sdb.log_reuse_wait, sdb.log_reuse_wait_desc, 
    log_reuse_wait_explanation = CASE

        WHEN log_reuse_wait = 1 THEN 'No checkpoint has occurred since the last log truncation, or the head of the log has not yet moved beyond'
        WHEN log_reuse_wait = 2 THEN 'A log backup is required before the transaction log can be truncated.'
        WHEN log_reuse_wait = 3 THEN 'A data backup or a restore is in progress (all recovery models). Please wait or cancel backup'
        WHEN log_reuse_wait = 4 THEN 'A long-running active transaction or a defferred transaction is keeping log from being truncated. You can attempt a log backup to free space or complete/rollback long transaction'
        WHEN log_reuse_wait = 5 THEN 'Database mirroring is paused, or under high-performance mode, the mirror database is significantly behind the principal database. (Full recovery model only)'        
        WHEN log_reuse_wait = 6 THEN 'During transactional replication, transactions relevant to the publications are still undelivered to the distribution database. Investigate the status of agents involved in replication or Changed Data Capture (CDC). (Full recovery model only.)'        

        WHEN log_reuse_wait = 7 THEN 'A database snapshot is being created. This is a routine, and typically brief, cause of delayed log truncation.'
        WHEN log_reuse_wait = 8 THEN 'A transaction log scan is occurring. This is a routine, and typically a brief cause of delayed log truncation.'
        WHEN log_reuse_wait = 9 THEN 'A secondary replica of an availability group is applying transaction log records of this database to a corresponding secondary database. (Full recovery model only.)'
        WHEN log_reuse_wait = 13 THEN 'If a database is configured to use indirect checkpoints, the oldest page on the database might be older than the checkpoint log sequence number (LSN).'
        WHEN log_reuse_wait = 16 THEN 'An In-Memory OLTP checkpoint has not occurred since the last log truncation, or the head of the log has not yet moved beyond a VLF.'
    ELSE 'None' END,

    sdb.database_id,
    sdb.recovery_model_desc,
    lsu.used_log_space_in_bytes/1024 as Used_log_size_MB,
	lsu.total_log_size_in_bytes /1024 as Total_log_size_MB,
    100 - lsu.used_log_space_in_percent as Percent_Free_Space
INTO #CannotTruncateLog_Db
FROM sys.databases AS sdb INNER JOIN #dm_db_log_space_usage lsu ON sdb.database_id = lsu.database_id
WHERE log_reuse_wait > 0

SELECT * FROM #CannotTruncateLog_Db 


DECLARE no_truncate_db CURSOR FOR
    SELECT log_reuse_wait, log_reuse_wait_desc, DbName, database_id, recovery_model_desc FROM #CannotTruncateLog_Db;


OPEN no_truncate_db

FETCH NEXT FROM no_truncate_db into @log_reuse_wait, @log_reuse_wait_desc, @dbname, @database_id, @recovery_model_desc

WHILE @@FETCH_STATUS = 0
BEGIN
    if (@log_reuse_wait > 0)
        select '-- ''' + @dbname +  ''' database has log_reuse_wait = ' + @log_reuse_wait_desc + ' --'  as 'Individual Database Report'


    if (@log_reuse_wait = 1)
    BEGIN
        select 'Consider running the checkpoint command to attempt resolving this issue or further t-shooting may be required on the checkpoint process. Also, examine the log for active VLFs at the end of file' as Recommendation
        select 'USE ''' + @dbname+ '''; CHECKPOINT' as CheckpointCommand
        select 'select * from sys.dm_db_log_info(' + CONVERT(varchar,@database_id)+ ')' as VLF_LogInfo
    END
    else if (@log_reuse_wait = 2)
    BEGIN
        select 'Is '+ @recovery_model_desc +' recovery model the intended choice for ''' + @dbname+ ''' database? Review recovery models and determine if you need to change it. https://learn.microsoft.com/sql/relational-databases/backup-restore/recovery-models-sql-server' as RecoveryModelChoice
        select 'To truncate the log consider performing a transaction log backup on database ''' + @dbname+ ''' which is in ' + @recovery_model_desc +' recovery model. Be mindful of any existing log backup chains that could be broken' as Recommendation
        select 'BACKUP LOG [' + @dbname + '] TO DISK = ''some_volume:some_folder' + @dbname + '_LOG.trn ''' as BackupLogCommand
    END
    else if (@log_reuse_wait = 3)
    BEGIN
        select 'Either wait for or cancel any active backups currently running for database ''' +@dbname+ '''. To check for backups, run this command:' as Recommendation
        select 'select * from sys.dm_exec_requests where command like ''backup%'' or command like ''restore%''' as FindBackupOrRestore
    END
    else if (@log_reuse_wait = 4)
    BEGIN
        select 'Active transactions currently running  for database ''' +@dbname+ '''. To check for active transactions, run these commands:' as Recommendation
        select 'DBCC OPENTRAN (''' +@dbname+ ''')' as FindOpenTran
        select 'select database_id, db_name(database_id) dbname, database_transaction_begin_time, database_transaction_state, database_transaction_log_record_count, database_transaction_log_bytes_used, database_transaction_begin_lsn, stran.session_id from sys.dm_tran_database_transactions dbtran left outer join sys.dm_tran_session_transactions stran on dbtran.transaction_id = stran.transaction_id where database_id = ' + CONVERT(varchar, @database_id) as FindOpenTransAndSession
    END

    else if (@log_reuse_wait = 5)
    BEGIN
        select 'Database Mirroring for database ''' +@dbname+ ''' is behind on synchronization. To check the state of DBM, run the commands below:' as Recommendation
        select 'select db_name(database_id), mirroring_state_desc, mirroring_role_desc, mirroring_safety_level_desc from sys.database_mirroring where mirroring_guid is not null and mirroring_state <> 4 and database_id = ' + convert(sysname, @database_id)  as CheckMirroringStatus
        
        select 'Database Mirroring for database ''' +@dbname+ ''' may be behind: check unsent_log, send_rate, unrestored_log, recovery_rate, average_delay in this output' as Recommendation
        select 'exec msdb.sys.sp_dbmmonitoraddmonitoring 1; exec msdb.sys.sp_dbmmonitorresults ''' + @dbname+ ''', 5, 0; waitfor delay ''00:01:01''; exec msdb.sys.sp_dbmmonitorresults ''' + @dbname+ '''; exec msdb.sys.sp_dbmmonitordropmonitoring'   as CheckMirroringStatusAnd
    END

    else if (@log_reuse_wait = 6)
    BEGIN
        select 'Replication transactions still undelivered from publisher database ''' +@dbname+ ''' to Distribution database. Check the oldest non-distributed replication transaction. Also check if the Log Reader Agent is running and if it has encoutered any errors' as Recommendation
        select 'DBCC OPENTRAN  (''' + @dbname + ''')' as CheckOldestNonDistributedTran
        select 'select top 5 * from distribution..MSlogreader_history where runstatus in (6, 5) or error_id <> 0 and agent_id = find_in_mslogreader_agents_table  order by time desc ' as LogReaderAgentState
    END
    
    else if (@log_reuse_wait = 9)
    BEGIN
        select 'Always On transactions still undelivered from primary database ''' +@dbname+ ''' to Secondary replicas. Check the Health of AG nodes and if there is latency is Log block movement to Secondaries' as Recommendation
        select 'select availability_group=cast(ag.name as varchar(30)), primary_replica=cast(ags.primary_replica as varchar(30)),primary_recovery_health_desc=cast(ags.primary_recovery_health_desc as varchar(30)), synchronization_health_desc=cast(ags.synchronization_health_desc as varchar(30)),ag.failure_condition_level, ag.health_check_timeout, automated_backup_preference_desc=cast(ag.automated_backup_preference_desc as varchar(10))  from sys.availability_groups ag join sys.dm_hadr_availability_group_states ags on ag.group_id=ags.group_id' as CheckAGHealth
        select 'SELECT  group_name=cast(arc.group_name as varchar(30)), replica_server_name=cast(arc.replica_server_name as varchar(30)), node_name=cast(arc.node_name as varchar(30)),role_desc=cast(ars.role_desc as varchar(30)), ar.availability_mode_Desc, operational_state_desc=cast(ars.operational_state_desc as varchar(30)), connected_state_desc=cast(ars.connected_state_desc as varchar(30)), recovery_health_desc=cast(ars.recovery_health_desc as varchar(30)), synchronization_health_desc=cast(ars.synchronization_health_desc as varchar(30)), ars.last_connect_error_number, last_connect_error_description=cast(ars.last_connect_error_description as varchar(30)), ars.last_connect_error_timestamp, primary_role_allow_connections_desc=cast(ar.primary_role_allow_connections_desc as varchar(30)) from sys.dm_hadr_availability_replica_cluster_nodes arc join sys.dm_hadr_availability_replica_cluster_states arcs on arc.replica_server_name=arcs.replica_server_name join sys.dm_hadr_availability_replica_states ars on arcs.replica_id=ars.replica_id join sys.availability_replicas ar on ars.replica_id=ar.replica_id join sys.availability_groups ag on ag.group_id = arcs.group_id and ag.name = arc.group_name ORDER BY cast(arc.group_name as varchar(30)), cast(ars.role_desc as varchar(30))' as CheckReplicaHealth
        select 'select database_name=cast(drcs.database_name as varchar(30)), drs.database_id, drs.group_id, drs.replica_id, drs.is_local,drcs.is_failover_ready,drcs.is_pending_secondary_suspend, drcs.is_database_joined, drs.is_suspended, drs.is_commit_participant, suspend_reason_desc=cast(drs.suspend_reason_desc as varchar(30)), synchronization_state_desc=cast(drs.synchronization_state_desc as varchar(30)), synchronization_health_desc=cast(drs.synchronization_health_desc as varchar(30)), database_state_desc=cast(drs.database_state_desc as varchar(30)), drs.last_sent_lsn, drs.last_sent_time, drs.last_received_lsn, drs.last_received_time, drs.last_hardened_lsn, drs.last_hardened_time,drs.last_redone_lsn, drs.last_redone_time, drs.log_send_queue_size, drs.log_send_rate, drs.redo_queue_size, drs.redo_rate, drs.filestream_send_rate, drs.end_of_log_lsn, drs.last_commit_lsn, drs.last_commit_time, drs.low_water_mark_for_ghosts, drs.recovery_lsn, drs.truncation_lsn, pr.file_id, pr.error_type, pr.page_id, pr.page_status, pr.modification_time from sys.dm_hadr_database_replica_cluster_states drcs join sys.dm_hadr_database_replica_states drs on drcs.replica_id=drs.replica_id and drcs.group_database_id=drs.group_database_id left outer join sys.dm_hadr_auto_page_repair pr on drs.database_id=pr.database_id  order by drs.database_id' as LogMovementHealth
        select 'For more information see https://learn.microsoft.com/troubleshoot/sql/availability-groups/error-9002-transaction-log-large' as OnlineDOCResource
    END    
    else if (@log_reuse_wait in (10, 11, 12, 14))
    BEGIN
        select 'This state is not documented and is expected to be rare and short-lived' as Recommendation
    END    
    else if (@log_reuse_wait = 13)
    BEGIN
        select 'The oldest page on the database might be older than the checkpoint log sequence number (LSN). In this case, the oldest page can delay log truncation.' as Finding
        select 'This state should be short-lived, but if you find it is taking a long time, you can consider disabling Indirect Checkpoint temporarily' as Recommendation
        select 'ALTER DATABASE [' +@dbname+ '] SET TARGET_RECOVERY_TIME = 0 SECONDS' as DisableIndirectCheckpointTemporarily
    END    
    else if (@log_reuse_wait = 16)
    BEGIN
        select 'For memory-optimized tables, an automatic checkpoint is taken when transaction log file becomes bigger than 1.5 GB since the last checkpoint (includes both disk-based and memory-optimized tables)' as Finding
        select 'Review https://blogs.msdn.microsoft.com/sqlcat/2016/05/20/logging-and-checkpoint-process-for-memory-optimized-tables-2/' as ReviewBlog
        select 'use ' +@dbname+ ' CHECKPOINT' as RunCheckpoint
    END    

    FETCH NEXT FROM no_truncate_db into @log_reuse_wait, @log_reuse_wait_desc, @dbname, @database_id, @recovery_model_desc

END

CLOSE no_truncate_db
DEALLOCATE no_truncate_db

[!IMPORTANT]
If the database was in recovery when the 9002 error occurred, after resolving the problem, recover the database by using ALTER DATABASE database_name SET ONLINE.

LOG_BACKUP log_reuse_wait

The most common actions you can consider here is to review your database recovery model and backup the transaction log of your database.

Consider the database’s recovery model

The transaction log may be failing to truncate with LOG_BACKUP log_reuse_wait category, because you have never backed it up. In many of those cases, your database is using FULL or BULK_LOGGED recovery model, but you did not back up transaction logs. You should consider each database recovery model carefully: perform transaction log backups on all databases in FULL or BULK LOGGED recovery models to minimize occurrences of error 9002. For more information, see Recovery Models.

Back up the log

Under the FULL or BULK_LOGGED recovery model, if the transaction log has not been backed up recently, backup might be what is preventing log truncation. You must back up the transaction log to allow log records to be released and the log truncated. If the log has never been backed up, you must create two log backups to permit the [!INCLUDEssDE] to truncate the log to the point of the last backup. Truncating the log frees logical space for new log records. To keep the log from filling up again, take log backups regularly and more frequently. For more information, see Recovery Models.

A complete history of all SQL Server backup and restore operations on a server instance is stored in the msdb system database. To review the complete backup history of a database, use the following sample script:

SELECT bs.database_name
, backuptype = CASE 
	WHEN bs.type = 'D' and bs.is_copy_only = 0 THEN 'Full Database'
	WHEN bs.type = 'D' and bs.is_copy_only = 1 THEN 'Full Copy-Only Database'
	WHEN bs.type = 'I' THEN 'Differential database backup'
	WHEN bs.type = 'L' THEN 'Transaction Log'
	WHEN bs.type = 'F' THEN 'File or filegroup'
	WHEN bs.type = 'G' THEN 'Differential file'
	WHEN bs.type = 'P' THEN 'Partial'
	WHEN bs.type = 'Q' THEN 'Differential partial' END + ' Backup'
, bs.recovery_model
, BackupStartDate = bs.Backup_Start_Date
, BackupFinishDate = bs.Backup_Finish_Date
, LatestBackupLocation = bf.physical_device_name
, backup_size_mb = bs.backup_size/1024./1024.
, compressed_backup_size_mb = bs.compressed_backup_size/1024./1024.
, database_backup_lsn -- For tlog and differential backups, this is the checkpoint_lsn of the FULL backup it is based on. 
, checkpoint_lsn
, begins_log_chain
FROM msdb.dbo.backupset bs	
LEFT OUTER JOIN msdb.dbo.backupmediafamily bf ON bs.[media_set_id] = bf.[media_set_id]
WHERE recovery_model in ('FULL', 'BULK-LOGGED')
AND bs.backup_start_date > DATEADD(month, -2, sysdatetime()) --only look at last two months
ORDER BY bs.database_name asc, bs.Backup_Start_Date desc;

A complete history of all SQL Server backup and restore operations on a server instance is stored in the msdb system database. For more information on backup history, see Backup History and Header Information (SQL Server).

Create a transaction log backup

Example of how to back up the log:

BACKUP LOG [dbname] TO DISK = 'some_volume:some_folderdbname_LOG.trn'
  • Back Up a Transaction Log (SQL Server)

  • xref:Microsoft.SqlServer.Management.Smo.Backup.SqlBackup%2A (SMO)

[!IMPORTANT]
If the database is damaged, see Tail-Log Backups (SQL Server).

ACTIVE_TRANSACTION log_reuse_wait

The steps to troubleshoot ACTIVE_TRANSACTION reason include discovering the long running transaction and resolving it (in some case using the KILL command to do so).

Discover long-running transactions

A very long-running transaction can cause the transaction log to fill. To look for long-running transactions, use one of the following:

  • sys.dm_tran_database_transactions.

This dynamic management view returns information about transactions at the database level. For a long-running transaction, columns of particular interest include the time of the first log record (database_transaction_begin_time), the current state of the transaction (database_transaction_state), and the log sequence number (LSN) of the begin record in the transaction log (database_transaction_begin_lsn).

  • DBCC OPENTRAN.
    This statement lets you identify the user ID of the owner of the transaction, so you can potentially track down the source of the transaction for a more orderly termination (committing it rather than rolling it back).
Kill a transaction

Sometimes you just have to end the transaction; you may have to use the KILL statement. Please use this statement very carefully, especially when critical processes are running that you don’t want to kill. For more information, see KILL (Transact-SQL)

AVAILABILITY_REPLICA log_reuse_wait

When transaction changes at primary Availability replica are not yet hardened on the secondary replica, the transaction log on the primary replica cannot be truncated. This can cause the log to grow, and can occur whether the secondary replica is set for synchronous or asynchronous commit mode. For information on how to troubleshoot this type of issue see Error 9002. The transaction log for database is full due to AVAILABILITY_REPLICA error

CHECKPOINT log_reuse_wait

No checkpoint has occurred since the last log truncation, or the head of the log has not yet moved beyond a virtual log file (VLF). (All recovery models)

This is a routine reason for delaying log truncation. If delayed, consider executing the CHECKPOINT command on the database or examining the log VLFs.

USE dbname; CHECKPOINT
select * from sys.dm_db_log_info(db_id('dbname'))

For more information on log_reuse_wait factors

For more details see Factors that can delay log truncation

2. Resolve full disk volume

In some situations the disk volume that hosts the transaction log file may fill up. You can take one of the following actions to resolve the log-full scenario that results from a full disk:

Free disk space

You might be able to free disk space on the disk drive that contains the transaction log file for the database by deleting or moving other files. The freed disk space allows the recovery system to enlarge the log file automatically.

Move the log file to a different disk

If you cannot free enough disk space on the drive that currently contains the log file, consider moving the file to another drive with sufficient space.

[!IMPORTANT]
Log files should never be placed on compressed file systems.

See Move Database Files for information on how to change the location of a log file.

Add a log file on a different disk

Add a new log file to the database on a different disk that has sufficient space by using ALTER DATABASE <database_name> ADD LOG FILE. Multiple log files for a single database should be considered a temporary condition to resolve a space issue, not a long-term condition. Most databases should only have one transaction log file. Continue to investigate the reason why the transaction log is full and cannot be truncated. Consider adding temporary additional transaction log files as an advanced troubleshooting step.

For more information see Add Data or Log Files to a Database.

Utility script for recommended actions

These steps can be partly automated by running this T-SQL script which will identify logs files that using a large percentage of disk space and suggest actions:

DECLARE @log_reached_disk_size BIT = 0

SELECT 
    name LogName, 
    physical_name, 
    CONVERT(bigint, size)*8/1024 LogFile_Size_MB, 
    volume_mount_point, 
    available_bytes/1024/1024 Available_Disk_space_MB,
    (CONVERT(bigint, size)*8.0/1024)/(available_bytes/1024/1024 )*100 file_size_as_percentage_of_disk_space,
    db_name(mf.database_id) DbName
FROM sys.master_files mf CROSS APPLY sys.dm_os_volume_stats (mf.database_id, file_id)
WHERE mf.[type_desc] = 'LOG'
    AND (CONVERT(bigint, size)*8.0/1024)/(available_bytes/1024/1024 )*100 > 90 --log is 90% of disk drive
ORDER BY size DESC

if @@ROWCOUNT > 0
BEGIN

    set @log_reached_disk_size = 1

    -- Discover if any logs have are close to or completely filled disk volume they reside on.
    -- Either Add A New File To A New Drive, Or Shrink Existing File
    -- If Cannot Shrink, Go To Cannot Truncate Section

    DECLARE @db_name_filled_disk sysname, @log_name_filled_disk sysname, @go_beyond_size bigint 
    
    DECLARE log_filled_disk CURSOR FOR
        SELECT 
            db_name(mf.database_id),
            name
        FROM sys.master_files mf CROSS APPLY sys.dm_os_volume_stats (mf.database_id, file_id)
        WHERE mf.[type_desc] = 'LOG'
            AND (convert(bigint, size)*8.0/1024)/(available_bytes/1024/1024 )*100 > 90 --log is 90% of disk drive
        ORDER BY size desc

    OPEN log_filled_disk

    FETCH NEXT FROM log_filled_disk into @db_name_filled_disk , @log_name_filled_disk

    WHILE @@FETCH_STATUS = 0
    BEGIN
        
        SELECT 'Transaction log for database "' + @db_name_filled_disk + '" has nearly or completely filled disk volume it resides on!' AS Finding
        SELECT 'Consider using one of the below commands to shrink the "' + @log_name_filled_disk +'" transaction log file size or add a new file to a NEW volume' AS Recommendation
        SELECT 'DBCC SHRINKFILE(''' + @log_name_filled_disk + ''')' AS Shrinkfile_Command
        SELECT 'ALTER DATABASE ' + @db_name_filled_disk + ' ADD LOG FILE ( NAME = N''' + @log_name_filled_disk + '_new'', FILENAME = N''NEW_VOLUME_AND_FOLDER_LOCATION' + @log_name_filled_disk + '_NEW.LDF'', SIZE = 81920KB , FILEGROWTH = 65536KB )' AS AddNewFile
        SELECT 'If shrink does not reduce the file size, likely it is because it has not been truncated. Please review next section below. See https://learn.microsoft.com/sql/t-sql/database-console-commands/dbcc-shrinkfile-transact-sql' AS TruncateFirst
        SELECT 'Can you free some disk space on this volume? If so, do this to allow for the log to continue growing when needed.' AS FreeDiskSpace




         FETCH NEXT FROM log_filled_disk into @db_name_filled_disk , @log_name_filled_disk

    END

    CLOSE log_filled_disk
    DEALLOCATE log_filled_disk

END

3. Change log size limit or enable Autogrow

Error 9002 can be generated if the transaction log size has been set to an upper limit or Autogrow is not allowed. In this case, enabling autogrow or increasing the log size manually can help resolve the issue. Use this T-SQL command to find such log files and follow the recommendations provided:

SELECT DB_NAME(database_id) DbName,
       name LogName,
       physical_name,
       type_desc ,
       CONVERT(bigint, SIZE)*8/1024 LogFile_Size_MB ,
       CONVERT(bigint,max_size)*8/1024 LogFile_MaxSize_MB ,
       (SIZE*8.0/1024)/(max_size*8.0/1024)*100 percent_full_of_max_size,
       CASE WHEN growth = 0 THEN 'AUTOGROW_DISABLED' ELSE 'Autogrow_Enabled' END as AutoGrow
FROM sys.master_files
WHERE file_id = 2
    AND (SIZE*8.0/1024)/(max_size*8.0/1024)*100 > 90
    AND max_size not in (-1, 268435456)
    OR growth = 0

if @@ROWCOUNT > 0
BEGIN
    DECLARE @db_name_max_size sysname, @log_name_max_size sysname, @configured_max_log_boundary bigint, @auto_grow int
    
    DECLARE reached_max_size CURSOR FOR
        SELECT db_name(database_id),
               name,
               CONVERT(bigint, SIZE)*8/1024,
               growth
        FROM sys.master_files
        WHERE file_id = 2
            AND ( (SIZE*8.0/1024)/(max_size*8.0/1024)*100 > 90
            AND max_size not in (-1, 268435456)
            OR growth = 0 )


    OPEN reached_max_size

    FETCH NEXT FROM reached_max_size into @db_name_max_size , @log_name_max_size, @configured_max_log_boundary, @auto_grow 

    WHILE @@FETCH_STATUS = 0
    BEGIN
        IF @auto_grow = 0
          BEGIN
            SELECT 'The database "' + @db_name_max_size+'" contains a log file "' + @log_name_max_size + '" whose autogrow has been DISABLED' as Finding
            SELECT 'Consider enabling autogrow or increasing file size via these ALTER DATABASE commands' as Recommendation
            SELECT 'ALTER DATABASE ' + @db_name_max_size + ' MODIFY FILE ( NAME = N''' + @log_name_max_size + ''', FILEGROWTH = 65536KB)' as AutoGrowth
          END
        ELSE
          BEGIN
            SELECT 'The database "' + @db_name_max_size+'" contains a log file "' + @log_name_max_size + '" whose max limit is set to ' + convert(varchar(24), @configured_max_log_boundary) + ' MB and this limit has been reached!' as Finding
            SELECT 'Consider using one of the below ALTER DATABASE commands to either change the log file size or add a new file' as Recommendation
          END
        
        SELECT 'ALTER DATABASE ' + @db_name_max_size + ' MODIFY FILE ( NAME = N''' + @log_name_max_size + ''', MAXSIZE = UNLIMITED)' as UnlimitedSize
        SELECT 'ALTER DATABASE ' + @db_name_max_size + ' MODIFY FILE ( NAME = N''' + @log_name_max_size + ''', MAXSIZE = something_larger_than_' + CONVERT(varchar(24), @configured_max_log_boundary) +'MB )' as IncreasedSize
        SELECT 'ALTER DATABASE ' + @db_name_max_size + ' ADD LOG FILE ( NAME = N''' + @log_name_max_size + '_new'', FILENAME = N''SOME_FOLDER_LOCATION' + @log_name_max_size + '_NEW.LDF'', SIZE = 81920KB , FILEGROWTH = 65536KB )' as AddNewFile

        FETCH NEXT FROM reached_max_size into @db_name_max_size , @log_name_max_size, @configured_max_log_boundary, @auto_grow

    END

    CLOSE reached_max_size
    DEALLOCATE reached_max_size
END
ELSE
    SELECT 'Found no files that have reached max log file size' as Findings

Increase log file size or enable Autogrow

If space is available on the log disk, you can increase the size of the log file. The maximum size for log files is two terabytes (TB) per log file.

If autogrow is disabled, the database is online, and sufficient space is available on the disk, do either of these:

  • Manually increase the file size to produce a single growth increment. These are general recommendations on log size growth and size.
  • Turn on autogrow by using the ALTER DATABASE statement to set a non-zero growth increment for the FILEGROWTH option. See Considerations for the autogrow and autoshrink settings in SQL Server

[!NOTE]
In either case, if the current size limit has been reached, increase the MAXSIZE value.

See also

ALTER DATABASE (Transact-SQL)
Manage the Size of the Transaction Log File
Transaction Log Backups (SQL Server)
sp_add_log_file_recover_suspect_db (Transact-SQL)
MSSQLSERVER_9002
How a log file structure can affect database recovery time — Microsoft Tech Community

In this article, I discuss the solution for the error mentioning that the transaction log for your SQL database is full due to ‘ACTIVE_TRANSACTION’. This error means that you SQL Server database has the wrong settings for the task that you want to perform.

Most likely, you are trying to bulk import a large data set from a plain text file or Excel file. Or your program or database executes an infrequent task or processes very large transactions, causing the database to throw these errors. In this article, we will explain how you can prevent the transaction log error in SQL Server while bulk importing your data.

Quick fix the full transaction log error

First of all, to fix the error due to full transaction log is very simple. The ACTIVE_TRANSACTION can give a good hint: the current transaction is filling up the transaction log for the database. And when the transaction log cannot grow anymore, you will get the full transaction log error.

You can solve this issue easily within your database. First of all, you can run a script to solve this. However, in this article we show you how to solve this by changing the properties of the database.

So, to solve this SQL Server error, the transaction log needs to be able to grow more than what is currently possible. You have to change this setting in the SQL Server database itself.

When you have logged in to the SQL Server instance using SQL Server Management Studio, you will see a list of databases that are on this SQL Server instance. From this list of databases, identify the database where SQL DataTool is connected to (or at least the database that returned the error). Now you select the properties of that database, by opening the context menu (right click on the database name). The context menu is the pop-up as shown in the screenshot below.

Database properties

Database properties

Within the properties screen for the database, multiple ‘pages’ are available (as shown on the left hand side of the screenshot below). The settings that you have to change, can be found on the ‘Files’ page. This page shows (at least) two files: one file that contains all the database data, and one file that contains the log of all transactions executed in the database. This second file has the file type LOG. This file contains the transaction log, and causes the transaction log full due to ACTIVE_TRANSACTION error.

The two files mentioned are the minimum number of files. Some databases contain more files, but as mentioned, in this case you should focus on the LOG file. Both files are created during the creation of the database. During the creation of the database, all settings are configured. Most likely, bulk insert is not one of the scenarios that was taken into account when creating the database.

Database file settings

Database file settings

As you can see in the screenshot above, in the file settings of the log file of this database the ‘Autogrowth / Maxsize’ property is set to ‘None’. This means that the transaction log can not grow at all. Even when you will try to bulk insert a small data, you might already get the transaction log is full due to ACTIVE_TRANSACTION error.

To change the settings of the ‘Autogrowth / Maxsize’ property, click on the Change button (button with the ellipsis) behind ‘None’ (like in the screenshot above). On the screen that pops up, you can change the Autogrowth settings. A screenshot of this screen is shown below.

Autogrowth properties

Autogrowth properties

This screen shows the following settings:

  • Enable autogrowth. Checking this option will enable the autogrowth of the file chosen. In this case, when we enable autogrowth, the transaction log file will be enabled for autogrowth.
  • File growth. File growth has two options. Each time an autogrow event is triggered, the transaction log file will be extended. You can either enable the transaction log file to grow with a certain percentage, or you can set the autogrowth to be always the same size (in Megabytes).
  • Maximum file size. The maximum file size has also two options. The file size can be either limited to a certain size (in MB) or the file can be set to grow unlimited (where the space of the disk used is the maximum).

By checking the ‘Enable Autogrowth’ option in this screen, the other settings become available. You can either limit the transaction log file to a specific maximum file size, or let the log file grow to an unlimited size. Now you know where you can find the solution of the error that the transaction log of your database is full due to ACTIVE_TRANSACTION, you can solve it!

All programs communicating with the database are dependent on the SQL Server database limitations. Therefore you might want to know what the transaction log does. In the next section, the transaction log is explained shortly, and some useful links are added.

What is the transaction log

The transaction log file is a file which is part of the database. The data (either ROWS data or COLUMN data) is stored within a file. The (transaction) log file is stored on the disk in a different file.

The transaction log file contains specific transactions with the purpose of restoring the database to its state before the transactions had taken place. This means that, when a transaction result in an error, the transaction can be rolled back. To find more details on the transaction log, you can look at this beginner’s guide.

When you enable the transaction log for autogrowth, it is important to keep in mind that an autogrow event will temporary stop transactions to be executed. So an autogrow event on a transactional production system will temporary stop the (business) transactions.

When the file growth setting has been set to grow in percentage, the size of the growth depends on the transaction log file. When the file is small, the file will only grow with a limited amount. When the file is already huge, the growth of the file will also be huge. Therefore, to be able to keep track of the size of the transaction log, it is better to set the ‘File growth’ setting to grow in megabytes.

And when the maximum file size is set to unlimited, you might run into the problem that the disk is full. When you limit the file size by a specific maximum, you might run into the transaction log is full due to ACTIVE_TRANSACTION error.

When bulk importing data, you should take the maximum file size into account. To limit the risk of autogrow events from happening (and thus stopping business transactions on a production system), you can choose to set the transaction log to the size of your largest table.

You can find on the pages of Microsoft other considerations and best practices on the autogrowth option.

Finishing bulk inserts

When you have finished the bulk inserts, the settings of the transaction log can be set to the initial configuration. Only when the initial settings were thoroughly thought through, and when you are not expecting to bulk insert any other data. Keeping the transaction log at a large file size will use a lot of disk space. And this cannot be used for other data anymore.

Tutorial

This is usually due to a long running transaction, or a low log file size.

SQL Server How To Solve 'The transaction log for database x is full due to ACTIVE_TRANSACTION'

The error “The transaction log for database x is full due to ACTIVE_TRANSACTION” can occur in SQL Server when the transaction log for a database becomes full and cannot accept any more transactions. This can happen for a number of reasons, such as a long-running transaction that is preventing the log from being truncated, or a database with a low log file size that is unable to accommodate the volume of transactions being performed.

👋 Check out our easy to use desktop GUI for SQL

Beekeeper Studio is a truly cross-platform SQL GUI with a clean, uncluttered interface. Write SQL, edit data, alter tables, and more!

Available for MacOS, Linux, and Windows.

There are a few different approaches you can take to solve this issue. Here are some steps you can try:

  1. Identify the active transaction causing the log to fill up: To do this, you can use the sys.dm_tran_active_transactions dynamic management view to find the transaction that is causing the log to fill up. You can then try to identify the cause of the long-running transaction and take steps to resolve it.

  2. Increase the size of the transaction log: If the transaction log is too small to accommodate the volume of transactions being performed, you can increase the size of the log file. To do this, you will need to alter the database, setting a new value for the FILEGROWTH property of the log file. You can also set the MAXSIZE property to allow the log file to grow to a larger size.

  3. Truncate the transaction log: If you are unable to identify the cause of the long-running transaction or increase the size of the log file, you may need to truncate the log. This will clear the log and allow new transactions to be recorded. However, be aware that this will also cause any uncommitted transactions to be rolled back, so you should only do this as a last resort.

  4. Change the recovery model of the database: If you are using the FULL recovery model for your database, you may be able to solve the “The transaction log for database x is full due to ACTIVE_TRANSACTION” error by switching to the SIMPLE recovery model. This will allow the log to be truncated more frequently, which can help prevent the log from filling up. However, be aware that this will also mean that you will not be able to perform point-in-time recovery of your database.

  5. Monitor and optimize your transactions: To prevent the “The transaction log for database x is full due to ACTIVE_TRANSACTION” error from occurring in the future, you should monitor your transactions and optimize them to minimize their impact on the transaction log. This can include reducing the size of transactions, optimizing the code being run in the transactions, and committing transactions more frequently.

Overall, solving the “The transaction log for database x is full due to ACTIVE_TRANSACTION” error requires identifying the cause of the problem and taking steps to address it. Whether you need to increase the size of the log file, truncate the log, change the recovery model of the database, or optimize your transactions, there are a number of different approaches you can take to resolve this issue and keep your database running smoothly.


  • Remove From My Forums
  • Question

  • Hi All,

    I am running an ssis job from sql server agent. The job keeps on failing with the following error-

    The transaction log for database ‘xxxxxx’ is full due to ‘ACTIVE_TRANSACTION’. «. 

    When I check for pending transaction on that database, I don’t see anything. Is there any work around for this issue. Help is highly appreciated.

    Thanks,


    VSP

Answers

  • Hello,

    Can you run below on database whoes log file is growing

    select log_reuse_wait_desc from sys.databases where name='db_name'

    Are you sure you have enough log file space to accomodate logs for this  transaction.In simple recovery also transaction log can grow if there is long running transaction which is hloding log from being truncated.

    How much space is there on drive where log file resides ,do you have enough space ?

    What is this job doing ?

    Please answer all


    Please mark this reply as the answer or vote as helpful, as appropriate, to make it useful for other readers

    • Marked as answer by

      Wednesday, April 30, 2014 6:28 PM

  • First I would like to suggest that do the bulk process in Bulk recovery model as in this model transaction will be minimally logged.

    —**************——————

    If your one truncation is make this full then do below as active transaction can’t be truncate ..

    Is your log file in restricted mode the make it unrestricted mode for a while when your package is running.

    Check if log drive is getting full  then keep and eye when drive is about to full create another log file to some other location

    If this is happen due to multiple transaction then there will be active log file and inactive log file so taking a log backup you can reclaim the space consumed by inactive log file.

    You can also do this changing recovery model to simple during the process and after completion back to original.

    • Marked as answer by
      VS_SQL
      Wednesday, April 30, 2014 6:28 PM

    • Marked as answer by
      VS_SQL
      Wednesday, April 30, 2014 6:28 PM

Понравилась статья? Поделить с друзьями:
  • Sql server ошибка the login failed
  • Sql server ошибка not support the language
  • Sql server ошибка 5023 при запуске
  • Sql server ошибка 26 при удаленном соединении
  • Sql server операция create file вызвала ошибку операционной системы