升级SQL Server 2019后收缩日志作业引发崩溃，求优化方案

核心问题原因 #

你的作业每30分钟反复切换恢复模式+收缩日志，在SQL Server 2019中会引发严重性能问题：

• 切换恢复模式会直接中断事务日志链，若原本依赖FULL模式下的完整备份+日志备份策略，该策略会彻底失效
• 频繁收缩日志会导致日志文件严重碎片化，后续SQL Server写入日志时需要频繁扩展文件，引发IO阻塞甚至系统冻结
• SQL Server 2019对事务日志的管理机制比2008更严格，这种粗暴的操作更容易触发内部资源竞争

最优处理方案 #

方案1：永久切换到SIMPLE恢复模式（适合无需时间点恢复的场景） #

如果确实不需要通过事务日志做时间点恢复，直接将数据库固定在SIMPLE模式，无需再执行手动收缩作业：

ALTER DATABASE MyDB SET RECOVERY SIMPLE;
GO

• SIMPLE模式下，SQL Server会自动截断不活动的日志部分，无需手动干预
• 先手动收缩一次日志到合理大小（建议设为100MB，不要设1MB，过小会导致文件频繁自动扩展）：

DBCC SHRINKFILE (Places_log, 100);
GO

之后让日志保持该大小，SQL Server会根据业务需求自动增长，但不会无限制膨胀（SIMPLE模式下会自动截断无用日志）

方案2：保留FULL模式但优化日志管理（若需灾难恢复备份链） #

如果必须使用FULL恢复模式（比如需要完整备份+日志备份做灾难恢复）：

1. 立即停止当前每30分钟执行的收缩作业
2. 建立定期日志备份计划（比如每15分钟一次），日志备份会自动截断不活动的日志部分，阻止日志文件无限增长：

BACKUP LOG MyDB TO DISK = 'D:\Backup\MyDB_Log.bak' WITH INIT; -- 每次覆盖备份，若需保留历史备份可改用WITH NOINIT追加
GO

3. 手动收缩一次日志到合理大小（建议设为200MB），之后不再手动执行收缩操作
4. 调整日志文件的自动增长设置：改为按固定大小增长（比如每次增长1GB），不要用百分比增长，避免频繁小幅度扩展导致碎片化

绝对禁止的操作 #

• 不要启用AUTO_SHRINK（自动收缩）：该选项会在后台不定期收缩数据和日志文件，同样会引发碎片化和性能波动
• 不要反复切换恢复模式：会彻底破坏FULL模式的备份链，丧失灾难恢复能力

关键说明 #

SQL Server的事务日志是核心组件，无法完全禁用——哪怕是SIMPLE模式，也需要日志来保证事务的ACID特性（原子性、一致性、隔离性、持久性）。你的需求本质是控制日志文件大小，避免无限制膨胀，而非删除日志。

内容的提问来源于stack exchange，提问作者kivi12k