SQL Server 数据库 Suspect 解决案例

生产环境： SQL Server 2008 R2 Active/Passive Nodes,Windows Server 2008 R2 SP1 Cluster, vSphere 5.x 发生起始 6 am 接到Application Team报告 BiztalkMsgBoxDb进入suspect模式，不可以访问。 报告事件，减少用户压力 简单的和App Manager电话了下，了解

　　生产环境：

　　SQL Server 2008 R2 Active/Passive Nodes,Windows Server 2008 R2 SP1 Cluster, vSphere 5.x

　　发生起始

　　6 am 接到Application Team报告 BiztalkMsgBoxDb进入suspect模式，不可以访问。

　　报告事件，减少用户压力

　　简单的和App Manager电话了下，了解他们Apps层面down time,在Ticket中录入大概发生时间，事件描述，最近有没有发生过任何变更事件。如果没有Ticket系统，请群发email给相关人员。电话Incident Manager管理所有的事件更新，这样做的好处：使惊慌失措的人们知道发生了什么，减少他们的压力。

　　整理一下自己

　　6:30 am很多人的电话总让自己神经紧张，简单的brainstorm一下suspect可能发生的原因：文件组(数据和日志)的损坏?磁盘爆满/SAN Disk出错?备份还在吧?

　　察看Error Log,定位起始出错信息

　　6:40 am查找到最初的错误，发生在成功的 Log backup以后的1分钟，错误信息显示：OS Error导致了LogWriter的log flush (写日志)失败。不能写日志会导致数据suspect.

　　2014-03-17 03:15:56.05 spid5s Error: 17053, Severity: 16, State: 1.

　　2014-03-17 03:15:56.05 spid5s LogWriter: Operating system error1117(failed to retrieve text for this error. Reason: 15105) encountered.

　　2014-03-17 03:15:56.05 spid5s Write error during log flush.

　　2014-03-17 03:15:56.05 spid79 Error: 9001, Severity: 21, State: 4.

　　2014-03-17 03:15:56.05 spid79 The log for database 'BizTalkMsgBoxDb' isnot available. Check the event log for related error messages. Resolve anyerrors and restart the database.

　　2014-03-17 03:15:56.05 spid85 Error: 9001, Severity: 21, State: 4.

　　分析错误：

　　1117 OS错误，有关磁盘。日志文件还在，磁盘没有满。可以考虑对log file迁移。

　　第一次尝试 DBCC Repair

　　(任何尝试的基础都是要明白：你的动作，不会使情况变得更糟糕)

　　命令 ALTER DATABASE [xxxxxx]SET EMERGENCY;

　　命令出错， 数据库被锁，不能alter database ,直接放弃DBCC CHECKDB (N'xxxxxxx', REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS, ALL_ERRORMSGS;修复。

　　为什么要放弃： DBCC Repair 要求数据库在 emergency模式下，它会试图利用现有log 把数据库恢复到一致性上(consistent recover)。如果 log有问题， 那么它 会重建 log ( 个人认为这就是repair allow data loss的意思) .对于一个100 GB以上的数据库， rebuild log可能花费数小时，考虑到recovery time object (RTO)和 SLA (service level agreement) , 都不允许数据库 downtime 很久 (事后的反思)。幸运的是不能alter database,错误信息直接指明了database log locked, 暗示了数据库 log可能没有 corrupt, 那么没有必要着急dbcc repair了。

　　事后反思，武断的认为log file corrupted 是错误的，dbcc repair作为 methodology 的第一步也是不合时宜的，应为没有向用户确认是否可以丢失过去15分钟的active transaction (虽然客户还在睡觉) ( 每15 分钟的事务日志备份)，更何况它还会让数据库 downtime更久，8点上班前未必恢复的了，可能都没有database backup restore快。作为methodology第一步应该首先确认是否file corrupted 并且联系server team是否有IO异常。

　　第二次尝试 迁移日志文件

　　遇到 resource lock 的问题，通常的 第一反应都是kill 或者 重启资源。这里限于自己技能不足或者没有建立正确的methodology,第一时间发现不了lock的资源，所以选择了重启资源

　　应为是Windows Cluster,所以不用detach/attach数据库，直接failover到passive server,数据库在failover后等效的重起和实例恢复了。现在日志文件可写，数据库恢复到Active.

　　暂时解决了问题，然后将数据库switch over到原来的 active服务器。没有出错，证明不是磁盘本身的问题。可能是磁盘接口问题。同时查看了event viewer除了log backup没有发现其他。Sp_who2也没有发现可疑的database lock排除了数据库进程锁住数据库或者logfile.

　　建立问题

　　7 am,让Server Team检查磁盘，怀疑EVA SAN出问题。 现在只知道起始错误和解决方法。作为一个问题，留给Problem Manager继续更进，用来避免以后发生同样的问题。

　　总结：遇到 log file 导致的 数据库挂起，，解决方法学首先是(1)确认磁盘问题，然后是(2 ) 确认数据库process lock,然后是(3)确认是否 corrupt, 这些 check up 做完后再针对(1) (2)(3) 提出解决方案。从(1) 到 (3)严重性也越高， 所以恢复后数据丢失的可能性也越高。要和客户确认在线修复的风险。最后的稻草自然是平时完备的数据备份方案和定期的数据库恢复执行计划。