sql2000使用DBCC checkdb(数据库) 检查出来的错误怎么解决？
我们的软件是基于SQL2000之上的，有天客户使用软件发生错误，然后通过DBCC checkdb检查出来很多错误，请求高手解决，不胜感激，错误如下：
 服务器: 消息 8903，级别 16，状态 1，行 1
 扩展盘区 (1:315272)（属于数据库 ID 8）在 GAM (1:2) 和 SGAM (1:3) 中均进行了分配。
 服务器: 消息 8906，级别 16，状态 1，行 1
 扩展盘区 (1:315272)（属于数据库 ID 8）在 SGAM (1:3) 和 PFS (1:307344) 中进行了分配，但未在任何 IAM 中进行过分配。PFS 标志 'MIXED_EXT ALLOCATED 0_PCT_FULL'。
 服务器: 消息 8903，级别 16，状态 1，行 1
 扩展盘区 (1:315296)（属于数据库 ID 8）在 GAM (1:2) 和 SGAM (1:3) 中均进行了分配。
 服务器: 消息 8906，级别 16，状态 1，行 1
 扩展盘区 (1:315296)（属于数据库 ID 8）在 SGAM (1:3) 和 PFS (1:307344) 中进行了分配，但未在任何 IAM 中进行过分配。PFS 标志 'MIXED_EXT ALLOCATED 0_PCT_FULL'。
 服务器: 消息 8906，级别 16，状态 1，行 1
 扩展盘区 (1:315298)（属于数据库 ID 8）在 SGAM (1:3) 和 PFS (1:307344) 中进行了分配，但未在任何 IAM 中进行过分配。PFS 标志 'MIXED_EXT ALLOCATED 0_PCT_FULL'。
 服务器: 消息 8905，级别 16，状态 1，行 1
 扩展盘区 (1:511936)（属于数据库 ID 8）在 GAM 中标记为已分配，但没有 SGAM 或 IAM 分配过该盘区。
 服务器: 消息 8905，级别 16，状态 1，行 1
 扩展盘区 (1:511944)（属于数据库 ID 8）在 GAM 中标记为已分配，但没有 SGAM 或 IAM 分配过该盘区。
 服务器: 消息 8905，级别 16，状态 1，行 1
 扩展盘区 (1:511952)（属于数据库 ID 8）在 GAM 中标记为已分配，但没有 SGAM 或 
96604，索引 ID 0）的下一页指针指向了 IAM 页 (1:315515)，但在扫描过程中未检测到该页。
 服务器: 消息 2575，级别 16，状态 1，行 1
 IAM 页 (1:2511)（对象 ID 452196661，索引 ID 0）的下一页指针指向了 IAM 页 (1:315518)，但在扫描过程中未检测到该页。
 服务器: 消息 2575，级别 16，状态 1，行 1
 IAM 页 (1:2509)（对象 ID 452196661，索引 ID 255）的下一页指针指向了 IAM 页 (1:315517)，但在扫描过程中未检测到该页。
 对象 'htl_field' 有 1549 行，这些行位于 17 页中。
 这些行位于 3339 页中。
 CHECKDB 发现了 1 个分配错误和 0 个一致性错误（在表 'htllog' 中，该表的对象 ID 为 436196604）。
 'tablename' 的 DBCC 结果。
 对象 'tablename' 有 16 行，这些行位于 1 页中。
 'Htlmemo' 的 DBCC 结果。
 对象 'Htlmemo' 有 4492 行，这些行位于 792 页中。
 CHECKDB 发现了 2 个分配错误和 0 个一致性错误（在表 'Htlmemo' 中，该表的对象 ID 为 452196661）。
 'tacomm' 的 DBCC 结果。
 CHECKDB 发现了 382 个分配错误和 159 个一致性错误（在数据库 'hdbg' 中）。
 repair_allow_data_loss 是最低的修复级别（对于由 DBCC CHECKDB (hdbg ) 发现的错误而言）。
 DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

------解决方案--------------------
首先，先做一次备份
然后，执行DBCC CHECKDB (数据库名,repair_allow_data_loss) （注意使用单用户模式）这个语句有可能导致部分数据丢失。
或者执行DBCC CHECKDB (数据库名,repair_rebuild)执行。
其实如果有镜像，最好还是用镜像恢复。
------解决方案--------------------
貌似文件损坏,没什么好方法.

做最坏的打算-->找最近的备份出来恢复.

另: 服务器的磁盘最好也换一个.
------解决方案--------------------

SQL code

--1、把数据库设置为单用户模式，直接在查询分析器中执行以下语句即可：(如发现语句运行不成功，请把用户的电脑注销一下，后再重新运行一下。) 

EXEC sp_dboption 'test', 'single user', 'TRUE'  

 

--2、进入查询分析器执行如下语句： 

use test 

dbcc checkdb（'test',repair_allow_data_loss）  -------修复数据库 

dbcc checkdb ('test',REPAIR_REBUILD)           -------修复数据库索引 

 

--3、再执行：dbcc checkdb，检测数据库，出现结果为： 

--CHECKDB  发现了0个分配错误和 0个一致性错误（在数据库 'test' 中）。 

--数据库已经修复完毕。

 

--4、取消单用户模式，即直接在查询分析器中执行以下语句即可： 

EXEC sp_dboption 'test', 'single user','FALSE'

------解决方案--------------------
---Reading notes  
Steps to fix data corruption  
1. Fix the underlying cause first
Check the server's Windows event viewer, SAN controller's error logs. If other SQL Servers store data on the same SAN controller, run DBCC CHECKDB against their databases as well.
2. Focus on the worst problem first
Use the following script to output error list, then focus on the worst error.
sqlcmd -E -Q”DBCC CHECKDB (master) WITH ALL_ERRORMSGS, NO_INFOMSGS”  
-oC:\errorlist.txt

3. Deal with damaged system tables
Restore or script out all objects, then create a new database and recreate the data.

4. Deal with corrupt clustered indexes
Restore the database under another name and replace the table in the live database with the one from the restored co