诗檀软件专业数据库修复团队
适用于：
Oracle Database - Enterprise Edition – 版本8.1.7.4 到12.1.0.2 [Release 8.1.7 到12.1]
本文信息适用于任何平台。
***于16-July-2015检查相关性***
目标
如果恢复所需的归档日志找不到，丢失或损坏，如何恢复并打开数据库？
解决方案
这里的假设是我们寻找的另一个好且有效的所需归档日志的副本或备份的一切可能位置都不行，可能在以下之一：
- LOG_ARCHIVE_DEST_n中定义的目录
- 在同一服务器或另一服务器中的另一目录
- 备用数据库
- RMAN备份
- OS备份
如果在上述任何位置没有发现归档日志，则如何恢复并打开数据库的方法和策略取决于数据文件的SCN（系统变更号），以及恢复所需的日志序列＃是否仍在联机重做日志中可用。
对于数据文件的SCN，重要的是要知道在数据文件备份时数据库的模式。即备份时数据库是否打开，mounted或关机（正常）。
如果数据文件是从联机或者热备份中还原，这意味着在备份时数据库是打开的，那么我们就必须至少应用从所述备份被用于恢复数据文件开始到完成期间生成的日志序列＃所属的归档日志或重做日志。
但是，如果数据文件从脱机或冷备份中还原，且数据库在备份之前被干净关闭，这意味着在备份时该数据库是未打开，处于nomount或mounted模式，则数据文件与其SCN已经同步。在这种情况下，我们可以立即打开数据库，甚至无需应用归档日志，因为数据文件已经处于一致的状态，除非需要将数据库前滚到一个备份后的时间点。
这里的关键是要确保所有的联机数据文件与其SCN同步，然后才可以正常打开数据库。因此，运行下面的SQL语句，确定数据文件是否同步。注意到我们查询了V $ DATAFILE_HEADER，因为我们想知道记录在物理数据文件头中的SCN，而不是V$DATAFILE，它从控制文件中得到信息。
select status, checkpoint_change#,
to_char(checkpoint_time, 'DD-MON-YYYY HH24:MI:SS') as checkpoint_time,
count(*)
from v$datafile_header
group by status, checkpoint_change#, checkpoint_time
order by status, checkpoint_change#, checkpoint_time;
上述查询的结果对于联机数据文件必须返回一行且只有一个行，这意味着它们与其SCN已经同步。否则，如果为联机数据文件返回多行，则数据文件仍尚未同步。在这种情况下，我们需要应用归档日志或重做日志来同步所有联机数据文件。顺便说一句，请记录V$DATAFILE_HEADER中的CHECKPOINT_TIME，这表明数据文件已经被恢复到多久的日期和时间。
同样重要的是检查数据文件的状态。有时虽然所有文件的SCN相同，你仍然无法打开数据库。检查状态可通过
select fhsta, count(*) from X$KCVFH group by fhsta;
预期的系统数据文件结果是0和8192。如果状态是1 或64，它将会在备份模式并需要更多恢复， 显示其他状态需要询问Oracle support。
以上查询的结果可能返回一些脱机数据文件。所以，确保所有所需的数据文件联机，因为一旦在resetlogs下打开数据库，我们之后可能无法恢复脱机数据文件。即使从10g起版本的Oracle数据库，由于LOG_ARCHIVE_FORMAT中格式"%R"的引入，我们可以在resetlogs下恢复数据库，还是建议在restlogs打开数据库之前联机所需的数据文件以避免可能出现的问题。但在某些情况下，我们有意脱机数据文件，因为我们在进行部分数据库还原，或可能我们不需要所述数据文件的内容。
你可以运行以下查询来确认脱机的数据文件：
select file#, name from v$datafile
where file# in (select file# from v$datafile_header
where status='OFFLINE');
你可以发出以下SQL语句将所需的数据文件状态从"OFFLINE" 更改为"ONLINE"：
alter database datafile <file#> online;
如果运气好，所需的日志序列＃仍在联机重做日志且相应的重做日志成员仍在磁盘上物理存在，那么我们可以应用它们，而不用归档日志。为了确认，发出以下查询，这由于确认可用于恢复数据库的重做日志成员：
set echo on feedback on pagesize 100 numwidth 16
alter session set nls_date_format = 'DD-MON-YYYY HH24:MI:SS';
select LF.member, L.group#, L.thread#, L.sequence#, L.status,
L.first_change#, L.first_time, DF.min_checkpoint_change#
from v$log L, v$logfile LF,
(select min(checkpoint_change#) min_checkpoint_change#
from v$datafile_header
where status='ONLINE') DF
where LF.group# = L.group#
and L.first_change# >= DF.min_checkpoint_change#;
如果因为V $ DATABASE.CONTROLFILE_TYPE有“BACKUP”的值，上面的查询没有返回行，则尝试在恢复过程中每次应用一个重做日志成员。你可以运行下面的查询来确定重做日志成员：
select * from v$logfile;
如果你已经尝试在恢复过程中应用所有的联机重做日志成员，而非归档日志，但是你始终收到ORA-00310错误，如下面的例子所示，则恢复所需的日志序列＃不再在联机重做日志中可用。
ORA-00279: change 189189555 generated at 11/03/2007 09:27:46 needed for thread 1
ORA-00289: suggestion : +BACKUP
ORA-00280: change 189189555 for thread 1 is in sequence #428
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
+BACKUP/prmy/onlinelog/group_2.258.603422107
ORA-00310: archived log contains sequence 503; sequence 428 required
ORA-00334: archived log: '+BACKUP/prmy/onlinelog/group_2.258.603422107'
尝试上述所有可能的解决方案，但由于恢复所需的归档日志已找不到，丢失或损坏，或相应的日志序列＃在联机重做日志中不再可用，因为它们在重做日志切换的过程中已经被覆盖，你仍无法打开数据库，那么我们就无法正常打开数据库，因为数据文件处于不一致的状态。因此，下面提供3个方案来打开数据库：
方案#1: 通过在init.ora设置一些隐含参数强制打开数据库。注意，你只能通过服务请求在Oracle Support的指导下进行。但没有100％保证打开数据库。但是，一旦数据库被打开，那么我们必须立即重建数据库。要数据库重建执行以下操作，即：（1）执行完整数据库导出，（2）创建一个全新的，独立的数据库，最后（3）导入最近的导出转储export dump。当数据库被打开，数据将与被使用的数据文件在同一时间点。在尝试此选项前，确保你有当前数据库的良好和有效的备份。
方案#2: 如果你有一个完好和有效的数据库备份，则从上述备份中还原数据库，并运用到最后一个可用的归档日志恢复数据库。在此选项中，我们将只恢复数据库到被应用的最后的归档日志，以及丢失后的任何数据。如果完全没有归档日志被应用，那么我们只能从还原的备份中恢复数据库。但是，如果我们从联机或热备份中还原，那么我们可能无法打开数据库，因为我们仍然需要应用所述备份中生成的归档日志，以便我们在能正常打开数据库之前同步数据文件的SCN。
方案#3: 使用的PRM-DUL Data Unloader (DUL)手动抽取数据，由诗檀软件提供恢复服务，并需额外收费。如果客户想要采取这个方法，我们需要代表客户，有权签署工作的人的全名，手机号，邮箱。http://www.parnassusdata.com/zh-hans