生产环境：
发生起始
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更久，８点上班前未必恢复的了，可能都没有database backup restore快。作为methodology第一步应该首先确认是否file corrupted 并且联系server team是否有IO异常。
