SQL Server 事务日志满了，先看 log_reuse_wait_desc

日志文件长到磁盘告警，收缩文件解决不了原因。SQL Server 要等占用日志尾部的那件事结束，才会把已有空间标成可重用。这件事写在 log_reuse_wait_desc 里。空间可重用之后，文件大小也不会自己变小。

先看是哪个库、恢复模式、以及在等什么：

SELECT
    name,
    recovery_model_desc,
    log_reuse_wait_desc
FROM sys.databases
WHERE database_id > 4;

再用空间数字对一下：

1	DBCC SQLPERF(LOGSPACE);

Log Size (MB) 是文件现在多大，Log Space Used (%) 是里面有多少还不能重用。log_reuse_wait_desc 为 NOTHING 时，只说明可以重用，文件不会因此变小。

常见的等待

LOG_BACKUP：恢复模式是 FULL 或 BULK_LOGGED，完整备份之后还没有日志备份。做一次该库的日志备份，等的原因会变成 NOTHING。改成 SIMPLE 也能截断，但会失去用日志备份恢复到某个时间点的能力。生产库不要为了腾空间改恢复模式。

ACTIVE_TRANSACTION：有事务没提交，日志从那个事务开始都不能重用。看是哪个会话、从什么时候开始：

1	DBCC OPENTRAN('库名');

输出里的 SPID (server process ID) 就是还开着事务的会话。它在干什么、要不要结束，按查阻塞那篇去看这个会话号。事务回滚或提交之后，再做日志备份（完整恢复）或等检查点（简单恢复），空间才会标成可重用。

ACTIVE_BACKUP_OR_RESTORE：备份或还原还在跑。等它结束，不要另开一个备份去「解」它。

AVAILABILITY_REPLICA：可用性组里有副本还没把日志收到或重做完。先看那个副本是否掉线、队列是否在涨。副本追上之前，主库收缩日志没有用。

REPLICATION：复制还没把日志里的事务送走。看日志读取器代理是否在跑，而不是先收缩。

其他值以微软文档里 sys.databases 的 log_reuse_wait_desc 为准。原因还在时执行 DBCC SHRINKFILE，文件会缩一点点又长回去。原因清掉、确认以后有日志备份，再决定要不要把文件缩到一个够用的大小。