【数据库故障描述】
今天介绍一下数据库的一个报错解决方法，这种报错通常出现在异常断电之后，报错内容为“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
最终成功导出数据库文件，数据库恢复成功。
