Sqlserver数据库日志文件过大(收缩/裁剪处理)

起因是最近服务经常报错，发现是硬盘存储空间不够，由于暂时无法增加存储盘容量。

只能搬走的搬走，不能搬走的剩下就是数据库了，虽然可以移动数据库文件，但不到万不得已就先不移动数据库文件，并且发现数据库的日志文件好大，先从日志文件开始处理。

--处理前数据库日志文件223G，比数据库本体还大。

一般可能有三种原因：

1）长时间运行的事务：某个大规模操作（如大批量UPDATE、DELETE）开始后一直未提交或回滚。

2）恢复模式为 FULL 但未配置日志备份：这是最常见的原因。在完整恢复模式下，只有事务日志备份 (BACKUP LOG) 才能截断日志。如果只做完整备份而不做日志备份，日志会无限增长。

3）高可用/灾难恢复同步延迟：如果配置了AlwaysOn、镜像或复制，但辅助副本长时间不可用或同步严重延迟，主副本的日志也无法被截断。

1,先做事务日志备份（必须先备份，否则无法正常收缩日志）

-- 完整日志备份（先备份才能截断日志） BACKUP LOG 数据库名 TO DISK = 'D:\备份路径\数据库名_Log.bak' WITH COMPRESSION;

2,查看日志文件当前占用、可收缩空间

USE 数据库名 GO DBCC SQLPERF(LOGSPACE)

3,收缩日志文件（推荐收缩到业务合理大小，不要缩到极小避免瞬间暴涨）

-- 查看日志逻辑文件名 EXEC sp_helpfile; -- 收缩日志，示例收缩到2G DBCC SHRINKFILE (N'数据库日志逻辑名', 2048); 会返回一张表，字段： FileId：文件 ID CurrentSize：收缩后文件占用页数（每页 8KB） MinimumSize：文件最小可占用页数 UsedPages：当前实际已使用页数 EstimatedPages：SQL 预估可释放页数

优化：设置日志文件自动增长合理步长（避免频繁自动增长产生碎片），不要设置 1MB 小步长。

4,把当前正在写入的 SQL Server 错误日志文件归档封存，新开一个空白的错误日志文件用来记录后续日志

SQL Server 默认只会保留6 个错误日志文件：

• ERRORLOG（当前正在写的日志）
• ERRORLOG.1（上一轮归档日志）
• ERRORLOG.2
• ERRORLOG.3
• ERRORLOG.4
• ERRORLOG.5

每次执行一次sp_cycle_errorlog：

1. 当前正在写的ERRORLOG→ 重命名为ERRORLOG.1，旧的依次往后滚（.1→.2…….5会被直接删除）
2. 生成全新空白ERRORLOG用来记录新报错、运行日志

-- 循环归档错误日志，默认只保留6个，可清理旧日志 EXEC sp_cycle_errorlog;

5,收缩完成后务必重建索引，消除碎片：

-- 重建全表索引 ALTER INDEX ALL ON 表名 REBUILD;

注意：

不应将收缩操作视为常规维护操作。 由于定期业务作而增长的数据和日志文件不需要收缩作。 收缩命令会影响运行时的数据库性能。 应在低使用率期间运行它们。 如果常规应用程序工作负荷会导致文件再次增长到相同的分配大小，则不建议收缩数据文件。

参考：

管理事务日志文件大小 - SQL Server | Microsoft Learn