在数据库五 中找不到分区 ID xxxx的目录条目, 元数据不一致

在数据库5 中找不到分区 ID xxxx的目录条目, 元数据不一致。
windows2003+sqlserver2008r2sp1
由于磁盘突然损坏，系统修复后，sqlserver的一个库db为可疑状态。
于是采用如下步骤修复：

参考：http://database.51cto.com/art/201108/285855.htm
 
1、修改数据库为紧急模式
ALTER DATABASE db SET EMERGENCY
2、使数据库变为单用户模式
ALTER DATABASE db SET SINGLE_USER
3、修复数据库日志重新生成，此命令检查的分配，结构，逻辑完整性和所有数据库中的对象错误。当您指定“REPAIR_ALLOW_DATA_LOSS”作为DBCC CHECKDB命令参数，该程序将检查和修复报告的错误。但是，这些修复可能会导致一些数据丢失。
DBCC CheckDB (db, REPAIR_ALLOW_DATA_LOSS)
4、使数据库变回为多用户模式
ALTER DATABASE db SET MULTI_USER

执行1,4步后，数据库可疑状态消失。但是查询所以分区表都报如下错误：
在数据库5 中找不到分区 ID 为 xxxxxxxxxxxxxxxxxxx 的目录条目。元数据不一致。请运行 DBCC CHECKDB 查看元数据是否已损坏。

所以分区表都不能dml和ddl操作，执行就报如上错误。
由于当前库没有备份，有没有办法解决？
------解决思路----------------------
考虑在分区表上重建聚集索引试试。
------解决思路----------------------
把数据重新导到一个新表可行不？
------解决思路----------------------
你说重建不行是只重建的操作是可以，但是还是差不了分区，还是说连重建的命令都执行不了？

------解决思路----------------------

USE AdventureWorks2012;
  GO
  ALTER INDEX PK_Employee_BusinessEntityID ON HumanResources.Employee
  REBUILD;
  GO

这样呢？
------解决思路----------------------
额。。。不过我觉得即使能执行，也不一定能修复你的问题，正式库怎么能没有备份呢？
------解决思路----------------------
2008用压缩备份通常能达到1：4的体积，这点空间都负担不起。。。
------解决思路----------------------
不过你要有个心理准备，不是所有的错误都能修复的，即使微软出马也不一定
------解决思路----------------------
DBCC CHECKDB (<Database Name>) WITH NO_INFOMSGS, ALL_ERRORMSGS 这个只是检查，不修复