SQLServer日志满了，写不了检查点，数据库卡住了得赶紧截断日志或者扩容，不然出大问题

（根据CSDN博客《记一次SQL Server事务日志已满的排查与解决》中的描述）那天下午，业务系统突然卡住了，用户打电话来说页面一直在转圈圈，什么都做不了，我赶紧远程连接到服务器，发现数据库确实响应极慢，几乎处于僵死状态，打开SQL Server的管理器，看到数据库旁边显示着“可疑”两个字，心里当时就咯噔一下，紧接着，我去查SQL Server的错误日志，里面密密麻麻地刷着类似“由于'LOG_BACKUP'，数据库'YourDatabase'的事务日志已满”这样的错误消息，最要命的是，还看到了“写检查点”失败的记录，我当时就明白了，这是事务日志文件撑满了整个磁盘空间，导致数据库连最基本的状态检查点都无法记录,整个写操作都被阻塞住了。

（根据微软官方文档《解决事务日志已满的问题（SQL Server错误 9002）》的解释）事务日志满了，就像是数据库的“操作记事本”被写满了，一页空行都没有了，数据库每做一次数据修改，比如你下个订单、改个价格，它不会立刻去动那个庞大的数据文件，而是先在这个“记事本”（也就是事务日志文件）里清清楚楚地记下一笔：“在什么时间，把哪个表的哪一行数据，从什么状态改成了什么状态”，这样设计本来是为了保证数据安全，万一系统崩溃，可以根据这个记事本恢复过来，这个记事本还有一个重要作用，就是支持“检查点”操作，检查点就像是定期把记事本里已经确认无误、并且已经落实到正式账本（数据文件）上的记录打个勾，表示这些记录可以归档或者清掉一部分空间来写新内容了，但当日志文件满了，没有空闲空间来记录新的操作，连这个打勾的动作（检查点）也做不了的时候，数据库为了不丢失数据，就会干脆拒绝所有需要写日志的操作，比如你的增删改,整个数据库就卡在那里了。

（综合自知乎专栏《DBA手记：生死时速！处理SQL Server日志爆满实战》和博客园《一次SQLServer数据库日志文件爆满的处理过程》）遇到这种情况，绝对不能简单地重启数据库服务，因为重启过程中，数据库会尝试进行恢复操作，这个操作本身也需要写日志，如果日志空间不足，可能导致恢复失败，甚至使数据库一直处于恢复中无法上线，那问题就更大条了，当务之急是立刻释放日志空间，最直接、最安全的办法（如果恢复模式不是简单模式的话）就是赶紧做一个事务日志备份，因为对于完整或大容量日志恢复模式的数据库，只有在做了日志备份之后，SQL Server才会认为这部分日志记录已经持久化到备份文件里了，从而标记这部分日志空间为可重用（截断），我当时的操作是，立刻打开SQL Server Management Studio，找到那个出问题的数据库，右键点击“任务”->“备份”，在备份类型里选择“事务日志”，然后执行备份，备份完成后，你会立刻看到日志文件的空间使用率大幅下降，数据库的写操作通常就会自动恢复，卡住的进程也会继续运行,用户那边页面很快就恢复正常了。

（引用自ITPUB论坛讨论帖《紧急：SQL Server 日志满，数据库挂起》）有时候会遇到更棘手的情况，可能因为某些原因，日志备份操作本身也失败了，或者备份了之后空间释放得很少，问题依旧，这时候就需要更进一步的排查，可以用一些命令查看当前是什么事务在占用大量的日志空间，是不是有某个超长的事务一直没提交，导致它开始之后的所有日志记录都无法被截断，如果发现有这样的“罪魁祸首”事务，可能需要联系开发人员确认后，强制终止这个事务（这有风险，可能导致数据不一致），如果日志文件本身设置的大小就不合理，初始值太小或者增长幅度设得太小（比如每次只增长1MB），那么即使经常做日志备份，也可能因为业务高峰时段操作密集，日志增长速度超过备份释放速度而导致瞬间爆满，这时候,就需要考虑扩容了。

（根据《SQL Server中央目录：管理事务日志》中的建议）扩容分为两种思路，一种是临时应急，直接扩大日志文件所在的磁盘分区容量，如果磁盘还有未分配空间，这是最快的办法，另一种是长远规划，修改日志文件本身的属性，就是在数据库属性里，找到文件设置，把日志文件的初始大小调大，比如从原来的10GB直接设置为50GB，同时设置一个合理的、较大的增长幅度，避免频繁的自动增长操作影响性能，但要注意，扩大文件大小这个操作本身，在磁盘空间已经非常紧张的情况下也可能失败,所以最好在问题发生前就做好容量规划。

（参考了开源中国社区的一篇总结《预防重于治疗：SQL Server日志管理最佳实践》）还有一种特殊情况，就是如果这个数据库允许一定程度的数据丢失（比如一些非核心的测试或报表库），可以将其恢复模式设置为“简单”模式，在简单模式下，SQL Server会自动在检查点发生时截断不再需要的日志部分，基本上不会出现日志无限增长的情况，但这意味着你无法进行时间点恢复，只能恢复到上一次完整备份或差异备份的时刻,所以这个选项一定要谨慎评估业务需求后才能使用。

SQL Server日志满了导致数据库卡住，是一个需要DBA快速响应的紧急故障，核心思路就是“释放空间”和“扩大空间”，首选方案是立即执行事务日志备份来释放空间，这是最标准、最安全的做法，如果备份无法解决问题或作为临时措施，才考虑终止长时间未提交的事务或紧急扩容，最重要的是，平时要建立完善的日志备份策略和监控告警机制，定期检查日志文件的大小和空间使用率，防患于未然，避免这种紧急情况在业务高峰时段突然发生，那可就真是手忙脚乱了，每次处理完这种故障，都应该写个事后总结，分析根本原因，是备份任务失败了？还是突然来了个异常大量数据操作？然后相应地调整备份策略、优化应用程序代码或者调整数据库配置,这样才能避免同样的问题再次发生。