SQL Server 数据库日志文件过大压缩步骤

准备工作

在开始操作前，请确认拥有该 SQL Server 实例的足够权限（通常需 sysadmin 角色）。此外，强烈建议在执行任何脚本操作之前，对当前数据库进行完整备份，以防操作意外导致数据丢失。

操作步骤

第1步：查看数据库属性

为了后续脚本中正确填写参数，首先需要获取目标数据库的实际名称及日志文件的逻辑名称。

第2步：修改恢复模式为“简单”

将数据库的恢复模式从 "完整" (Full) 切换为 "简单" (Simple)。这一步会自动截断事务日志，清除不再需要的历史记录，为后续压缩做准备。

1. 打开查询窗口，连接到 [master] 数据库。
2. 执行以下 SQL 语句：

   --切换到主库
   use [master]
   go
   --修改数据库恢复模式为简单
   alter database [dbname] set recovery simple with no_wait
   go
   alter database [dbname] set recovery simple
   go

注意：请将脚本中的 [dbname] 替换为你的实际数据库名称。

第3步：执行日志压缩

切换到目标数据库，使用 DBCC SHRINKFILE 命令压缩日志文件。

1. 将上下文切换回目标数据库：use [dbname]
2. 执行压缩脚本：

   use [dbname]
   go
   --N'dblogname' 为日志文件的逻辑名称，11 为目标大小(MB)，可忽略或填0表示最小化
   dbcc shrinkfile (N'11,truncateonly)
   go

说明：

• N'dblogname'：指日志文件的逻辑名称（而非文件名），通常在数据库属性 -> 文件页可见。
• truncateonly：指示 SQL Server 仅释放文件末尾可用空间而不移动数据文件内部数据。

第4步：在 SSMS 中验证状态

脚本执行完毕后，可以在图形界面查看压缩效果。

选择目标数据库，右键点击选择 任务 (Tasks) → 收缩 (Shrink) → 文件 (Files)。

在弹出的窗口中，确认文件类型为“日志”。你会发现虽然物理文件大小可能暂时仍较大，但“可用空间”已显著增加，表明日志已有效截断。

第5步：恢复恢复模式

为防止未来因故障无法进行精确时间点恢复，操作完成后务必将数据库改回完整的记录模式。

1. 再次连接至 [master] 数据库。
2. 执行恢复命令：

   use [master]
   go
   alter database [dbname] set recovery full with no_wait
   go
   alter database [dbname] set recovery full
   go

完成判断

脚本运行正常无报错，且数据库日志逻辑空间被释放即可认为成功。在实际监控中，日志文件的大小可能会随着业务重启或下一次检查点（Checkpoint）操作而真正缩小到较小的数值（如示例中缩小至数百 MB）。

简要总结

手动压缩 SQL Server 日志的核心逻辑是：切简模式 → 截断日志 → 收缩文件 → 切全模式。这适用于日志文件极度臃肿且不常发生大规模事务操作的场景。如果问题频繁出现，可能需要排查是否有长期运行的未提交事务阻碍了日志截断。

以上就是 SQL Server 压缩数据库日志文件的详细内容，更多关于 SQL Server 管理优化的资料请关注本站其它相关文章！