这篇文章仍然是RMAN-600错误的后续系列。
RMAN-600(8201)错误:http://yangtingkun.net/?p=690
RMAN-600(8201)错误的重现:http://yangtingkun.net/?p=716
恢复数据库出现ORA-38727:http://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的创建得以成功,控制文件中隐藏的问题同时得以解决。
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/4227/viewspace-721735/ ,如需转载,请注明出处,否则将追究法律责任。