SQL Server 事务日志暴涨、收缩不动实测：没做日志备份前 SHRINKFILE 只从 1736MB 缩到 1544MB，「切 SIMPLE 三步法」让 BACKUP LOG 直接报 4214

实例是 Docker 里的 SQL Server 2022 Developer（RTM-CU27-GDR，16.0.4305.5）。loglab 数据文件 1024MB，日志初始 8MB、每次自动增长 64MB，建库后立刻 ALTER DATABASE … SET RECOVERY FULL——很多应用的建库脚本、以及 model 库默认值都是 FULL，这一步很有代表性。

每一步之后我都记一行状态：恢复模式、sys.databases.log_reuse_wait_desc、sys.dm_db_log_space_usage 的日志大小和已用、sys.dm_db_log_info 的 VLF 总数和活动 VLF 数，以及 sys.database_recovery_status.last_log_backup_lsn 是否为 NULL。下面的表都是这一行的摘录。

建库后不做任何备份，连跑 3 轮更新：日志从 392MB 长到 776MB 后就不动了，已用只有 12.5–38.4MB，log_reuse_wait_desc 一直是 NOTHING，last_log_backup_lsn 为 NULL。也就是说，这个库名义上是 FULL，实际行为和 SIMPLE 一样，CHECKPOINT 就截断。业内管这个叫「伪简单模式」。

做完一次完整备份（218ms，28474 页）之后，日志链开始了，情况立刻反转：同样 3 轮更新，日志 840 → 1288 → 1736MB，已用 495.6 → 953.3 → 1411.2MB，VLF 41 → 55，log_reuse_wait_desc 变成 LOG_BACKUP。所以「我们以前一直没事，最近突然涨」的库，常常是最近有人第一次给它做了完整备份，却没配日志备份。

接着我做大多数人的第一反应：DBCC SHRINKFILE (loglab_log, 64)。它 12ms 就返回了，没有任何报错，但日志只从 1736MB 变成 1544MB，已用 91.7%，活动 VLF 51 个——收缩只能砍掉文件尾部不活动的 VLF，前面 1.4GB 全是没备份的日志，一个字节都动不了。

做第 1 次日志备份（888ms，176468 页，压缩后 .trn 78.6MB）后已用降到 1.9MB，再收缩也只到 648MB：此时唯一的活动 VLF 落在文件中段，收缩不能越过它。第 2 次日志备份（61ms）让活动位置绕回文件开头，第三次收缩才到 72MB、8 个 VLF。第二遍复跑是一样的 1544 → 648 → 72MB。

这是我排查时最容易误判的场景。我在另一个会话里 BEGIN TRAN、往 job_log 插 1 行、不提交（模拟卡住的作业或没关的 SSMS 窗口），然后跑一轮更新，并把日志 MAXSIZE 限制为 640MB 模拟磁盘满。日志备份之后 used 只从 613.9MB 降到 606.8MB，下一轮更新直接报：Msg 9002, The transaction log for database 'loglab' is full due to 'LOG_BACKUP' and the holdup lsn is (257:63376:2)。

注意错误里写的是 LOG_BACKUP，sys.databases 里也还是 LOG_BACKUP——可我刚刚做过日志备份。真正的原因要用 DBCC OPENTRAN 看：OLDACT_SPID 77，开始 LSN (257:63464:2)；只读 SQL 第 5 段显示 session 77、login sa、程序 SQLCMD、正在 WAITFOR，事务已开 5 秒，它自己写的日志不到 1KB。它之后产生的所有日志都不能截断。

我又单独做了一组（E3b）：开着事务连做 3 次日志备份，第 1 次把 used 从 930MB 降到 467MB，之后两次只备份了 2 页和 5 页，used 一直 467MB，这时 reuse_wait 才变成 ACTIVE_TRANSACTION；CHECKPOINT 也没用。事务提交之后、下一次备份之前，它仍然写着 ACTIVE_TRANSACTION；再备份一次才变 NOTHING、used 20MB。

