数据库 文件 修复-dataguard备库修复

2008年7月7日星期一，数据库服务器的磁盘阵列卡坏了，硬件维修人员更换了磁盘阵列卡，但系统的数据库文件损坏了。 恢复数据库花了两天时间。 数据库使用SQLSERVER2000，数据库名称为regie_sc_sj，数据库文件名为regie_sc_sj_data.mdf。

问题检查过程

1、企业管理器中垄断数据库状态可疑，通过以下命令修复数据库状态：

使用大师

去

sp_configure '允许更新', 1

去

重新配置覆盖

去

sp_resetstatus 'regie_sc_sj'

但是修复不成功，找不到数据库。 检查发现数据库文件没有丢失，只是数据库文件没有连接到SQLSERVER。

2、通过SQLSERVER的企业管理器将数据库文件附加到SQLSERVER失败，报“823”错误，是磁盘故障引起的。

3、将数据库文件复制到另一台机器上，在新机器上附加到企业管理器，同样报错。 表示磁盘故障损坏了数据库文件。 数据库上次备份是2004年的，用这个备份文件时间太久了。 现在只能尽量恢复已有的数据库文件。

修复过程

1、在master库的sysdatabases表中添加垄断数据库信息：

使用大师

--修改系统属性，允许修改系统表的内容

sp_configure '允许更新', 1

重新配置覆盖

--在sysdatabases表中添加垄断数据库信息数据库 文件 修复，其中status=32768表示紧急模式

插入 sysdatabases（名称、dbid、sid、模式、状态、status2、crdate、保留、类别、cmptlevel、文件名）

values('regie_sc_sj',10,0x01,0,32768,'1090519040',getdate(),getdate(),0,80,'D:/108809 database backup/regie_sc_sj_data.mdf') from sysdatabases

2.检查并修复数据库文件：

--设置regie_sc_sj数据库一次只能被一个用户访问

sp_dboption 'regie_sc_sj', '单用户', 'true'

-- 检查并修复数据库

DBCC CHECKDB('regie_sc_sj')

修复后记录错误的表

3.恢复数据库原有属性

sp_dboption 'regie_sc_sj', '单用户', '假'

sp_configure '允许更新', 0

重新配置覆盖

4、现在可以查询数据库中的数据，但是没有日志文件。 创建一个新的日志文件并重新启动数据库服务。

5、重启数据库服务后，如果数据库正常，那么就大功告成了，但是如果数据库变得可疑，或者无法创建日志文件数据库 文件 修复，那么还得继续下面的操作。

6. 按照步骤1~3，将数据库恢复到可查询状态。 不重启数据库服务，将用户创建的表、视图、存储过程、函数等信息导入脚本。

7.新建一个数据库，在新数据库（regie_sc_sj_jy）中执行之前导出的脚本。 注意表脚本必须包含索引、用户、主键等信息。 在执行表脚本之前，必须先更改表脚本中原有的数据库名称。 (regie_sc_sj) 应该是新的数据库名称 (regie_sc_sj_jy)。

8、将数据库中各表的数据导入到新数据库中。 数据导入过程中，将之前查库时出现问题的表单独导入。 这些表损坏无法修复，会丢失部分数据。

9、整理完数据后，重启数据库服务，将regie_sc_sj和regie_sc_sj_jy从数据库管理器中分离出来，将regie_sc_sj_jy的数据库文件重新附加到管理器中，将数据库名称改为regie_sc_sj。

这样数据库regie_sc_sj就修复好了，但是还是有部分数据丢失了。

俗话说，“好斗者无大事”。 数据库的维护应以预防为主，但如果数据库文件损坏，再好的解决办法，最好有一个最近的备份，以便进行简单的恢复操作。 因此，要真正保证数据库的安全，有必要对数据库进行定期备份。