Export (0) Print
Expand All

The Transaction Log (SQL Server)


Applies To: SQL Server 2016

Every SQL Server database has a transaction log that records all transactions and the database modifications made by each transaction. The transaction log must be truncated on a regular basis to keep it from filling up. However, some factors can delay log truncation, so monitoring log size is important. Some operations can be minimally logged to reduce their impact on transaction log size.

The transaction log is a critical component of the database and, if there is a system failure, the transaction log might be required to bring your database back to a consistent state. The transaction log should never be deleted or moved unless you fully understand the ramifications of doing this.

System_CAPS_ICON_note.jpg Note

Known good points from which to begin applying transaction logs during database recovery are created by checkpoints. For more information, see Database Checkpoints (SQL Server).

In this Topic:

The transaction log supports the following operations:

  • Recovery of individual transactions.

  • Recovery of all incomplete transactions when SQL Server is started.

  • Rolling a restored database, file, filegroup, or page forward to the point of failure.

  • Supporting transactional replication.

  • Supporting high availability and disaster recovery solutions: Always On Availability Groups, database mirroring, and log shipping.

Log truncation frees space in the log file for reuse by the transaction log. Log truncation is essential to keep the log from filling. Log truncation deletes inactive virtual log files from the logical transaction log of a SQL Server database, freeing space in the logical log for reuse by the Physical transaction log. If a transaction log were never truncated, it would eventually fill all the disk space that is allocated to its physical log files.

To avoid this problem, unless log truncation is being delayed for some reason, truncation occurs automatically after the following events:

  • Under the simple recovery model, after a checkpoint.

  • Under the full recovery model or bulk-logged recovery model, if a checkpoint has occurred since the previous backup, truncation occurs after a log backup (unless it is a copy-only log backup).

For more information, see Factors That Can Delay Log Truncation, later in this topic.

System_CAPS_ICON_note.jpg Note

Log truncation does not reduce the size of the physical log file. To reduce the physical size of a physical log file, you need to shrink the log file. For information about shrinking the size of the physical log file, see Manage the Size of the Transaction Log File.

When log records remain active for a long time transaction log truncation is delayed, and potentially the transaction log can fill up.

System_CAPS_ICON_important.jpg Important

For information about how to respond to a full transaction log, see Troubleshoot a Full Transaction Log (SQL Server Error 9002).

Log truncation can be delayed by a variety of factors. You can discover what, if anything, is preventing log truncation by querying the log_reuse_wait and log_reuse_wait_desc columns of the sys.databases catalog view. The following table describes the values of these columns.

log_reuse_wait valuelog_reuse_wait_desc valueDescription
0NOTHINGCurrently there are one or more reusable virtual log files.
1CHECKPOINTNo checkpoint has occurred since the last log truncation, or the head of the log has not yet moved beyond a virtual log file. (All recovery models)

This is a routine reason for delaying log truncation. For more information, see Database Checkpoints (SQL Server).
2LOG_BACKUPA log backup is required before the transaction log can be truncated. (Full or bulk-logged recovery models only)

When the next log backup is completed, some log space might become reusable.
3ACTIVE_BACKUP_OR_RESTOREA data backup or a restore is in progress (all recovery models).

If a data backup is preventing log truncation, canceling the backup operation might help the immediate problem.
4ACTIVE_TRANSACTIONA 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. Note that long-running transactions prevent log truncation under all recovery models, including the simple recovery model, under which the transaction log is generally truncated on each automatic checkpoint.

A transaction is deferred. 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 (SQL Server).
5DATABASE_MIRRORINGDatabase mirroring is paused, or under high-performance mode, the mirror database is significantly behind the principal database. (Full recovery model only)

For more information, see Database Mirroring (SQL Server).
6REPLICATIONDuring transactional replications, transactions relevant to the publications are still undelivered to the distribution database. (Full recovery model only)

For information about transactional replication, see SQL Server Replication.
7DATABASE_SNAPSHOT_CREATIONA database snapshot is being created. (All recovery models)

