直接执行DBCC SHRINKFILE会失败，因VLF中存在未截断活动日志；须先通过BACKUP LOG、处理长事务等方式使日志可截断，再收缩至合理大小，并确保定期日志备份以保障RPO。
直接执行 DBCC SHRINKFILE 会失败，因为日志文件正被使用
生产环境里，DBCC SHRINKFILE 报错 “无法收缩日志文件，因为该文件不是空的” 是最常见现象。这不是命令写错了，而是 SQL Server 日志文件的物理结构决定的：只要 VLF（Virtual Log File）里还有未截断的活动日志，就无法真正释放空间。而活动日志通常来自未备份的事务、长时间运行的事务、或恢复模式为 FULL 但从未做过 BACKUP LOG。
必须先让日志“可截断”，否则所有收缩操作都是徒劳
判断日志是否可截断，看 sys.databases 的 log_reuse_wait_desc 列：
SELECT name, log_reuse_wait_desc FROM sys.databases WHERE name = 'YourDB';
常见阻塞原因及对应动作：
-
LOG_BACKUP→ 立即执行BACKUP LOG YourDB TO DISK = 'nul'（仅测试用）或真实备份路径 -
ACTIVE_TRANSACTION→ 执行DBCC OPENTRAN('YourDB')找出长事务，联系业务确认能否中止 -
REPLICATION→ 检查sp_helpreplicationdboption，确认复制是否滞后，必要时EXEC sp_repldone（仅限已弃用复制链） -
AVAILABILITY_REPLICA→ 在 AlwaysOn 环境中，检查次要副本同步状态和日志发送队列
不要用 SET RECOVERY SIMPLE 临时切换来“清日志”
这是老系统运维里流传最广的危险操作。它确实能快速释放空间，但代价是：永久丢失从上次完整备份到现在的所有事务日志，无法做时间点还原。在生产库上执行等同于主动破坏 RPO（恢复点目标）。尤其当数据库启用了 CDC、Change Tracking 或镜像时，SIMPLE 模式会导致这些功能异常甚至元数据损坏。
正确做法是：
- 确保
RECOVERY FULL模式下，已建立定期BACKUP LOG作业（例如每15分钟一次） - 备份后立即跟
DBCC SHRINKFILE，且只收缩到合理大小（如 2GB），避免频繁自动增长 - 用
sys.dm_db_log_info查看 VLF 数量，如果超过 1000 个，说明日志文件长期碎片化，需重建（通过备份+收缩+调整初始大小）
BACKUP LOG ... WITH NO_LOG 已不可用，别再搜旧文档了
SQL Server 2008 起，WITH NO_LOG 和 WITH TRUNCATE_ONLY 就被移除。现在执行会报错：Msg 155, Level 15, State 1: "NO_LOG" is not a recognized BACKUP option. 所有声称“一行命令清空日志”的脚本，背后要么是切换恢复模式，要么是调用已被废弃的内部过程（如 sp_dboption），在 SQL Server 2016+ 上大概率失效或引发一致性风险。
真正可控、可审计、可回滚的方式只有一种：按备份链走。哪怕只是临时备份到 NUL 设备（仅 Windows），也比强行破坏日志头要安全：
BACKUP LOG YourDB TO DISK = 'NUL' WITH FORMAT, INIT;
注意：NUL 不是跨平台方案，Linux 上要用 /dev/null；且该操作仍计入日志备份链，不影响后续还原流程。
日志文件不是磁盘垃圾，它是数据库可恢复性的唯一凭证。所谓“安全截断”，本质是让日志空间循环复用，而不是把它删掉。任何跳过备份环节、绕过日志链校验的操作，在生产环境里都等于在事务日志上走钢丝。
