Troubleshooting a Full Transaction Log (Error 9002)

  • Article

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, SQL Server Database Engine 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 Database Engine marks the database as RESOURCE PENDING. In either case, user action is required to make log space available.

Responding to a Full Transaction Log

The appropriate response to a full transaction log depends partly on what condition or conditions caused the log to fill. 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.database catalog view. For more information, see sys.databases (Transact-SQL). For descriptions of factors that can delay log truncation, see Factors That Can Delay Log Truncation.

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.

Alternatives for responding to a full transaction log include:

  • Backing up the log.
  • Freeing disk space so that the log can automatically grow.
  • Moving the log file to a disk drive with sufficient space.
  • Increasing the size of a log file.
  • Adding a log file on a different disk.
  • Completing or killing a long-running transaction.

These alternatives are discussed in the following sections. Choose a response that fits your situation best.

Note

Forcing log truncation breaks the log chain and leaves your database vulnerable until the next full database backup. For this reason, the TRUNCATE_ONLY option will be removed from the BACKUP statement in a future version of SQL Server. Avoid using this option in new development work, and plan to modify applications that currently use it.

Backing up the Log

Under the full recovery model or bulk-logged recovery model, if the transaction log has not been backed up recently, backup might be what is preventing log truncation. If the log has never been backed up, you must create two log backups to permit the Database Engine to truncate the log to the point of the last backup. Truncating the log frees space for new log records. To keep the log from filling up again, take log backups frequently.

To create a transaction log backup

Important

If the database is damaged, see Tail-Log Backups.

Freeing 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.

Moving 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.

To move a log file

Increasing the Size of a Log File

If space is available on the log disk, you can increase the size of the log file.

To increase the file size

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

  • Manually increase the file size to produce a single growth increment.
  • Turn on autogrow by using the ALTER DATABASE statement to set a non-zero growth increment for the FILEGROWTH option.

Note

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

Adding 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.

To add a log file

Identify and Manage a Long-Running Transaction

For more information, see Managing Long-Running Transactions.

See Also

Concepts

Creating Transaction Log Backups
Factors That Can Delay Log Truncation
Overview of the Recovery Models
Introduction to Transaction Logs
Working with Transaction Log Backups

Other Resources

ALTER DATABASE (Transact-SQL)
Managing the Transaction Log
sp_add_log_file_recover_suspect_db (Transact-SQL)

Help and Information

Getting SQL Server 2005 Assistance

Change History

Release History

14 April 2006
New content:
  • Added a description about the impact of a full transaction log on database availability.
  • Added information about using sys.database to identify the cause of a full transaction log.
  • Integrated information about resolving the 9002 error from the former "Troubleshooting Insufficient Disk Space" topic.