做数据库运维的人，最怕半夜手机响。尤其是那种带着哭腔的电话：“库挂了，起不来了。”等你远程连上去一看，SQL Server的数据库状态栏里，赫然写着“Recovery Pending”。翻译过来就是“回避恢复模式”，这五个字，比“正在恢复”更可怕。因为“正在恢复”好歹还在干活，而“回避恢复”基本等于数据库罢工了——它不让你连，也不让你操作，就那么僵在那儿，像一头倔驴。
这玩意儿是怎么来的？说白了，就是SQL Server在启动或恢复数据库时，碰到它认为“搞不定”的障碍，于是撂挑子不干了。最常见的导火索是磁盘满了——日志文件没地方写；或者文件权限被改了——服务账户突然没权限访问数据文件；再或者就是文件被其他进程锁住了。还有一种情况比较坑，就是数据库文件本身没坏，但SQL Server在恢复时发现日志链断了，比如你之前做日志备份时手工删过日志文件，那它就会进入这种自我保护状态。
遇到这种情况，第一反应千万别慌，更别直接去点“分离数据库”或“删除数据库”。我见过太多新手栽在这上面——本来只是回避恢复，结果一分离，再想附加回来，直接报错“文件已损坏”，那才是真的哭都没地方哭。正确的第一步，是先确认磁盘空间。打开资源管理器，看看C盘和数据库所在盘符还有多少剩余空间。如果连1GB都不到了，那基本就实锤了——日志膨胀把磁盘塞满了。这时候二话不说，先清理临时文件、移动备份文件，把空间腾出来，然后重启SQL Server服务，很多情况下数据库自己就缓过来了。
如果空间没问题，那就要看权限了。右键点击数据库的MDF和LDF文件，看看“安全”选项卡里，SQL Server服务账户是不是有完全控制权限。很多企业环境里，IT管理员喜欢定期改密码，一改，服务账户的权限就乱了。这时候你只需要把权限重新授予，再重启服务，数据库一般就能从回避模式里爬出来。这个方法成功率大概在六成左右，而且操作简单，不会造成任何数据损失，建议作为第二优先级的尝试。
要是上面两步都试了还是不行，那就得动真格的了。这时候你需要打开SSMS，用“管理员模式”跑一条命令：ALTER DATABASE [你的库名] SET EMERGENCY。这个命令会让数据库进入紧急模式，相当于告诉SQL Server：“兄弟，我知道你受伤了，但咱先别躺平，我把你扶起来坐着。”然后紧接着跑一条：ALTER DATABASE [你的库名] SET SINGLEUSER WITH ROLLBACK IMMEDIATE。这条是强制断开所有连接，把数据库踢到单用户模式。做完这两步，你再跑DBCC CHECKDB，让它检查并修复一致性错误。
这里要敲黑板了——DBCC CHECKDB跑出来的结果，是决定命运的时刻。如果它报告“0 errors”，恭喜你，数据库其实是完好的，只是恢复路径上卡了壳。你只需要再执行一条ALTER DATABASE [你的库名] SET MULTIUSER，把数据库拉回多用户模式，一切就恢复正常了。但如果DBCC CHECKDB报了一堆错误，那就得根据错误级别来应对。级别在10以下的，通常可以直接用REPAIR_REBUILD修复；但要是级别在10以上，或者涉及页损坏、分配错误，那强制修复很可能会导致数据丢失——这时候你就要权衡了，到底是接受部分数据损失，还是赶紧联系专业的数据恢复公司。
还有一种情况，是数据库本身没坏，但日志文件彻底废了。比如你发现LDF文件大小是0字节，或者文件路径对不上。这时候你可以尝试“重建日志”的骚操作：先把数据库设为紧急模式，然后分离它，再重新附加，但在附加时把日志文件那一栏删掉，只附加MDF。SQL Server会误以为日志丢了，自动帮你重建一个全新的日志文件。这个方法能救回数据，但有个副作用——日志链会断，意味着你没法做时点恢复，只能恢复到当前状态。对于非核心业务库，这招挺实用。
不过话说回来，上面这些操作，都是“事后诸葛亮”。真正的高手，从来不会让数据库走到这一步。我见过一个老运维，他给所有核心库都配了磁盘空间监控，阈值设在80%，超过就自动告警。还定期检查日志文件的大小，一旦发现日志增长异常，立刻排查是哪个大事务在作怪。更关键的是，他给每个库都做了完整的备份策略——全备、差备、日志备份，三层防护，就算真出了问题，也能从容地做时间点恢复，而不是像现在这样手忙脚乱地救火。
回到开头那个
