<P></P><P>Applies to: Oracle Server Enterprise Edition - Version: 8.1.7.4 to 11.1.0.6 Information in this document applies to any platform. Oracle Server - Enterprise Edition - Version: 8.1.7.4 to 11.1 Goal How to recover and open the database if the archivelog required for recovery is either missing, lost or corrupted? Solution 假设我们在所有的可能的位置搜索是否存在好的，可用的归档日志的拷贝或者备份，以下是可以查找的几种途径： LOG_ARCHIVE_DEST_n定义的归档路径 同一个服务器或者其他服务器中的另外的目录 Standby数据库 RMAN backup OS backup 如果通过以上的几种途径都没有找到合适的归档日志，那么要想恢复数据库并打开数据库的方法只能依赖于数据文件的SCN 号了，并且，对于在线重新做日志中可用于数据库恢复的日志序列也要是可用的。 针对数据文件的SCN号，对于了解数据文件在备份的时候数据库是什么模式是非常重要的。即当执行备份的时候，数据库是否open, mounted or shutdown (normally)。 如果数据文件是通过热备（在线备份）中恢复过来的，那就表示当执行备份的时候，数据库处于打开状态。此时我们至少要应用那些日志序列号处于上述备份从开始到结束的过程中的归档日志或重做日志来进行数据文件的恢复。 然而，当数据文件是从离线备份（冷备）中恢复，那就表示数据库在备份的之前已经cleanly shutdown，也就是说在执行备份的时候数据库既不是处于open，也不是处于nomount或mount状态，，此时数据文件的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已经同步。否则，如果为online数据文件返回不止一行记录，那就表示数据文件还没有同步。在这种情况下，我们需要应用归档日志和在线重做日志来保证在线数据文件的同步。顺便要注意：V$DATAFILE_HEADER视图中的CHECKPOINT_TIME的值表示数据文件被恢复了多长时间。 上述的查询也可能会返回一些离线的文件，所以要确保所需要的数据文件必须是在线的，因为一旦我们以resetlogs打开数据库后就不可能恢复后来的离线文件了。尽管在ORACLE10g及后续的版本中我们可以基于OG_ARCHIVE_FORMAT中"%R"的引导恢复超出resetlogs的数据库，建议你在以resetlogs打开数据库后立即让所需要的数据文件在线以避免任何可能出现的问题。然而在一些情况下当我们在进行部分数据库还原或者我们并不需要某些文件的时候要是数据文件离线。可以执行接下来的查询来确定离线的数据文件 select file#, name from v$datafile where file# in (select file# from v$datafile_header where status='OFFLINE') 如果在联机重做日志中的日志序列号是可用的，并且相关联的重做日志成员物理保存在磁盘中，此时我们可以应用这些日志组成员来代替归档日志。为了确认这一点，执行以下的查询，查询结果将会确定在数据库恢复的时候可以应用的日志成员。 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: {=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个操作可以用来打开数据库的操作： Option#1:通过在初始化参数init.ora中设置一些隐藏参数来强制打开数据库。注意你只能在申请一个服务请求并在oracle技术支持的指导下进行此操作。但是，这也没有100%的把握保证能够打开数据库。然而一旦数据库被打开，我们必须马上rebuild数据库。数据库的rebuild要执行以下操作：（1）执行全库的导出操作；（2）创建一个全新的独立的数据库，最后（3）导入之前导出的文件。此操作相对繁琐和费时，但是一旦我们能成功的敬爱那个之前创建的新的数据库打开后，它将如我们期望或许不会造成数据丢失。当我们在执行此项操作之前你必须确保当前的数据库已经有了一个很好的且可用的备份。 Option#2:如果此数据库有一个良好的和有效的备份，就可以使用该备份进行恢复，并且可以通过应用上一个可以获得的归档日志进行recover 数据库。在本次操作中我们只能将数据库恢复到我们所能应用的归档日志的那个地方，在这之后的数据将会丢失。如果没有可用的归档日志被应用，那么我们只能通过备份恢复数据库。然而，如果我们是通过在线备份（热备）进行数据库的恢复，此时我们可能会因为在正常打开数据库的时候了需要通过应用之前备份中产生的归档日志来保证数据文件的SCN号的同步的 原因而不能打开数据库。 Option#3:我们可以通过使用Oracle's Data Unloader (DUL)工具手动提取数据。但是这需要由在下一个工作日由ORACLE 通过客户的网站进行现场支持，需要承担一些额外的费用。ORACLE 公司需要客户这边有一个有权限的人留下全名，手机号以及email地址，需要他代表客户签署work order Errors ORA-279; ORA-280; ORA-289; ORA-334; ORA-310</P><P></P>