This is a routine, and typically brief, cause of delayed log truncation.
8LOG_SCANA log scan is occurring. (All recovery models)

This is a routine, and typically brief, cause of delayed log truncation.
9AVAILABILITY_REPLICAA secondary replica of an availability group is applying transaction log records of this database to a corresponding secondary database. (Full recovery model)

For more information, see Entity with relative path '../Topic/Overview%20of%20AlwaysOn%20Availability%20Groups%20(SQL%20Server).md' can not be found, for source topic '{"project_id":"7d6ffa79-2ddc-4606-b774-a6a5d46784cd","entity_id":"d7be5ac5-4c8e-4d0a-b114-939eb97dac4d","entity_type":"Article","locale":"en-US"}'..
10For internal use only
11For internal use only
12For internal use only
13OLDEST_PAGEIf a database is configured to use indirect checkpoints, the oldest page on the database might be older than the checkpoint LSN. In this case, the oldest page can delay log truncation. (All recovery models)

For information about indirect checkpoints, see Database Checkpoints (SQL Server).
14OTHER_TRANSIENTThis value is currently not used.

Minimal logging involves logging only the information that is required to recover the transaction without supporting point-in-time recovery. This topic identifies the operations that are minimally logged under the bulk-logged recovery model (as well as under the simple recovery model, except when a backup is running).

System_CAPS_ICON_note.jpg Note

Minimal logging is not supported for memory-optimized tables.

System_CAPS_ICON_note.jpg Note

Under the full recovery model, all bulk operations are fully logged. However, you can minimize logging for a set of bulk operations by switching the database to the bulk-logged recovery model temporarily for bulk operations. Minimal logging is more efficient than full logging, and it reduces the possibility of a large-scale bulk operation filling the available transaction log space during a bulk transaction. However, if the database is damaged or lost when minimal logging is in effect, you cannot recover the database to the point of failure.

The following operations, which are fully logged under the full recovery model, are minimally logged under the simple and bulk-logged recovery model:

  • Bulk import operations (bcp, BULK INSERT, and INSERT... SELECT). For more information about when bulk import into a table is minimally logged, see Prerequisites for Minimal Logging in Bulk Import.

    System_CAPS_ICON_note.jpg Note

    When transactional replication is enabled, BULK INSERT operations are fully logged even under the Bulk Logged recovery model.

  • SELECT INTO operations.

    System_CAPS_ICON_note.jpg Note

    When transactional replication is enabled, SELECT INTO operations are fully logged even under the Bulk Logged recovery model.

  • Partial updates to large value data types, using the .WRITE clause in the UPDATE statement when inserting or appending new data. Note that minimal logging is not used when existing values are updated. For more information about large value data types, see Data Types (Transact-SQL).

  • WRITETEXT and UPDATETEXT statements when inserting or appending new data into the text, ntext, and image data type columns. Note that minimal logging is not used when existing values are updated.

    System_CAPS_ICON_note.jpg Note

    The WRITETEXT and UPDATETEXT statements are deprecated, so you should avoid using them in new applications.

  • If the database is set to the simple or bulk-logged recovery model, some index DDL operations are minimally logged whether the operation is executed offline or online. The minimally logged index operations are as follows:

    • CREATE INDEX operations (including indexed views).


      System_CAPS_ICON_note.jpg Note

      The DBCC DBREINDEX statement is deprecated so you should avoid using it in new applications.

    • DROP INDEX new heap rebuild (if applicable).

      System_CAPS_ICON_note.jpg Note

      Index page deallocation during a DROP INDEX operation is always fully logged.

Managing the transaction log

Backing Up the Transaction Log (Full Recovery Model)

Restoring the Transaction Log (Full Recovery Model)

Control Transaction Durability
Prerequisites for Minimal Logging in Bulk Import
Back Up and Restore of SQL Server Databases
Database Checkpoints (SQL Server)
View or Change the Properties of a Database
Recovery Models (SQL Server)

Community Additions

© 2016 Microsoft