SQL Server Log Won’t Truncate: What log_reuse_wait_desc Is Telling You

The Log Will Not Truncate and the Backups Are Running

A transaction log is filling a disk, or it has stopped shrinking, and the backup job says it succeeded. Before touching anything, ask SQL Server why it will not reuse the space. It already knows, and it will tell you in one column.

SELECT
    name,
    recovery_model_desc,
    log_reuse_wait_desc
FROM sys.databases
WHERE state_desc = 'ONLINE'
ORDER BY CASE WHEN log_reuse_wait_desc = 'NOTHING' THEN 1 ELSE 0 END, name;

That column is log_reuse_wait_desc. It is the single most useful thing in sys.databases during a log incident, because it turns “the log is full” into a specific, named reason with a specific fix. Everything else in this post is what the values mean.

Reading It On A Real Instance

Output from the lab, using Get-LogReuseWaits, which adds recovery model, log size and last log backup beside the reason:

database_name    recovery_model  log_reuse_wait  log_size_mb  last_log_backup          status
---------------  --------------  --------------  -----------  -----------------------  --------------------------
DBAMonitor       FULL            LOG_BACKUP            584.0  NULL                     ACTION: take a log backup
DemoDatabase     FULL            LOG_BACKUP            512.0  2026-07-28 08:00:02.000  ACTION: take a log backup
migdb_37A45A06   FULL            LOG_BACKUP            160.0  2026-07-28 08:00:02.000  ACTION: take a log backup
migdb_7049216A   FULL            LOG_BACKUP            160.0  2026-07-28 08:00:02.000  ACTION: take a log backup
migdb_751FB44B   FULL            LOG_BACKUP            160.0  2026-07-28 08:00:02.000  ACTION: take a log backup
migdb_B8A15B78   FULL            LOG_BACKUP            160.0  2026-07-28 08:00:03.000  ACTION: take a log backup
migdb_A9250FB6   FULL            NOTHING               160.0  2026-07-28 08:00:02.000  OK
zzidx_db         FULL            NOTHING                72.0  NULL                     OK

Six databases in FULL recovery waiting on a log backup, and a last log backup 35 days old. That is not six problems. It is one missing job, and the column found it in a second.

Every Value, And What To Do About It

Microsoft documents thirteen values. Three of them account for almost every real incident, so those get the detail:

The Rarer Values

You are unlikely to meet these, and most clear on their own. They are here so that a value you have never seen does not turn into an investigation.

• NOTHING and CHECKPOINT, healthy. If the file is still enormous, that is a sizing question, not a truncation one.
• ACTIVE_BACKUP_OR_RESTORE, a data backup or restore is running. Self-clearing, and only a problem when a full backup takes hours.
• REPLICATION, transactions not yet delivered to the distributor. Change data capture counts here too. Check the Log Reader Agent is alive, because a dead one grows the log without limit.
• DATABASE_MIRRORING, the mirror is paused or a long way behind. Increasingly rare, since mirroring is deprecated.
• DATABASE_SNAPSHOT_CREATION, a snapshot is being created. Worth knowing that DBCC CHECKDB builds an internal one, so this can appear during a routine integrity check.
• LOG_SCAN, something is reading the log. Routine and normally brief.
• OLDEST_PAGE, indirect checkpoints are on and the oldest dirty page predates the checkpoint LSN. More visible than it used to be, because indirect checkpoint is the default for databases created on SQL Server 2016 and later.
• XTP_CHECKPOINT, an In-Memory OLTP checkpoint is needed. Only relevant with a memory-optimized filegroup, where Microsoft says to expect this or CHECKPOINT as normal.
• SLOG_SCAN, Accelerated Database Recovery is scanning its secondary log stream. SQL Server 2019 and later, and the value the documentation covers worst, see below.

Microsoft’s Own Two Pages Disagree

Worth knowing before you go looking things up mid-incident, because it will waste your time otherwise. The sys.databases reference lists thirteen values and points you at the transaction log page for “more detailed explanations”. That second page does not cover SLOG_SCAN at all, and it lists a value called OTHER_TRANSIENT that the first page does not.

So the page with the fullest explanations is missing the newest value, and the two pages disagree about a string. Neither is wrong exactly, they were updated at different times. If you land on the transaction log page and cannot find your value, that is why.

Frequently Asked Questions

Related

• Get Log Reuse Waits, the script behind the output above
• SQL Server transaction log full (error 9002), when it has already filled
• Recovery models explained, if LOG_BACKUP was a surprise
• Get VLF Counts, for a log that is fragmented rather than full
• Storage & Capacity, the pillar this sits in

Summary

When a log will not truncate, SQL Server already knows why and stores the answer in log_reuse_wait_desc. Read that column before you shrink anything, change a recovery model, or add a file. Three values cover almost every case: a missing log backup, an open transaction, or a secondary replica that has not caught up. The rest are mostly routine and clear on their own.