【数据库故障描述】

今天介绍一下数据库的一个报错解决方法，这种报错通常出现在异常断电之后，报错内容为“system01.dbf需要更多的恢复来保持一致性”。那么这种情况下应该如何修复数据库，使数据库可以正常使用呢？今天小编就给大家简单梳理一下这种报错的修复方法。

【恢复流程】

1.检查数据库同时备份

2.尝试挂起并修复数据库

3.解析数据库文件并验证数据

4.导出数据库数据

【数据恢复案例】

某公司的一个数据库由于非正常断电导致报错，数据库无法打开，也无法使用了。

我们首先利用DBV命令检测数据库文件是否是完整的，

经过检查发现SYSAUX01.DBF文件数据块（Data）检测失败39页，索引页（Index)检测失败32页，其他位置的数据是正常的，由此可知SYSAUX01.DBF存在坏块。

随后我们创建新的os尝试挂起数据库，确认一下报错情况。

我们使用recover database 命令，利用在线日志做介质恢复。

SQL> recover database;

ORA-00283: ??????????

ORA-01618: ?? BACKUP CONTROLFILE ????????

数据库的控制文件已被修改，需要使用控制文件恢复数据库

由于归档日志丢失，使用cancel参数进行不完全恢复。

再次执行alter database open 命令，数据库打开。

对打开的数据库进行实例状态查询，报错“ora 00600”，查询其他位置，也发现部分相同内容的报错。

查看警告日志，追踪文件查看内部错误代码；

警告日志部分内容如下：

ORA-00600: internal error code, arguments: [13013], [5001], [267], [8456009], [5], [8456009], [17], [], [], [], [], []

Non-fatal internal error happenned while SMON was doing logging scn->time mapping.

尝试用expdp/exp工具导出数据库；但均导出失败。

由上可知，数据库的恢复已不可能。底层解析，解析数据文件，获取用户对象。我们自己编写了一个解析DBF的工具进行数据获取并且成功获取到数据库数据。

创建数据库，在数据库中创建用户，为用户分配表空间，解锁用户并授权。然后，通道数据的搭桥的方式，将解析到的用户对象迁移到数据库中。

最后使用toad for oracle工具验证数据。

使用exp或者expdp导出zxfg用户下的所有对象，本例采用exp导出数据，命令如下：

exp system/abc file=C:\test\dump\zxfg.dmp log=C:\test\dump\zxfg.log owner=zxfg

最终成功导出数据库文件，数据库恢复成功。