数据库索引故障与解决方案

一、       数据库索引故障背景

一般情况下，引起分配错误的原因是磁盘损坏或突然停电；一致性错误可能是数据库中的表或索引坏。

具体表现为在没有正常关闭sqlserver的情况下，将服务器关闭了，重启后某些表损坏（应该是某些页损坏了，没有损坏的页还能访问到数据，但是访问损坏了的页就有问题）。

二、    报错可能的原因

RestorePending一般是在进行页恢复的过程中出现的，就是在进行了restore操作之后但还没有进行recovery操作之前页的状态。出现这样的问题可以肯定这个表是损坏了，但是在查询数据的时候如果不会查询到损坏页面的数据话是不会报错的，也就是说可以有条件的使用这个表。

三、       数据库索引损坏的错误现象

数据库 ID 15，页 (1:21826) 已标记为 RestorePending，可能表明磁盘已损坏。要从此状态恢复，请执行还原操作。

使用dbcc checkdb进行数据库修复结果如下(部分)

Gm_Buz_Archives的 DBCC 结果。

消息 8928，级别 16，状态 1，第 1 行

对象 ID 514100872，索引 ID 1，分区 ID 72057594047365120，分配单元 ID 72057594050510848 (类型为 In-row data): 无法处理页 (1:1750)。有关详细信息，请参阅其他错误消息。

DBCC 语句的修复级别导致避开了此修复。

消息 8939，级别 16，状态 98，第 1 行

表错误: 对象 ID 514100872，索引 ID 1，分区 ID 72057594047365120，

四、       数据库的一般性恢复

1）第一种，可以通过重新生成索引进行修复，【右键索引】→【编写索引脚本为】→【DROP 和 CREATE 到】→【新建编辑器窗口】，执行SQL ；

2）第二种，通过 DBCC CHECKTABLE（’text'）查看表的问题，如果出现一致性错误时，通过命令修复表

首先把数据库设置为单用户模式，直接在查询分析器中执行以下语句即可

执行 EXEC sp_dboption 'text, 'single user', 'TRUE'  

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

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

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

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

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

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

EXEC sp_dboption 'pos', 'single user','FALSE'

需要注意的是修复过程中不要使用DBCC CHECKDB ('数据名'', REPAIR_ALLOW_DATA_LOSS)，REPAIR_ALLOW_DATA_LOSS该语句是可能丢失数据的。

五、       数据库索引故障的预防与解决方案

1.     解决突然断电的问题,需购买UPS电源，即不间断电源，保障服务器正常关机。

2.     服务器进行维护时，通知各部门小组，停止对数据库进行数据交互。

3.     提前做好备份，每天可备份一次以上，对备份的数据进行还原测试。

4.     启用备份数据服务器进行业务的临时办理，故障解决后将数据同步到主服务器。

 

数据服务器出现紧急情况后的建议

1.     第一时间联系软件技术工程师。

2.     停止对数据库进行任何数据访问。

3.     即刻备份数据库。

4.     启用临时数据服务器。