SQL Server日志满了别慌，这些办法试试看能不能解决问题

综合自CSDN博客、腾讯云社区、知乎专栏以及个人DBA运维经验）

SQL Server的日志文件（通常是那个.ldf文件）要是突然满了，确实会让人心里一咯噔，因为一旦日志满了，最直接的表现就是数据库几乎“卡死”了，任何需要写数据的操作，比如增删改，都可能报错失败，错误信息里经常会提到“事务日志已满”或者类似的提示，这时候别急着重启服务或者更冒险的操作，可以按照下面这些步骤，由简到繁、由安全到略有风险地试试看。

第一步：最安全快捷的尝试——备份事务日志

这是官方推荐的首选方案，也是很多有经验的DBA会第一个想到的，SQL Server的事务日志之所以会增长，是为了保证数据安全，它记录了你对数据库做的每一步修改，在“完整”或“大容量日志”恢复模式下，只有当你做了日志备份后，SQL Server才会认为这些已经被记录到备份里的日志空间是可以被重复使用的“空闲空间”，当日志满的时候,很可能就是因为很久没有做日志备份了。

怎么做呢？如果你之前从来没有设置过定期日志备份，可以立刻手动执行一次事务日志备份，打开SQL Server Management Studio (SSMS)，连接到你的数据库，在要处理的数据库上右键点击“任务”->“备份”，在备份类型里选择“事务日志”，然后执行备份，备份完成后，再去查看日志文件的大小，很多时候你会发现，虽然最大尺寸没变，但可用空间大大增加了，数据库立刻就恢复正常了,这招能解决大部分因为备份策略缺失导致的日志满问题。

第二步：检查并设置日志的自动增长

如果备份日志后问题暂时解决，但没过多久又满了，那可能是日志文件的“自动增长”设置不合理，你可以右键点击数据库->属性->文件，查看日志文件的自动增长设置，如果设置得太小，比如每次只增长1MB或10MB，那么当业务繁忙时，数据库可能需要频繁地暂停下来去分配新的磁盘空间，这种频繁的“挣扎”反而容易导致日志快速被占满。

一个改善的办法是，将自动增长的幅度设置得大一些，比如一次增长100MB或200MB，或者设置为按百分比增长（如10%），但要注意，不能设置得过大，以免一次增长耗尽磁盘空间，如果可能，最好预先分配一个足够大的初始尺寸,避免频繁自动增长。

第三步：万不得已时，考虑收缩日志文件

“收缩”操作要非常谨慎地使用，它是在日志文件确实已经变得异常巨大，并且通过备份已经释放了大量内部空间后，为了回收磁盘空间才进行的操作。绝对不要把“收缩”当作解决日志满的常规手段，因为它会导致日志文件碎片化，可能影响性能，而且如果根本原因没解决,它很快又会涨回来。

如果你确认已经做了日志备份，但文件物理大小还是很大，想把它变小一点，可以尝试收缩，在SSMS中，右键数据库->任务->收缩->文件，选择文件类型为“日志”，然后可以选择“释放未使用的空间”或者指定一个更小的目标大小，但收缩可能不会一次成功，有时需要配合多次备份-收缩的循环。

第四步：检查是否有长时间运行或异常的大型事务

日志满的罪魁祸首不是一个“静态”的文件设置，而是一个“动态”的、长时间运行的事务，有人开启了一个事务，执行了一个要处理几百万条数据的DELETE或UPDATE操作，但没提交也没回滚，这个活动的事务会阻止日志空间的正常重用，即使你做了备份，空间也无法释放,日志就会一直被撑大。

可以尝试运行一些查询来检查当前活动的事务，比如使用DBCC OPENTRAN命令来查看是否有很早开始但一直没结束的事务，如果找到这样的“元凶”，需要联系发起事务的用户或应用程序，让其提交或回滚该事务,这是治本的方法之一。

第五步：终极手段——在紧急情况下切换恢复模式

如果以上方法都来不及或者不奏效，数据库已经完全无法使用，业务中断压力巨大，可以考虑一种紧急应对措施：将数据库的恢复模式临时切换到“简单”模式，在简单模式下，SQL Server会自动回收可重用的日志空间，不需要日志备份,这个操作会立刻释放日志空间。

这个操作有巨大的代价：它会破坏日志链，意味着你无法做基于时间点的恢复，从上次完整备份到现在的所有数据变更将无法通过日志还原，所以这只能作为“保业务”的最后一招，并且切换后要立即做一个完整备份，然后根据情况决定是否要切回“完整”恢复模式并重新设置备份计划。

遇到日志满，别慌，先尝试备份事务日志，这通常能立刻见效，然后检查自动增长设置是否合理，收缩文件要小心使用，排查是否有异常长事务，最后才是考虑切换恢复模式这种有损恢复能力的紧急方案，最重要的是，问题解决后，一定要建立定期的完整备份和事务日志备份策略，这才是预防问题再次发生的根本办法，数据库管理,防大于治。