SQL RAID5损坏恢复后sql数据库无法附加提示823错误 修复数据库之后，有一个关键表无法打开，怎么修复这个表

Question

今天早上来，发现放数据库那个盘不见了，SQL也挂了，因是做得RAID５，修复后盘能打开了，数据库文件还在可是启动之后就显示为质疑状态，我通过操作终于把数据修复了（具体操作方法见这里http://www.db-recovery.com/raid5-sun-huai-hui-fu-hou-sql-shu-ju-ku-wu-fa-fu-jia-ti-shi-823-cuo-wu-cheng-gong-xiu-fu.html#more-67），
打开一看除了一个关键存放数据得表（此数据特别多有几千万）不能开启，
别的所有表都能开启，大家知道能用什么方法，把这个表得数据恢复，目前直接打不开

Answer 1

－－－－目前正在做得修复表的操作如下，大家看看还有没有其它方法USE MASTER
GO
sp_dboption '问题数据库', 'single user', 'true' 
Go
DBCC CHECKDB('问题数据库', REPAIR_ALLOW_DATA_LOSS) 
Go
USE '问题数据库'go
exec sp_msforeachtable 'DBCC CHECKTABLE("问题表",REPAIR_ALLOW_DATA_LOSS)' 
exec sp_msforeachtable 'DBCC DBREINDEX("问题表")' 
go
sp_dboption '问题数据库', 'single user', 'false' 
Go 

Answer 2

现在　他不是硬盘损坏　，是丢失一个逻辑盘 E盘（这个盘就是存放SQL数据库的）
后来把RAID5修复了下，E盘又回来了，而且数据都在
再启动SQL服务器之后，就显示那个数据为质疑状态我就通过一楼那个网上说的方法恢复之后，现在就剩下一个最关键的表无法打开
别的表都能开启而且数据都在现在的问题是怎么修复这个表（这个表的数据比较大，大概有几千万笔吧），别的表都以及OK了

Answer 3

可是我检查那个数据库的文件(mdf)容量还是那么大，应该数据都在啊

Answer 4

有没有错误，可以用DBCC CHECKDB就能检测出来.
物理损坏的话，很难修复.

Answer 5

select  * into newtbale from 那个表            呢？

Answer 6

select  * into newtbale from 那个表            呢？
----这个肯定是不行了，因为根本就无法执行SELECT

Answer 7

质疑的数据库的恢复：提供一下资料吧1.新建一个同名的数据库  
   
  2.再停掉sql   server  
   
  3.用suspect数据库的文件覆盖掉这个新建的同名数据库  
   
  4.再重启sql   server  
   
  5.此时打开企业管理器时新建的同名数据库会出现置疑，先不管，执行下面的语句（注意修改其中的数据库名)  
   
   
  USE   MASTER  
  GO  
   
  SP_CONFIGURE   'ALLOW   UPDATES',1   RECONFIGURE   WITH   OVERRIDE  
  GO  
   
  UPDATE   SYSDATABASES   SET   STATUS   =32768   WHERE   NAME='his222'  
  Go  
   
  sp_dboption   'test',   'single   user',   'true'  
  Go  
   
  DBCC   CHECKDB('test')    
  Go  
   
  update   sysdatabases   set   status   =28   where   name='test'  
  Go  
   
  sp_configure   'allow   updates',   0   reconfigure   with   override  
  Go    
   
  sp_dboption   'test',   'single   user',   'false'  
  Go  
   
  6.完成后一般就可以访问数据库中的数据了,这时,数据库本身一般还要问题,解决办法是,利用  
  数据库的脚本创建一个新的数据库,并将数据导进去就行了.  
   
  如果这样改不加数据库状态,你就把数据库导成一个新库来代替旧库吧  
   
  企业管理器--右键你的数据库--所有任务--导出数据  
                      --目标标数据库选择新建  
                      --选择"在两个sql数据库之间复制对象和数据"  
                      --把"包含扩展属性"选上,其他的根据需要选择  
                      --最后完成  
  

Answer 8

那样的话，最坏的可能就是做RAID5恢复的时候那个表对应的部分数据出现了物理损坏。

Answer 9

做checktable repair_allow_data_loss檢查時 
修復了11個多小時，最後的提示是(我的是繁体系统)：checktable在资料表＂SFC＂上发现了0个配置错误和2020680个一致性错误

Answer 10

依据我们恢复数据库的经验，一致性错误的问题基本依靠sql server普通命令无法解决了

Answer 11

事务没有执行完毕。你的ldf呢？如果没重建，试着用logexplorer呢？

Answer 12

我的LDF已经重建了，不过我还有最原始的有问题的MDF和LDF备份，我也下载了LOGexplorer　还没用

Answer 13

典型的数据库正在运行时，RAID挂掉，对当前库进行了脏页写入，然后造成IAM表链断裂。2005以上的库方法比较简单，2000做起来比较麻烦。

Answer 14

建议还是不要省这个钱  找数据修复公司处理，  一、浪费时间     二、知道修复的人也不可能会告诉你。还有，你上述所指  “硬盘e分区丢失，后来把RAID5修复了下，E盘又回来了”   你所做修复操作是什么？ 是重新同步raid了还是其他什么操作？   有些操作都可能是导致数据损坏所在。  光问怎么恢复，又不说是sql在报什么错，让别人想帮你都帮不了。

Answer 15

做checktable repair_allow_data_loss檢查時 
修復了11個多小時，最後的提示是(我的是繁体系统)： checktable在资料表＂SFC＂上发现了0个配置错误和2020680个一致性错误