错误号msg 8928:是和8939相关联的信息，
错误号msg 8965:是和8939相关联的信息，
大家可以到下面的地址找到相关的信息：
http://support.microsoft.com/default.aspx?scid=kb;en-us;826433
prb: additional sql server diagnostics added to detect unreported i/o problems
http://support.microsoft.com/default.aspx?scid=kb;en-us;828339
prb: error message 823 may indicate hardware problems or system problems
http://support.microsoft.com/default.aspx?scid=kb;en-us;308795
fix: checkdb may not fix error 8909 or error 8905
故障确诊：raid有一块hdd坏，造成数据库文件破坏
2.更换hdd
2003－12－28 23:00
现在就体现了raid5的好处，坏了一块hdd，系统可以照常运行，不过系统的日志和sqlserver的日志还是有msg823的报错信息。
按照raid 卡的rebuild的步骤将新的hdd绑定到原始的raid5中，顺利完成:-)
用dbcc检查数据库的完整性
dbcc checkdb('pos_db') with all_errormsgs
发现还是有和更换hdd之前一样的error信息，看来数据库文件还是有问题。
--有一个奇怪问题1，既然是5块hdd的raid5，为何有一块hdd坏会影响数据库文件的损坏，不解？？？:-(
3.恢复数据库
2003－12－29 00:30
没有办法，用备份的数据集恢复数据库（看来备份是多么的重要）
use master
go
restore database pos_db from disk='d:\databasebackup\pos_db_backup.dat'
重新启动mssqlsercver服务，
net stop mssqlserver / net start mssqlserver
用dbcc检查数据库的完整性
dbcc checkdb('pos_db') with all_errormsgs
和恢复之前的错误信息一致，没有改变。
--奇怪问题之2，sqlserver backup 之前并不验证数据库的完整性，数据库的全备份竟然是有问题的。气愤！！
看来只能通过工具修复数据库了（--在修改之前记录错误表的记录数，以便修复数据库后进行比较）。
在查询分析器中运行：
alter database pos_db set singl_user
go
dbcc checkdb('pos_db',repair_allow_data_loss) with tablock
go
alter database pos_db set multi_user
go
checkdb 有3个参数:
repair_allow_data_loss
执行由 repair_rebuild 完成的所有修复，包括对行和页进行分配和取消分配以改正分配错误、结构行或页的错误，以及删除已损坏的文本对象。这些修复可能会导致一些数据丢失。修复操作可以在用户事务下完成以允许用户回滚所做的更改。如果回滚修复，则数据库仍会含有错误，应该从备份进行恢复。如果由于所提供修复等级的缘故遗漏某个错误的修复，则将遗漏任何取决于该修复的修复。修复完成后，备份数据库。
repair_fast 进行小的、不耗时的修复操作，如修复非聚集索引中的附加键。这些修复可以很快完成，并且不会有丢失数据的危险。
repair_rebuild 执行由 repair_fast 完成的所有修复，包括需要较长时间的修复（如重建索引）。执行这些修复时不会有丢失数据的危险。
第一次运行，我们会发现：
dbcc results for 'table_name'.
there are 1 rows in 1 pages for object 'table_name'.
the error has been repaired.
checkdb found 0 allocation errors and 1 consistency errors in table '(object id 26342838)' (object id 26342838).
checkdb fixed 0 allocation errors and 1 consistency errors in table '(object id 26342838)' (object id 26342838).
这样的信息有很多，并且有“the error has been repaired”的提示。不过到最后还是有这样的信息：
checkdb found 0 allocation errors and 19 consistency errors in database 'pos_db'.
checkdb fixed 0 allocation errors and 19 consistency errors in database 'pos_db'.
再次运行，还是有同样的错误。糟糕:=)看来这种方式是无法修复这样测错误。
失败！！！
再仔细看看sqlserver bol发现checkdb还有一个非常有用的参数physical_only
physical_only
仅限于检查页和记录标题物理结构的完整性，以及页对象 id 和索引 id 与分配结构之间的一致性。该检查旨在以较低的开销检查数据库的物理一致性，同时还检测会危及用户数据安全的残缺页和常见的硬件故障。physical_only 始终意味着 no_infomsgs，并且不能与任何修复选项一起使用。
再次运行：
dbcc checkdb('pos_db') with no_infomsgs,physical_only
然后再运行：
dbcc checkdb('pos_db',repair_allow_data_loss) with tablock
这次会返回一些8952.8956的错误信息:
server: msg 8952, level 16, state 1, line 1
table error: database 'pos_db', index 'pos_refer.idx2_pos_refer' (id 861246123) (index id 2). extra or invalid key for the keys:
server: msg 8956, level 16, state 1, line 1
index row (1:26315:23) with values (plu_id = '6922825200240' and prd_aggr_id = 10006 and evnt_id = null and rgst_mde = 0 and subprd_nbr = 0 and str_id = 12 and prd_aggr_id = 10006 and subprd_nbr = 0 and str_id = 12 and plu_id = '6922825200240' and evnt_id = null and rgst_mde = 0) points to the data row identified by ().
根据msdn上的说明：
