任何数据库系统都无法避免崩溃状况即使你使用了Clustered双机热备……仍然无法完全根除系统中单点故障何况对于大部分用户来说无法承受这样昂贵硬件投资所以在系统崩溃时候如何恢复原有宝贵数据就成为个极其重要问题了 在恢复时候最理想情况就是你数据文件和日志文件都完好无损了这样只需要sp_attach_db把数据文件附加到新数据库上即可或者在停机时候把所有数据文件(定要有master等)都copy到原有路径下也行不过般不推荐这样做法sp_attach_db比较好虽然麻烦许多 但是呢般数据库崩溃时候系统是未必能有时间把未完成事务和脏页等写入磁盘这样情况sp_attach_db就会失败那么寄期望于DBA制定了个良好灾难恢复计划吧按照你恢复计划还原最新完全备份增量备份或者事务日志备份然后如果你活动事务日志还能读得出来话恭喜你!你可以还原到崩溃前状态 般单位都是没有专职DBA如果没有可用备份更可能是最近次备份时间过于久远而导致不可接受数据损失而且你活动事务日志也处于不可用状态那就是最麻烦情况了 不幸很是般数据库崩溃都是由于存储子系统引起而这样情况是几乎不可能有可用日志用于恢复 那么就只好试下这些方案了当然是要求至少你数据文件是存在要是数据文件、日志文件和备份都没有了话别找我你可以到楼顶上去唱“神啊救救我吧” 首先你可以试下sp_attach_single_file_db试着恢复下你数据文件虽然能恢复可能性不大不过假如这个数据库刚好执行了个checkpo话还是有可能成功 如果你没有好到有摸彩票手气最重要数据库没有像你期盼那样attach上去不要气馁还是有别方案 我们可以试着重新建立个log先把数据库设置为emergency modesysdatabasesstatus为32768 就表示数据库处于此状态 不过系统表是不能随便改设置下先 Use MasterGosp_configure 'allow updates', 1reconfigure with overrideGo



然后 update sysdatabases status = 32768 where name = ''



现在祈求满天神佛保佑吧重新建立个log文件成功机会还是相当大系统般都会认可你新建立日志如果没有报告什么现在就可以松口气了 虽然数据是恢复了可是别以为事情就算完成了正在进行事务肯定是丢失了原来数据也可能受到些损坏 先把SQL Server 重新启动下然后检查你数据库吧 先设置成单用户模式然后做 dbcc sp_dboption '', 'single user', 'true'DBCC CHECKDB('')



如果没有什么大问题就可以把数据库状态改回去了记得别忘了把系统表修改选项关掉 update sysdatabases status = 28 where name = ''



当然你数据库状态可能不是这个自己改为合适值吧也可以用 sp_restatusgosp_configure 'allow updates', 0reconfigure with overrideGo



Checkdb时候可能报告有些这些数据你可能就只好丢弃了 Checkdb有几种修复选项自己看着用吧不过最后你可能还是得REPAIR_ALLOW_DATA_LOSS完成所有修复 Chekcdb并不能完成所有修复我们需要更进步修复用DBCC CHECKTABLE对每个表做检查吧 表列表可以用sysobjects里面得到把OBJECTPROPERTY是IsTable全部找出来检查下吧这样能够基本上解决问题了如果还报告试着把数据select o到另张表检查下 这些都做完了的后把所有索引、视图、存储过程、触发器等重新建立下DBCC DBREINDEX也许可以帮你些忙