<p><a href="http://www.karaszi.com/SQLServer/info_corrupt_suspect_db.asp">原文链接</a></p> <p><strong>概述</strong> <br />遭遇一个损坏(corruption)或者置疑(suspect)的数据库是难得一见的事情. 然而, 它的确会发生, 大部分原因经常是硬件出错和操作错误(比如日志文件被删). </p> <p> </p> <b></b> <p><strong>更多信息</strong> <br />下面几点是处理这种情况(遭遇某种形式的数据库损坏或者数据库置疑)的建议. 这篇文章是在许多SQL Server MVP以及SQL Server开发组成员的帮助下编写完成的. <br />欢迎您以任何形式分享这些信息.</p> <p> <br /><strong>细节</strong></p> <ol> <li>确保拥有一个可以用来从硬件故障(含数据库损坏)中恢复的备份策略. 在大多数情况下建议数据库和日志文件两者都要备份. </li> <li>如果可能, 对数据库执行DBCC CHECKDB: 为返回的任何错误号搜索联机丛书和知识库. 那里可能会有针对你的错误信息的特定建议. DBCC的NO_INFOMSGS选项是有用的, 它使得DBCC只返回错误信息. </li> <li>找出故障发生的原因. 检查事件日志, 做硬件检测等等; 为那些错误搜索联机丛书和知识库. 你不会希望故障再次发生! 如果数据库被置疑, 数据库文件可能被例如防毒软件之类的占用那么重启SQL Server可能是你要做的全部 - 但是你仍需要读取日志等等来找出到底发生了什么. </li> <li>如果存在硬件问题, 确认替换掉出错的硬件. </li> <li>备份日志. 这里假设存在一个日志备份计划. 如果数据库是置疑的, 你必须使用带NO_TRUNCATE选项的BACKUP命令 . 并且, 你可能要做一个mdf和ldf文件的文件备份作为额外的安全性. </li> <li>[a] 还原是现在要做的最好事情. 如果你在上一步做了日志备份, 那么你很可能会没有数据损失. 然后还原最近的干净的数据库备份和随后的日志备份, 包含上一步做的日志备份. 如果是SQL Server 2005, 我们拥有页级别的还原, 意味着我们能够只还原损坏的页面(代替完整的备份)然后是随后的日志备份. <br />[b]如果数据库没有被置疑,那么带REPAIR选项的DBCC CHECKDB可能是第二选择,但是这通常会导致数据损失. 另外的解决方案, 取决于具体的错误, 可能是手工重建非聚簇索引, 如果数据是静态的手工扔掉和重新载入表, 诸如此类. <br />[c]如果数据库是置疑的并且Sql Server的版本是2000或者更早, 第二选择可以是尝试着使用sp_resetstatus"去置疑"数据库. 阅读关于它的文档(联机丛书, 知识库, google等等). 这样可能会有所帮助但是如果数据库损坏的太厉害, 这样可能只是再次跳回置疑状态. 这里还同样有叫做"紧急模式(emergency mode)"的东西, 它是一个为从严重损坏的数据库中取出数据而可以设置的"恐慌" 状态. 这个选项的名字说明了它自己. 再次搜索网络关于它的资料. </li> </ol> <br />如果你觉得上面的步骤靠不住, 我建议让<a href="http://support.microsoft.com/oas/default.aspx?gprid=2852">MS Support</a> 针对你的特定情况手把手带你通过这些步骤.