网上最常见的「清日志」做法是：ALTER DATABASE … SET RECOVERY SIMPLE → CHECKPOINT + DBCC SHRINKFILE → SET RECOVERY FULL。我照做：一轮更新后日志 1280MB、已用 477.5MB，三步之后变成 72MB、8 个 VLF，看起来完美。

但紧接着 BACKUP LOG 失败：Msg 4214, BACKUP LOG cannot be performed because there is no current database backup，外加 Msg 3013。更隐蔽的是接下来：再跑一轮会产生 450MB 日志的更新，日志只长到 776MB、只用了 3.6MB，last_log_backup_lsn 又变回 NULL——库回到了 E1 的伪简单模式。监控只看「日志使用率」的话，这时一片绿。

补一个差异备份（183ms）后 BACKUP LOG 恢复正常。msdb.dbo.backupset 里能看到断点：切换前最后一个日志备份 last_lsn 是 331000003743200001，切换后的第一个日志备份 first_lsn 是 377000000452000001，中间不连续。从切 SIMPLE 到差异备份这段时间，任何时间点都恢复不了。

收缩得太狠，日志就要在业务高峰重新长回来。我用同一个大事务（两轮全表更新、约 900MB 日志，一次提交）比较 4 种日志设置，每种重建库跑 3 次。SQL Server 2022 的规则是：每次增长 ≤64MB 只建 1 个 VLF，所以 1MB 增长长到 1.5GB 会留下 1522 个 VLF。

耗时差别很明显：1MB 增长 3907–4211ms，10% 和 64MB 都在 2.2–2.5s，预分配 2GB 只要 1268–1746ms。但我也要如实说：本次 1522 个 VLF 时，从完整备份还原（1.57–1.85s）和脱机再联机（126–132ms）没有看出比 16 个 VLF 慢（1.65–2.05s、144–151ms）——这个量级在 1.5GB 日志、热缓存下体现不出来，「VLF 多导致恢复慢」要到更大的日志和崩溃恢复场景才明显，我没测到，就不下结论。

写之前我列了五个角度：收缩前先看 reuse_wait；反对「切 SIMPLE 三步法」；日志文件大不是病、备份后不降才是；FULL 不做日志备份等于花 FULL 的磁盘买 SIMPLE 的恢复能力；1MB 增长让写入慢 2–3 倍。最后我选的判断是：恢复模式是 RPO 的决定，不是磁盘空间的决定。

理由很直接。FULL 模式唯一的价值是能用日志备份恢复到某个时间点；不做日志备份，你承担了 E1 里每轮 450MB 的日志增长，却拿不到这个能力。反过来，如果业务能接受「丢到上一次完整/差异备份」，就明确用 SIMPLE，并把完整/差异备份的频率按 RPO 定好——这不丢人。最糟糕的是两头都不要：FULL、不做日志备份、日志满了就切 SIMPLE 清一下，结果既有磁盘告警，又有 E4 那种自己都不知道的日志链断点。

我的建议具体到动作：要时间点恢复的库，日志备份间隔 ≤ RPO（例如 RPO 15 分钟就 15 分钟一次），每季度至少做一次「完整 + 日志链」还原到另一台机器；日志按峰值预分配后不再收缩。只有在一次性大操作（历史数据清理、重建索引）之后，才在备份完成后手动收缩一次。

下载区的只读 SQL 全是 SELECT（不备份、不收缩、不改恢复模式、不 KILL），在本次测试实例上跑通。它按我排查时的顺序输出 6 段：每个库的恢复模式 / reuse_wait / 日志大小 / 增长设置 / VLF；FULL 库的最近完整、差异、日志备份和伪简单模式判断；最近 20 次备份的 LSN（看日志链断没断）；当前库的日志使用率；最老的活动事务；当前最多能缩到多少。