这篇文章仍然是RMAN-600错误的后续系列。
RMAN-600(8201)错误：https://yangtingkun.net/?p=690
RMAN-600(8201)错误的重现：https://yangtingkun.net/?p=716
恢复数据库出现ORA-38727：https://yangtingkun.net/?p=759
当控制文件里存在更大RESETLOGS的ORPHAN时，Oracle在10.2.0.3及以前版本是存在bug的，开始仅仅认为这个问题影响CATALOG模式的备份。但是测试发现，对于数据库的恢复同样存在影响。
如果数据库的FLASHBACK出于打开状态，那么恢复操作就会报错ORA-38727错误，而如果FLASHBACK处于关闭状态，恢复操作就可能碰到ORA-600(kccfhb_1)错误。
[orat1@hpserver2 ~]$ sqlplus / AS sysdba SQL*Plus: Release 10.2.0.3.0 - Production ON Mon Apr 16 10:58:58 2012 Copyright (c) 1982, 2006, Oracle. ALL Rights Reserved. Connected TO: Oracle DATABASE 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production WITH the Partitioning, OLAP AND DATA Mining options SQL> SET pages 100 LINES 140 SQL> ALTER DATABASE recover tablespace tbs011; ALTER DATABASE recover tablespace tbs011 * ERROR at line 1: ORA-00283: recovery SESSION canceled due TO errors ORA-00600: internal error code, arguments: [kccfhb_1], [4], [], [], [], [], [], [] SQL> shutdown immediate DATABASE closed. DATABASE dismounted. ORACLE instance shut down. SQL> startup mount ORACLE instance started. Total System Global Area 314572800 bytes Fixed SIZE 2072384 bytes Variable SIZE 150995136 bytes DATABASE Buffers 155189248 bytes Redo Buffers 6316032 bytes DATABASE mounted. SQL> recover tablespace tbs010; ORA-00283: recovery SESSION canceled due TO errors ORA-01110: DATA file 7: '/t1/orat1/oradata/test10g_s/tbs010.dbf' ORA-01157: cannot identify/LOCK DATA file 7 - see DBWR trace file ORA-01110: DATA file 7: '/t1/orat1/oradata/test10g_s/tbs010.dbf' SQL> host [orat1@hpserver2 ~]$ rman target / Recovery Manager: Release 10.2.0.3.0 - Production ON Mon Apr 16 11:14:16 2012 Copyright (c) 1982, 2005, Oracle. ALL rights reserved. connected TO target DATABASE: TEST10G (DBID=1030910857, NOT OPEN) RMAN> restore tablespace tbs010; Starting restore at 16-APR-12 USING target DATABASE control file instead OF recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=155 devtype=DISK skipping datafile 7; already restored TO file /t1/orat1/oradata/test10g_s/tbs010.dbf restore NOT done; ALL files readonly, offline, OR already restored Finished restore at 16-APR-12 RMAN> recover tablespace tbs010; Starting recover at 16-APR-12 USING channel ORA_DISK_1 RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure OF recover command at 04/16/2012 11:14:38 RMAN-06067: RECOVER DATABASE required WITH a backup OR created control file RMAN> restore tablespace tbs010 force; Starting restore at 16-APR-12 USING channel ORA_DISK_1 channel ORA_DISK_1: starting datafile backupset restore channel ORA_DISK_1: specifying datafile(s) TO restore FROM backup SET restoring datafile 00007 TO /t1/orat1/oradata/test10g_s/tbs010.dbf channel ORA_DISK_1: reading FROM backup piece /t1/orat1/flash_recovery_area/BOSTON/backupset/2012_04_16/o1_mf_nnndf_TAG20120416T101406_7rq03jy8_.bkp channel ORA_DISK_1: restored backup piece 1 piece handle=/t1/orat1/flash_recovery_area/BOSTON/backupset/2012_04_16/o1_mf_nnndf_TAG20120416T101406_7rq03jy8_.bkp tag=TAG20120416T101406 channel ORA_DISK_1: restore complete, elapsed TIME: 00:00:02 Finished restore at 16-APR-12 RMAN> recover tablespace tbs010; Starting recover at 16-APR-12 USING channel ORA_DISK_1 RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure OF recover command at 04/16/2012 11:16:25 RMAN-06067: RECOVER DATABASE required WITH a backup OR created control file RMAN> recover DATABASE; Starting recover at 16-APR-12 USING channel ORA_DISK_1 starting media recovery archive log thread 1 SEQUENCE 67 IS already ON disk AS file /t1/orat1/oradata/test10g_s/redo03.log archive log thread 1 SEQUENCE 68 IS already ON disk AS file /t1/orat1/oradata/test10g_s/redo01.log archive log thread 1 SEQUENCE 69 IS already ON disk AS file /t1/orat1/oradata/test10g_s/redo02.log archive log filename=/t1/orat1/oradata/test10g_s/redo03.log thread=1 SEQUENCE=67 archive log filename=/t1/orat1/oradata/test10g_s/redo01.log thread=1 SEQUENCE=68 archive log filename=/t1/orat1/oradata/test10g_s/redo02.log thread=1 SEQUENCE=69 media recovery complete, elapsed TIME: 00:00:02 Finished recover at 16-APR-12 RMAN> exit Recovery Manager complete. [orat1@hpserver2 ~]$ exit exit SQL> ALTER DATABASE OPEN; ALTER DATABASE OPEN * ERROR at line 1: ORA-01589: must USE RESETLOGS OR NORESETLOGS OPTION FOR DATABASE OPEN SQL> ALTER DATABASE OPEN resetlogs; DATABASE altered. SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'YYYY-MM-DD HH24:MI:SS'; SESSION altered. SQL> SELECT INCARNATION#, RESETLOGS_CHANGE#, RESETLOGS_TIME, STATUS, RESETLOGS_ID FROM V$DATABASE_INCARNATION; INCARNATION# RESETLOGS_CHANGE# RESETLOGS_TIME STATUS RESETLOGS_ID ------------ ----------------- ------------------- ------- ------------ 1 1 2012-03-31 16:09:45 PARENT 779386185 2 251422 2012-04-01 14:32:15 PARENT 779466735 3 252146 2012-04-01 15:09:56 PARENT 779468996 4 263286 2012-04-05 16:16:26 ORPHAN 779818586 5 306405 2012-04-16 11:18:50 CURRENT 780751130 SQL> EXIT Disconnected FROM Oracle DATABASE 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production WITH the Partitioning, OLAP AND DATA Mining options [orat1@hpserver2 ~]$ rman target / catalog RCAT_USER/rcat_password Recovery Manager: Release 10.2.0.3.0 - Production ON Mon Apr 16 11:25:10 2012 Copyright (c) 1982, 2005, Oracle. ALL rights reserved. connected TO target DATABASE: TEST10G (DBID=1030910857) connected TO recovery catalog DATABASE RMAN> unregister DATABASE; DATABASE name IS "TEST10G" AND DBID IS 1030910857 Do you really want TO unregister the DATABASE (enter YES OR NO)? yes DATABASE unregistered FROM the recovery catalog RMAN> register DATABASE; DATABASE registered IN recovery catalog starting FULL resync OF recovery catalog FULL resync complete RMAN> SHOW ALL; RMAN configuration parameters are: CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # DEFAULT CONFIGURE BACKUP OPTIMIZATION OFF; # DEFAULT CONFIGURE DEFAULT DEVICE TYPE TO DISK; # DEFAULT CONFIGURE CONTROLFILE AUTOBACKUP OFF; # DEFAULT CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # DEFAULT CONFIGURE DEVICE TYPE DISK PARALLELISM 5 BACKUP TYPE TO BACKUPSET; CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # DEFAULT CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # DEFAULT CONFIGURE MAXSETSIZE TO UNLIMITED; # DEFAULT CONFIGURE ENCRYPTION FOR DATABASE OFF; # DEFAULT CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # DEFAULT CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # DEFAULT CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/t1/orat1/product/10.2.0/db_1/dbs/snapcf_test10g_s.f'; # DEFAULT RMAN> |
可以看到，这个步骤其实和上一篇ORA-38727错误完全一样，虽然只是一个表空间的恢复，Oracle也必须强制关闭数据库执行全数据库的恢复，而且最终只能RESETLOGS方式打开数据库。
随着OPEN RESETLOGS操作的完成，RMAN-600(8201)错误产生的条件也不再存在，因此CATALOG的创建得以成功，控制文件中隐藏的问题同时得以解决。