凌晨三点，数据手机开始疯狂弹告警。疑何我眯着眼看了一眼，修复SQL Server 的数据数据库状态变成了“可疑”。那一瞬间，疑何心跳绝对漏了一拍。修复这不是数据演习，生产库挂了，疑何所有业务查询全部报错，修复页面一片空白。数据我灌了口凉水，疑何坐到电脑前，修复开始跟这个“可疑”状态死磕。数据

数据库为什么会“可疑”？疑何说白了，SQL Server 自己觉得这个库不干净了。修复可能是突然断电，可能是磁盘阵列掉盘，也可能是某个数据文件被误删或者损坏。它没法保证事务日志和数据文件的一致性，于是干脆把库锁起来，标记为 SUSPECT，谁也别想访问。这就像银行发现金库账本对不上，直接封门，等审计来查。

第一步，别慌着去重启服务。我见过有人一看到可疑就重启 SQL Server，结果重启完还是可疑，甚至更糟。先连上实例，查一下错误日志。我打开 SSMS，执行了这段：

SELECT name, state_desc, user_access_desc FROM sys.databases WHERE state_desc = 'SUSPECT';

果然，那个库赫然在列。接着看日志：

EXEC sp_readerrorlog 0, 1, 'suspect';

日志里写得很清楚：“无法打开文件 … 操作系统错误 5: 拒绝访问。” 错误 5 是权限问题。我愣了一下——权限？昨天刚有人动过服务器文件夹的 ACL。大概率是 SQL Server 的服务账户失去了对数据文件的读取权限。

这种情况其实算幸运的。如果是磁盘坏道或者文件头损坏，那就得走紧急修复模式。我先试着把权限改回来。找到数据文件所在目录，右键属性，安全，把 SQL Server 服务账户（这里是 NT Service\MSSQLSERVER）加进去，给完全控制。然后回到 SSMS，执行：

ALTER DATABASE [YourDB] SET EMERGENCY; ALTER DATABASE [YourDB] SET SINGLE_USER; DBCC CHECKDB ([YourDB], REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS; ALTER DATABASE [YourDB] SET MULTI_USER;

注意，REPAIR_ALLOW_DATA_LOSS 这行会丢数据。不到万不得已别用。我这次只是权限问题，所以先试了更温和的：

ALTER DATABASE [YourDB] SET ONLINE;

结果报错：“无法打开物理文件 … 拒绝访问。” 还是权限。我干脆重启了 SQL Server 服务，再执行 SET ONLINE。这次成功了。数据库状态从 SUSPECT 变回 ONLINE。我赶紧跑了个 DBCC CHECKDB，没有一致性错误。虚惊一场。

但不是每次都这么走运。去年有个客户，磁盘阵列同时坏了两块盘，数据库可疑。他们没备份，最后只能做 REPAIR_ALLOW_DATA_LOSS，丢了三天的订单数据。老板气得拍桌子。所以每次遇到可疑，第一反应应该是：有没有备份？有备份就还原，别折腾修复。还原最快，最干净。没有备份才考虑紧急模式、单用户、CHECKDB 修复。

还有个小细节：修复完成后，记得把数据库选项改回去。比如 SINGLE_USER 要改回 MULTI_USER，EMERGENCY 要取消。否则应用连不上，又是一轮新的告警。

我处理完这个案子，天已经蒙蒙亮。顺手把服务账户权限加了个监控脚本，一旦 ACL 变化就发邮件。数据库可疑不可怕，可怕的是没有预案、没有备份、还乱操作。下次再遇到，先看日志，再查权限，最后才动 CHECKDB。顺序错了，可能就把库彻底搞死了。