丢失归档日志文件的数据库恢复方法，从一个不能正常打开的数据库（由于一个/多个数据库文件与其他文件不一致）中提取数据。场景：一个磁盘损坏了并且丢失了一个数据库文件。从一周前的热备转储数据文件，不幸的是丢失了几个归档日志文件。但是有问题的数据文件包含了最重要的表，如何能够挽救数据呢?
从一个不能正常打开的数据库(由于一个/多个数据库文件与其他文件不一致)中提取数据。场景：一个磁盘损坏了并且丢失了一个数据库文件。从一周前的热备转储数据文件，不幸的是丢失了几个归档日志文件。但是有问题的数据文件包含了最重要的表，如何能够挽救数据呢?
每个DBA都知道这是有问题的，一定会丢失数据，因为某些事务丢失了，问题是会丢失多少数据?Oracle使用硬线路位置并且由于存在完整性约束问题，因此不允许正常打开数据。但是如果使用非常规的方法让Oracle删除其硬线路属性，那么应该能够提取尽可能多的数据。而通常这会比损失全部数据要好很多。
详细过程通常如果仅仅丢失了堆表的索引，或者某些能够很容易重建的数据，那么最好的方法应该是删除表空间并重建这些对象然后重新输入。但是如果丢失的数据文件包含了重要数据并且很难恢复，而且只有前一次的备份却又丢失了某些归档日志，那么用户可能希望能够尽可能多的从有问题的表空间恢复数据并且删除和重建表空间。
主要的步骤如下：
1. 对当前拥有的数据进行一个冷备;
2. 转储丢失的数据库文件备份并应用可以应用的日志;
3. 设置未文档化的初始化参数，其允许你在当前状态打开数据库;
4. 执行exp并提取全部可以从有问题的表空间提取的数据;
5. 从先前的冷备转储数据库;
6. 使毁坏的数据文件offline;
7. 执行exp并提取第4步没有提取的额外数据;
8. 在一次从冷备转储;
9. 删除有问题的表空间;
10. 重建有问题的表空间;
11. 使用第四步和第七步提取的数据重建数据;
使用案例描述：ORDTAB表空间的一个数据文件ordtab03.dbf毁坏，其包含很多ORDERS表的分区，数据文件热备于July 4， 2004，July 4—至今的某些归档日志丢失。
第一步：备份数据库第一步的任务是冷备当前拥有的任何数据文件，在线重做日志，和控制文件。如果丢失了一个/多个数据文件但是数据库仍然是open的，那么对每个剩余的数据文件进行热备并确保备份期间/之后的归档被安全保存。
创建备份后，在关闭数据库之前，备份一下控制文件：ALTER DATABASE BACKUP CONTROLFILE TO TRACE RESETLOGS;然后打开备份的控制文件，删除第一个#之上的所有行，并删除“RECOVER DATABASE…”到文件结尾的全部。
第二步：转储丢失的数据库文件备份并应用日志;这一步应该转储备份，并应用日志到直到无法在前向滚动，此时如果尝试正常打开数据库，将会得到ORA-01589： must use RESETLOGS or NORESETLOGS option for database open错误。
如果尝试执行ALTER DATABASE OPEN RESETLOGS，将会得到ORA-01195错误：ORA-01195： online backup of file %s needs more recovery to be consistent.这里是Oracle使用其硬线路的位置。由于转储的数据文件不能恢复到与其他文件一致的位置，所以可能存在中断的数据并且Oracle不允许正常打开数据库。
第三步：设置未文档化的实例参数并打开数据库在初始化参数文件中首先需要将job_queue_processes设置为0，然后设置_allow_resetlogs_corruption=TRUE，更改该参数后，切换到保存新控制文件的目录，第一步创建的位置。然后以SYSDBA连接并运行新的控制文件创建脚本。
此时数据库可以打开了。
SQL> SELECT COUNT(*) FROM OE.orders;
第四步：执行导出并提取数据在这一步可以很容易的看到那些表导出了全部的数据。
第五步：转储备份的数据库这一步，以及下面两步可选。这三步结合在一起允许提取更多的数据，这一步从备份的数据库转储可以高效的撤销任何由于使用_allow_resetlogs_corruption参数造成的毁坏。因此，这一步不会恢复任何丢失的数据文件。
第六步：使毁坏的数据文件offline ALTER DATABASE DATAFILE ’/u07/oradata/PRD/ordtab03.dbf’ OFFLINE;这一步得到数据库的完全一致性状态。
第七步：执行导出并提取额外的数据这一步可能能够提取从第四步不能提取的额外数据，如索引中的数据。
第八步 ：转储数据库这是最后一次转储数据库，这一步正式回滚数据库到使用隐含参数前那一刻，然后将数据库返回到正常状态，如果从第五步转储以来没有更新任何数据，可以跳过这一步。
第九步：删除有问题的表空间首先需要查看是否有完整性约束限制，使用以下查询：
SELECT CR.constraint_name
FROM dba_constraints CR, dba_constraints CP, dba_tables TP, dba_tables TR
WHERE CR.r_owner = CP.owner
AND CR.r_constraint_name = CP.constraint_name
AND CR.constraint_type = ’R’
AND CP.constraint_type IN (’P’, ’U’)
AND CP.table_name = TP.table_name
AND CP.owner = TP.owner
AND CR.table_name = TR.table_name
AND CR.owner = TR.owner
AND TR.tablespace_name ’ORDTAB’
AND TP.tablespace_name = ’ORDTAB’;
如果有约束，可能需要创建重建脚本。如果使用export dump重建数据，约束可以从导出文件转储。
DROP TABLESPACE ordtab INCLUDING CONTENTS CASCADE CONSTRAINTS;
第十步：重建表空间
第十一步：重建数据执行导入