【RMAN】RMAN恢复各类错误解决总结
第一章 RMAN恢复错误
1.1 不完全恢复错误
1.1.1 RMAN-06023
RMAN-06023 : no backup or copy of datafile found to restore 说明
RMAN 的备份信息如下：
RMAN> list backupset summary;
List of Backups
===============
Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
------- -- -- - ----------- --------------- ------- ------- ---------- ---
9 b 1 a disk 01-jun-11 1 1 no dave_lev1
10 b 1 a disk 01-jun-11 1 1 no dave_lev1
13 b a a disk 01-jun-11 1 1 no arc_bak
14 b a a disk 01-jun-11 1 1 no arc_bak
15 b a a disk 01-jun-11 1 1 no arc_bak
16 b a a disk 01-jun-11 1 1 no arc_bak
17 b a a disk 01-jun-11 1 1 no arc_bak
18 b a a disk 01-jun-11 1 1 no arc_bak
19 b a a disk 01-jun-11 1 1 no arc_bak
20 b a a disk 01-jun-11 1 1 no arc_bak
21 b a a disk 01-jun-11 1 1 no arc_bak
22 b f a disk 01-jun-11 1 1 no bak_ctlfile
23 b f a disk 01-jun-11 1 1 no spfile
RMAN> crosscheck backup;
using channel ORA_DISK_1
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=/u01/backup/dave_lev1_0cmdpuof_1_1_20110601 recid=9 stamp=752679695
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=/u01/backup/dave_lev1_0bmdpuoe_1_1_20110601 recid=10 stamp=752679695
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=/u01/backup/arch_0fmdpven_1_1_20110601 recid=13 stamp=752680408
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=/u01/backup/arch_0gmdpven_1_1_20110601 recid=14 stamp=752680422
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=/u01/backup/arch_0hmdpvj4_1_1_20110601 recid=15 stamp=752680549
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=/u01/backup/arch_0imdpvj5_1_1_20110601 recid=16 stamp=752680582
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=/u01/backup/arch_0jmdpvo4_1_1_20110601 recid=17 stamp=752680709
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=/u01/backup/arch_0kmdpvo5_1_1_20110601 recid=18 stamp=752680721
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=/u01/backup/arch_0mmdpvss_1_1_20110601 recid=19 stamp=752680863
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=/u01/backup/arch_0lmdpvsr_1_1_20110601 recid=20 stamp=752680860
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=/u01/backup/arch_0nmdpvv0_1_1_20110601 recid=21 stamp=752680929
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=/u01/backup/ctl_file_0omdpvv7_1_1_20110601 recid=22 stamp=752680937
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=/u01/backup/dave_spfile_0pmdpvva_1_1_20110601 recid=23 stamp=752680939
Crosschecked 13 objects
但是restore validate的时候， 报错：
RMAN> restore database validate;
Starting restore at 01-JUN-11
using channel ORA_DISK_1
RMAN-00571: =================================================
RMAN-00569: ===== ERROR MESSAGE STACK FOLLOWS ====
RMAN-00571: ==========================================
RMAN-03002: failure of restore command at 06/01/2011 21:21:28
RMAN-06026: some targets not found - aborting restore
RMAN-06023: no backup or copy of datafile 3 found to restore
RMAN-06023: no backup or copy of datafile 2 found to restore
RMAN-06023: no backup or copy of datafile 1 found to restore
一般来说，遇到这种问题是因为控制过旧，即控制文件中没有备份的信息。
比如在nocatalog模式下，备份数据文件之前，先备份控制文件，然后在备份数据库。 在还原的时候，先还原还原控制文件，此时的控制文件中并没有包含RMAN 备份的信息，这时进行恢复就会遇到RMAN-06023 的错误。 但我这里控制文件没有修改。 所以不是这个原因造成。
这几种方法是问题的一方面，不过我遇到的情况还有一个特殊性。 就是我的RMAN 采用了增量备份，但是我没有做0级备份，而是直接用1级备份。 这种情况下，RMAN 发现没有0级备份，所以此时的1级备份也相当于0级备份。
尝试重新做了一次0级备份，在次validate，居然ok了。
RMAN> RESTORE DATABASE VALIDATE;
Starting restore at 01-JUN-11
using channel ORA_DISK_1
channel ORA_DISK_1: starting validation of datafile backupset
channel ORA_DISK_1: reading from backup piece /u01/backup/dave_lev0_10mdqqtd_1_1_20110601
channel ORA_DISK_1: restored backup piece 1
piece handle=/u01/backup/dave_lev0_10mdqqtd_1_1_20110601 tag=DAVE_LEV0
channel ORA_DISK_1: validation complete, elapsed time: 00:00:07
channel ORA_DISK_1: starting validation of datafile backupset
channel ORA_DISK_1: reading from backup piece /u01/backup/dave_lev0_0vmdqqtd_1_1_20110601
channel ORA_DISK_1: restored backup piece 1
piece handle=/u01/backup/dave_lev0_0vmdqqtd_1_1_20110601 tag=DAVE_LEV0
channel ORA_DISK_1: validation complete, elapsed time: 00:00:15
Finished restore at 01-JUN-11
正常情况下直接进行1级备份也是可以进行恢复的。 所以不应该出现这种问题。 所以在进行一次测试，就是使用1级备份进行恢复，看这种备份能否正常用于恢复。
到另一台单实例测试库上进行一下测试。 上面这台是我的RAC 测试库，折腾坏了，一时也没空去捣鼓。
在ORACLE 10g数据库还原过程遭遇RMAN-06023: no backup or copy of datafile x found to restore，具体情况如下所示
.....................................................................................
File Name: /u03/flash_recovery_area/EPPS/archivelog/2015_01_26/o1_mf_1_10_bdcwsc6t_.arc
File Name: /u03/flash_recovery_area/EPPS/archivelog/2015_01_26/o1_mf_1_23_bdcxwwx6_.arc
File Name: /u03/flash_recovery_area/EPPS/archivelog/2015_01_26/o1_mf_1_16_bdcxwgmd_.arc
File Name: /u03/flash_recovery_area/EPPS/archivelog/2015_01_26/o1_mf_1_39_bdczfb6o_.arc
File Name: /u03/flash_recovery_area/EPPS/archivelog/2015_01_26/o1_mf_1_40_bdczzotd_.arc
File Name: /u03/flash_recovery_area/EPPS/archivelog/2015_01_26/o1_mf_1_19_bdcxwmoy_.arc
File Name: /u03/flash_recovery_area/EPPS/archivelog/2015_01_26/o1_mf_1_31_bdcyvsk0_.arc
using channel ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 03/06/2015 21:56:26
RMAN-06026: some targets not found - aborting restore
RMAN-06023: no backup or copy of datafile 4 found to restore
RMAN-06023: no backup or copy of datafile 3 found to restore
RMAN-06023: no backup or copy of datafile 1 found to restore
RMAN>
在RMAN里面使用restore database validate验证备份时也报RMAN-06023错误
RMAN> list backup of datafile 1;
using target database control file instead of recovery catalog
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
46739 Full 1.75G DISK 00:16:07 05-MAR-15
BP Key: 50263 Status: AVAILABLE Compressed: YES Tag: TAG20150305T010709
Piece Name: /u03/flash_recovery_area/backup/backupsets/ora_df873514789_s46810_s1
List of Datafiles in backup set 46739
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- --------- ----
1 Full 17572554495 05-MAR-15 /u01/app/oracle/oradata/epps/system01.dbf
RMAN> list backup of datafile 3;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
46736 Full 8.83G DISK 00:52:30 05-MAR-15
BP Key: 50260 Status: AVAILABLE Compressed: YES Tag: TAG20150305T010709
Piece Name: /u03/flash_recovery_area/backup/backupsets/ora_df873508030_s46807_s1
List of Datafiles in backup set 46736
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- --------- ----
3 Full 17571362089 05-MAR-15 /u01/app/oracle/oradata/epps/sysaux01.dbf
[oracle@getlnx01 archivelog]$ ls /u03/flash_recovery_area/backup/backupsets/ora_df873508030_s46807_s1
/u03/flash_recovery_area/backup/backupsets/ora_df873508030_s46807_s1
检查备份文件，发现都是存在的，根本没有问题。最后检查发现是incarnation的问题，因为中间我对该数据库做了一次不完全恢复，做了resetlogs操作。
RMAN> list incarnation;
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1 1 EPPS 2179993557 PARENT 1 30-JUN-05
2 2 EPPS 2179993557 PARENT 446075 19-JUL-09
3 3 EPPS 2179993557 CURRENT 16926695161 23-JAN-15
解决方法：
重置数据库的incarnation到2，然后还原数据库，问题解决。关于incarnation的资料，可以参考官方资料7.6.2 Point-in-Time Recovery and Database Incarnations: Concepts
RMAN> reset database to incarnation 2;
database reset to incarnation 2
背景：
之前做了基于SCN的不完全恢复，在尝试恢复的过程中使用了_allow_resetlogs_corruption参数,resetlogs之后，Oracle使用的当前控制文件不允许从这个历史的备份集中进行恢复，从而导致了RMAN-06026这个错误，错误现象如下：
错误现象：
RMAN> restore database;
Starting restore at 26-JUL-12
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=47 devtype=DISK
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 07/26/2012 12:41:17
RMAN-06026: some targets not found - aborting restore
RMAN-06023: no backup or copy of datafile 7 found to restore
RMAN-06023: no backup or copy of datafile 6 found to restore
RMAN-06023: no backup or copy of datafile 5 found to restore
RMAN-06023: no backup or copy of datafile 4 found to restore
RMAN-06023: no backup or copy of datafile 3 found to restore
RMAN-06023: no backup or copy of datafile 2 found to restore
RMAN-06023: no backup or copy of datafile 1 found to restore
错误分析：
首先我们的数据库是肯定做过全备的，但是从如上恢复反馈出来的信息可以看到没有数据文件的备份活拷贝，那么这个时候我们可以考虑尝试的使用
dbms_backup_resetore 这个包来制定路径进行数据库的手工恢复，详细步骤如下：
解决办法：
执行dbms_backup_restore包来进行恢复：
DECLARE
devtype varchar2(256);
done boolean;
BEGIN
devtype:=sys.dbms_backup_restore.deviceAllocate (type=>'',ident=>'FUN');
sys.dbms_backup_restore.restoreSetDatafile;
sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>01,toname=>'/DBBak2/oradata/WWL/system01.dbf');
sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>02,toname=>'/DBBak2/oradata/WWL/undotbs01.dbf');
sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>03,toname=>'/DBBak2/oradata/WWL/sysaux01.dbf');
sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>04,toname=>'/DBBak2/oradata/WWL/users01.dbf');
sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>05,toname=>'/DBBak2/oradata/WWL/wwl001.dbf');
sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>06,toname=>'/DBBak2/oradata/WWL/wwl002.dbf');
sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>07,toname=>'/DBBak2/oradata/WWL/wwl003.dbf');
sys.dbms_backup_restore.restoreBackupPiece(done=>done,handle=>'/DBSoft/product/10.2.0/db_1/dbs/0pnh23kk_1_1', params=>null);
sys.dbms_backup_restore.deviceDeallocate;
END;
/
执行步骤如下：
1、将数据库启动到nomount状态
SQL> startup nomount;
Oracle instance started.
Total System Global Area 100663296 bytes
Fixed Size 1217884 bytes
Variable Size 88083108 bytes
Database Buffers 8388608 bytes
Redo Buffers 2973696 bytes
2、执行手工恢复包
SQL>DECLARE
done boolean;
devtype varchar2(256);
done boolean;
BEGIN
devtype:=sys.dbms_backup_restore.deviceAllocate (type=>'',ident=>'FUN');
6 sys.dbms_backup_restore.restoreSetDatafile;
7 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>01,toname=>'/DBBak2/oradata/WWL/system01.dbf');
sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>02,toname=>'/DBBak2/oradata/WWL/undotbs01.dbf');
sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>04,toname=>'/DBBak2/oradata/WWL/wwl001.dbf');
sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>03,toname=>'/DBBak2/oradata/WWL/users01.dbf');
END;
sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>04,toname=>'/DBBak2/oradata/WWL/wwl001.dbf');
sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>05,toname=>'/DBBak2/oradata/WWL/wwl002.dbf');
sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>06,toname=>'/DBBak2/oradata/WWL/wwl003.dbf');
sys.dbms_backup_restore.restoreBackupPiece(done=>done,handle=>'/DBSoft/product/10.2.0/db_1/dbs/0mnh01jv_1_1', params=>null);
sys.dbms_backup_restore.deviceDeallocate;
END;
16 /
PL/SQL procedure successfully completed.
SQL>
3、生成备份控制文件的trace
SQL> alter database backup controlfile to trace;
Database altered.
4、重建控制文件
SQL>CREATE CONTROLFILE REUSE DATABASE "WWL" RESETLOGS ARCHIVELOG
MAXLOGFILES 16
MAXLOGMEMBERS 3
MAXDATAFILES 100
MAXINSTANCES 8
MAXLOGHISTORY 292
LOGFILE
GROUP 4 (
'/DBBak2/oradata/WWL/redo4a.log',
'/DBBak2/oradata/WWL/redo4b.log'
) SIZE 128M,
GROUP 5 (
'/DBBak2/oradata/WWL/redo5a.log',
'/DBBak2/oradata/WWL/redo5b.log'
) SIZE 128M,
GROUP 6 (
'/DBBak2/oradata/WWL/redo6a.log',
'/DBBak2/oradata/WWL/redo6b.log'
) SIZE 128M,
GROUP 7 (
'/DBBak2/oradata/WWL/redo7a.log',
'/DBBak2/oradata/WWL/redo7b.log'
) SIZE 128M
-- STANDBY LOGFILE
DATAFILE
'/DBBak2/oradata/WWL/system01.dbf',
'/DBBak2/oradata/WWL/undotbs01.dbf',
'/DBBak2/oradata/WWL/sysaux01.dbf',
'/DBBak2/oradata/WWL/users01.dbf',
'/DBBak2/oradata/WWL/wwl01.dbf',
'/DBBak2/oradata/WWL/wwl02.dbf',
'/DBBak2/oradata/WWL/wwl03.dbf'
CHARACTER SET ZHS16CGB231280
Database altered.
5、启动数据库
SQL>alter database open resetlogs;
Database altered.
SQL> select instance_name,status from v$instance;
INSTANCE_NAME STATUS
---------------- ------------
WWL OPEN
SQL>
建议最后对数据库做一次全备。
昨天做一个实验，结果把数据库搞坏了，当试图进行恢复时居然报了RMAN-06026错误。 回想一下，原来在尝试恢复中使用了_allow_resetlogs_corruption参数，resetlogs之后，Oracle使用当前的控制文件不允许从这个历史备份集中进行恢复。
由于我没有使用catalog，所以尝试使用dbms_backup_restore进行恢复。
1.错误信息
我们看到虽然list backup可以显示备份集，但是无法进行恢复，错误为RMAN-06026，RMAN-06026。
| [oracle@jumper oradata]$ rman target / Recovery Manager: Release 9.2.0.4.0 - Production Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved. connected to target database: CONNER (DBID=3152029224) RMAN> restore database; Starting restore at 11-JUN-05 using target database controlfile instead of recovery catalogallocated channel: ORA_DISK_1channel ORA_DISK_1: sid=11 devtype=DISKRMAN-00571: ===========================================================RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============RMAN-00571: ===========================================================RMAN-03002: failure of restore command at 06/11/2005 01:19:01RMAN-06026: some targets not found - aborting restoreRMAN-06023: no backup or copy of datafile 3 found to restoreRMAN-06023: no backup or copy of datafile 2 found to restoreRMAN-06023: no backup or copy of datafile 1 found to restore RMAN> list backup; List of Backup Sets=================== BS Key Type LV Size Device Type Elapsed Time Completion Time------- ---- -- ---------- ----------- ------------ ---------------13 Full 1G DISK 00:03:20 09-JUN-05 BP Key: 13 Status: AVAILABLE Tag: TAG20050609T173346 Piece Name: /opt/oracle/product/9.2.0/dbs/0ggmiabq_1_1 SPFILE Included: Modification time: 08-JUN-05 List of Datafiles in backup set 13 File LV Type Ckp SCN Ckp Time Name ---- -- ---- ---------- --------- ---- 1 Full 240560269 09-JUN-05 /opt/oracle/oradata/conner/system01.dbf 2 Full 240560269 09-JUN-05 /opt/oracle/oradata/conner/undotbs01.dbf 3 Full 240560269 09-JUN-05 /opt/oracle/oradata/conner/users01.dbf RMAN> exit Recovery Manager complete. |
2.使用dbms_backup_restore进行恢复
dbms_backup_restore是一个非常强大的package，可以在数据库nomount下使用，用于从备份集中读取各类文件。
本例使用如下脚本:
| DECLARE devtype varchar2(256); done boolean; BEGIN devtype:=sys.dbms_backup_restore.deviceAllocate (type=>'',ident=>'t1'); sys.dbms_backup_restore.restoreSetDatafile; sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>01,toname=>'/opt/oracle/oradata/conner/system01.dbf'); sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>02,toname=>'/opt/oracle/oradata/conner/undotbs01.dbf'); sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>03,toname=>'/opt/oracle/oradata/conner/users01.dbf'); sys.dbms_backup_restore.restoreBackupPiece(done=>done,handle=>'/opt/oracle/product/9.2.0/dbs/0ggmiabq_1_1', params=>null); sys.dbms_backup_restore.deviceDeallocate;END;/ |
3.执行恢复
| [oracle@jumper conner]$ sqlplus "/ as sysdba" SQL*Plus: Release 9.2.0.4.0 - Production on Sat Jun 11 01:24:34 2005 Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved. Connected to an idle instance. SQL> startup nomount;ORACLE instance started. Total System Global Area 101782828 bytesFixed Size 451884 bytesVariable Size 37748736 bytesDatabase Buffers 62914560 bytesRedo Buffers 667648 bytes SQL> DECLARE 2 devtype varchar2(256); 3 done boolean; 4 BEGIN 5 devtype:=sys.dbms_backup_restore.deviceAllocate (type=>'',ident=>'t1'); 6 sys.dbms_backup_restore.restoreSetDatafile; 7 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>01,toname=>'/opt/oracle/oradata/conner/system01.dbf'); 8 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>02,toname=>'/opt/oracle/oradata/conner/undotbs01.dbf'); 9 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>03,toname=>'/opt/oracle/oradata/conner/users01.dbf'); 10 sys.dbms_backup_restore.restoreBackupPiece(done=>done,handle=>'/opt/oracle/product/9.2.0/dbs/0ggmiabq_1_1', params=>null); 11 sys.dbms_backup_restore.deviceDeallocate; 12 END; 13 / PL/SQL procedure successfully completed. SQL> |
至此，从备份集中读取文件完毕。
4.恢复控制文件
由于大意，也没有备份控制文件，所以只好重建控制文件。
| SQL> alter database mount; Database altered. SQL> alter database backup controlfile to trace; Database altered. |
找到trace文件，编辑、执行重建控制文件需要部分:
| [oracle@jumper oracle]$ sqlplus "/ as sysdba"SQL*Plus: Release 9.2.0.4.0 - Production on Sat Jun 11 01:30:50 2005 Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved. Connected to:Oracle9i Enterprise Edition Release 9.2.0.4.0 - ProductionWith the Partitioning optionJServer Release 9.2.0.4.0 - Production SQL> shutdown immediate;ORA-01109: database not open Database dismounted.ORACLE instance shut down. SQL> startup nomount;ORACLE instance started. Total System Global Area 101782828 bytesFixed Size 451884 bytesVariable Size 37748736 bytesDatabase Buffers 62914560 bytesRedo Buffers 667648 bytesSQL> set echo onSQL> @ctlSQL> SQL> CREATE CONTROLFILE REUSE DATABASE "CONNER" RESETLOGS ARCHIVELOG 2 -- SET STANDBY TO MAXIMIZE PERFORMANCE 3 MAXLOGFILES 5 4 MAXLOGMEMBERS 3 5 MAXDATAFILES 100 6 MAXINSTANCES 1 7 MAXLOGHISTORY 1361 8 LOGFILE 9 GROUP 1 '/opt/oracle/oradata/conner/redo01.log' SIZE 10M, 10 GROUP 2 '/opt/oracle/oradata/conner/redo02.log' SIZE 10M, 11 GROUP 3 '/opt/oracle/oradata/conner/redo03.log' SIZE 10M 12 -- STANDBY LOGFILE 13 DATAFILE 14 '/opt/oracle/oradata/conner/system01.dbf', 15 '/opt/oracle/oradata/conner/undotbs01.dbf', 16 '/opt/oracle/oradata/conner/users01.dbf' 17 CHARACTER SET ZHS16GBK 18 ; Control file created. |
5.执行恢复
| SQL> recover database;ORA-00283: recovery session canceled due to errorsORA-01610: recovery using the BACKUP CONTROLFILE option must be done SQL> recover database using backup controlfile until cancel;ORA-00279: change 240560269 generated at 06/09/2005 17:33:48 needed for thread 1ORA-00289: suggestion : /opt/oracle/oradata/conner/archive/1_7.dbfORA-00280: change 240560269 for thread 1 is in sequence #7 Specify log: {=suggested | filename | AUTO | CANCEL} autoORA-00279: change 240600632 generated at 06/10/2005 10:42:26 needed for thread 1ORA-00289: suggestion : /opt/oracle/oradata/conner/archive/1_8.dbfORA-00280: change 240600632 for thread 1 is in sequence #8ORA-00278: log file '/opt/oracle/oradata/conner/archive/1_7.dbf' no longer needed for this recovery Specify log: {=suggested | filename | AUTO | CANCEL}autoORA-00279: change 240620884 generated at 06/10/2005 10:45:42 needed for thread 1ORA-00289: suggestion : /opt/oracle/oradata/conner/archive/1_9.dbfORA-00280: change 240620884 for thread 1 is in sequence #9ORA-00278: log file '/opt/oracle/oradata/conner/archive/1_8.dbf' no longer needed for this recovery ORA-00283: recovery session canceled due to errorsORA-00600: internal error code, arguments: [3020], [4242465], [1], [9], [314], [272], [], []ORA-10567: Redo is inconsistent with data block (file# 1, block# 48161)ORA-10564: tablespace SYSTEMORA-01110: data file 1: '/opt/oracle/oradata/conner/system01.dbf'ORA-10560: block type 'DATA SEGMENT HEADER - UNLIMITED' ORA-01112: media recovery not started SQL> recover database using backup controlfile until cancel;ORA-00279: change 240620949 generated at 06/10/2005 10:45:44 needed for thread 1ORA-00289: suggestion : /opt/oracle/oradata/conner/archive/1_9.dbfORA-00280: change 240620949 for thread 1 is in sequence #9 Specify log: {=suggested | filename | AUTO | CANCEL}cancelMedia recovery cancelled.SQL> alter database open resetlogs; Database altered. SQL> select name from v$datafile; NAME------------------------------------------------------------/opt/oracle/oradata/conner/system01.dbf/opt/oracle/oradata/conner/undotbs01.dbf/opt/oracle/oradata/conner/users01.dbf SQL> |
至此恢复完毕。
执行restore database 或 duplicate target database to vmdb2;
报如下错误：
1、$ rman target /
RMAN> restore database;
RMAN-03002: failure of restore command at 06/11/2005 01:19:01
RMAN-06026: some targets not found - aborting restore
RMAN-06023: no backup or copy of datafile 3 found to restore
RMAN-06023: no backup or copy of datafile 2 found to restore
RMAN-06023: no backup or copy of datafile 1 found to restore
----经过深入检讨，发现问题并非没有备份，而是恢复目标路径不存在。
----解决办法：
1， 建立目标路径。 mkdir -p /opt/app/oracle/oradata/VMDB2/
2，建立路径映射，（注意：需对所有恢复的数据文件作路径映射检查）
db_file_name_convert='/VMDB1','/VMDB2','/opt/app/oracle/oradata/VMDB1/','/data/VMDB2'
log_file_name_convert='/VMDB1','/VMDB2','/opt/app/oracle/oradata/VMDB1/','/data/VMDB2'
1.1.1.1 解决办法
google 一下。 有网友通过以下几种方法解决了这个问题：
1. shutdown abort。
2. crosscheck backup
3 设置 DBID set DBID=187761848
4. 重建UNDO Tablespace
5. 将备份集放在和备份同样的目录上,然后crosscheck backup
6. 执行dbms_backup_restore包来进行恢复
7.检查恢复路径是否存在，如果是异机不同路径恢复，则恢复之前的路径和要恢复的路径都需要创建
8.备份文件是否真的存在
1.1.2 RMAN-06025报错的原因和处理方法
报错信息：
RMAN-06025: no backup of archived log for thread 1 with sequence *** and starting SCN of ********* found to restore
报错背景：
朋友在进行测试环境测试库恢复的过程中遇到此问题，怀疑是找不到归档文件导致的，由于其已经执行过增量备份，所以大家都推测很可能是有归档没备份进去导致的。
测试过程：
归档文件在的时候执行数据库恢复（恢复成功）：
RMAN> restore database;
Starting restore at 19-MAR-15
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=134 device type=DISK
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00001 to /oracle/app/oradata/ORCL/datafile/o1_mf_system_8xm4839m_.dbf
channel ORA_DISK_1: restoring datafile 00003 to /oracle/app/oradata/ORCL/datafile/o1_mf_undotbs1_8xm483gd_.dbf
channel ORA_DISK_1: restoring datafile 00007 to /oracle/app/oradata/ORCL/datafile/gaoqiang.dbf
channel ORA_DISK_1: restoring datafile 00008 to /oracle/app/oradata/ORCL/datafile/gao.dbf
channel ORA_DISK_1: restoring datafile 00009 to /oracle/app/oradata/ORCL/datafile/lee.dbf
channel ORA_DISK_1: restoring datafile 00014 to /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORADATAORCLDRSYS01.DBF
channel ORA_DISK_1: restoring datafile 00015 to /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORADATAORCLINDX01.DBF
channel ORA_DISK_1: restoring datafile 00017 to /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORADATAORCLTOOLS01.DBF
channel ORA_DISK_1: restoring datafile 00018 to /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORADATAORCLXDB01.DBF
channel ORA_DISK_1: restoring datafile 00019 to /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORA92DATABASECA_PARTDATA.DBF
channel ORA_DISK_1: restoring datafile 00020 to /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORA92DATABASECA_INDEX.DBF
channel ORA_DISK_1: restoring datafile 00023 to /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORA92DATABASEOCSP_DATA.DBF
channel ORA_DISK_1: restoring datafile 00024 to /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORA92DATABASEOCSP_INDEX.DBF
channel ORA_DISK_1: restoring datafile 00027 to /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORA92DATABASEBSTRSPACE.DBF
channel ORA_DISK_1: reading from backup piece /backup/orcl_full_ORCL_20150319_3eq27jsk_1_1_L0
channel ORA_DISK_1: piece handle=/backup/orcl_full_ORCL_20150319_3eq27jsk_1_1_L0 tag=VALIDATE
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:25
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00002 to /oracle/app/oradata/ORCL/datafile/o1_mf_sysaux_8xm483f7_.dbf
channel ORA_DISK_1: restoring datafile 00004 to /oracle/app/oradata/ORCL/datafile/o1_mf_users_8xm483jk_.dbf
channel ORA_DISK_1: restoring datafile 00005 to /oracle/app/oradata/ORCL/datafile/o1_mf_example_8xm4gzck_.dbf
channel ORA_DISK_1: restoring datafile 00006 to /oracle/app/oradata/catalog_rman/rmantbs01.dbf
channel ORA_DISK_1: restoring datafile 00010 to /oracle/app/oradata/ORCL/datafile/jon.dbf
channel ORA_DISK_1: restoring datafile 00011 to /oracle/app/oradata/ORCL/datafile/CA_DATA.dbf
channel ORA_DISK_1: restoring datafile 00012 to /oracle/app/oradata/ORCL/datafile/CA_TEMP.dbf
channel ORA_DISK_1: restoring datafile 00013 to /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORADATAORCLCWMLITE01.DBF
channel ORA_DISK_1: restoring datafile 00016 to /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORADATAORCLODM01.DBF
channel ORA_DISK_1: restoring datafile 00021 to /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORA92DATABASEKMC_DATA.DBF
channel ORA_DISK_1: restoring datafile 00022 to /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORA92DATABASEKMC_INDEX.DBF
channel ORA_DISK_1: restoring datafile 00025 to /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORA92DATABASETSADB_DATA.DBF
channel ORA_DISK_1: restoring datafile 00026 to /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORA92DATABASETSADB_INDEX.DBF
channel ORA_DISK_1: restoring datafile 00028 to /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORA92DATABASERA_DATA_01.DBF
channel ORA_DISK_1: reading from backup piece /backup/orcl_full_ORCL_20150319_3fq27jsl_1_1_L0
channel ORA_DISK_1: piece handle=/backup/orcl_full_ORCL_20150319_3fq27jsl_1_1_L0 tag=VALIDATE
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:15
Finished restore at 19-MAR-15
RMAN> recover database
2> ;
Starting recover at 19-MAR-15
using channel ORA_DISK_1
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
destination for restore of datafile 00001: /oracle/app/oradata/ORCL/datafile/o1_mf_system_8xm4839m_.dbf
destination for restore of datafile 00007: /oracle/app/oradata/ORCL/datafile/gaoqiang.dbf
destination for restore of datafile 00008: /oracle/app/oradata/ORCL/datafile/gao.dbf
destination for restore of datafile 00010: /oracle/app/oradata/ORCL/datafile/jon.dbf
destination for restore of datafile 00014: /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORADATAORCLDRSYS01.DBF
destination for restore of datafile 00016: /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORADATAORCLODM01.DBF
destination for restore of datafile 00017: /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORADATAORCLTOOLS01.DBF
channel ORA_DISK_1: reading from backup piece /backup/orcl_Inc_ORCL_20150319_3nq27k0e_1_1_L1
channel ORA_DISK_1: piece handle=/backup/orcl_Inc_ORCL_20150319_3nq27k0e_1_1_L1 tag=VALIDATE
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
destination for restore of datafile 00002: /oracle/app/oradata/ORCL/datafile/o1_mf_sysaux_8xm483f7_.dbf
destination for restore of datafile 00009: /oracle/app/oradata/ORCL/datafile/lee.dbf
destination for restore of datafile 00013: /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORADATAORCLCWMLITE01.DBF
destination for restore of datafile 00015: /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORADATAORCLINDX01.DBF
destination for restore of datafile 00018: /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORADATAORCLXDB01.DBF
destination for restore of datafile 00020: /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORA92DATABASECA_INDEX.DBF
destination for restore of datafile 00026: /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORA92DATABASETSADB_INDEX.DBF
channel ORA_DISK_1: reading from backup piece /backup/orcl_Inc_ORCL_20150319_3oq27k0f_1_1_L1
channel ORA_DISK_1: piece handle=/backup/orcl_Inc_ORCL_20150319_3oq27k0f_1_1_L1 tag=VALIDATE
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
destination for restore of datafile 00003: /oracle/app/oradata/ORCL/datafile/o1_mf_undotbs1_8xm483gd_.dbf
destination for restore of datafile 00004: /oracle/app/oradata/ORCL/datafile/o1_mf_users_8xm483jk_.dbf
destination for restore of datafile 00005: /oracle/app/oradata/ORCL/datafile/o1_mf_example_8xm4gzck_.dbf
destination for restore of datafile 00019: /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORA92DATABASECA_PARTDATA.DBF
destination for restore of datafile 00023: /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORA92DATABASEOCSP_DATA.DBF
destination for restore of datafile 00024: /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORA92DATABASEOCSP_INDEX.DBF
destination for restore of datafile 00027: /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORA92DATABASEBSTRSPACE.DBF
channel ORA_DISK_1: reading from backup piece /backup/orcl_Inc_ORCL_20150319_3pq27k0f_1_1_L1
channel ORA_DISK_1: piece handle=/backup/orcl_Inc_ORCL_20150319_3pq27k0f_1_1_L1 tag=VALIDATE
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
destination for restore of datafile 00006: /oracle/app/oradata/catalog_rman/rmantbs01.dbf
destination for restore of datafile 00011: /oracle/app/oradata/ORCL/datafile/CA_DATA.dbf
destination for restore of datafile 00012: /oracle/app/oradata/ORCL/datafile/CA_TEMP.dbf
destination for restore of datafile 00021: /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORA92DATABASEKMC_DATA.DBF
destination for restore of datafile 00022: /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORA92DATABASEKMC_INDEX.DBF
destination for restore of datafile 00025: /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORA92DATABASETSADB_DATA.DBF
destination for restore of datafile 00028: /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORA92DATABASERA_DATA_01.DBF
channel ORA_DISK_1: reading from backup piece /backup/orcl_Inc_ORCL_20150319_3qq27k0f_1_1_L1
channel ORA_DISK_1: piece handle=/backup/orcl_Inc_ORCL_20150319_3qq27k0f_1_1_L1 tag=VALIDATE
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
starting media recovery
archived log for thread 1 with sequence 164 is already on disk as file /archlog/orcl/1_164_820195525.dbf
archived log for thread 1 with sequence 165 is already on disk as file /archlog/orcl/1_165_820195525.dbf
archived log for thread 1 with sequence 166 is already on disk as file /archlog/orcl/1_166_820195525.dbf
archived log for thread 1 with sequence 167 is already on disk as file /archlog/orcl/1_167_820195525.dbf
archived log file name=/archlog/orcl/1_164_820195525.dbf thread=1 sequence=164
archived log file name=/archlog/orcl/1_165_820195525.dbf thread=1 sequence=165
media recovery complete, elapsed time: 00:00:00
Finished recover at 19-MAR-15
OK，恢复成功，没有任何问题！~~~
接着执行alter system switch logfile生成3个新的归档日志，新的3个日志是不在最新的增量备份中的。
挪走归档日志，其中包括新生成的3个日志：
[root@dbserver backup]# mkdir archbackup
[root@dbserver backup]# cd /archlog/orcl/
[root@dbserver orcl]# ls
1_100_820195525.dbf 1_111_820195525.dbf 1_122_820195525.dbf 1_133_820195525.dbf 1_144_820195525.dbf 1_155_820195525.dbf 1_166_820195525.dbf
1_101_820195525.dbf 1_112_820195525.dbf 1_123_820195525.dbf 1_134_820195525.dbf 1_145_820195525.dbf 1_156_820195525.dbf 1_167_820195525.dbf
1_102_820195525.dbf 1_113_820195525.dbf 1_124_820195525.dbf 1_135_820195525.dbf 1_146_820195525.dbf 1_157_820195525.dbf 1_92_820195525.dbf
1_103_820195525.dbf 1_114_820195525.dbf 1_125_820195525.dbf 1_136_820195525.dbf 1_147_820195525.dbf 1_158_820195525.dbf 1_93_820195525.dbf
1_104_820195525.dbf 1_115_820195525.dbf 1_126_820195525.dbf 1_137_820195525.dbf 1_148_820195525.dbf 1_159_820195525.dbf 1_94_820195525.dbf
1_105_820195525.dbf 1_116_820195525.dbf 1_127_820195525.dbf 1_138_820195525.dbf 1_149_820195525.dbf 1_160_820195525.dbf 1_95_820195525.dbf
1_106_820195525.dbf 1_117_820195525.dbf 1_128_820195525.dbf 1_139_820195525.dbf 1_150_820195525.dbf 1_161_820195525.dbf 1_96_820195525.dbf
1_107_820195525.dbf 1_118_820195525.dbf 1_129_820195525.dbf 1_140_820195525.dbf 1_151_820195525.dbf 1_162_820195525.dbf 1_97_820195525.dbf
1_108_820195525.dbf 1_119_820195525.dbf 1_130_820195525.dbf 1_141_820195525.dbf 1_152_820195525.dbf 1_163_820195525.dbf 1_98_820195525.dbf
1_109_820195525.dbf 1_120_820195525.dbf 1_131_820195525.dbf 1_142_820195525.dbf 1_153_820195525.dbf 1_164_820195525.dbf 1_99_820195525.dbf
1_110_820195525.dbf 1_121_820195525.dbf 1_132_820195525.dbf 1_143_820195525.dbf 1_154_820195525.dbf 1_165_820195525.dbf
[root@dbserver orcl]# mv ./* /backup/archbackup/
[root@dbserver orcl]# ls -lt
总计 0 ---OK，归档路径下没有任何归档日志文件
[root@dbserver orcl]# pwd
/archlog/orcl
再进行数据库恢复：
重启数据库到mount状态
RMAN> shutdown immediate;
database dismounted
Oracle instance shut down
RMAN> startup mount;
connected to target database (not started)
Oracle instance started
database mounted
Total System Global Area 417546240 bytes
Fixed Size 2213936 bytes
Variable Size 364906448 bytes
Database Buffers 41943040 bytes
Redo Buffers 8482816 bytes
RMAN> restore database;
Starting restore at 19-MAR-15
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=133 device type=DISK
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00001 to /oracle/app/oradata/ORCL/datafile/o1_mf_system_8xm4839m_.dbf
channel ORA_DISK_1: restoring datafile 00003 to /oracle/app/oradata/ORCL/datafile/o1_mf_undotbs1_8xm483gd_.dbf
channel ORA_DISK_1: restoring datafile 00007 to /oracle/app/oradata/ORCL/datafile/gaoqiang.dbf
channel ORA_DISK_1: restoring datafile 00008 to /oracle/app/oradata/ORCL/datafile/gao.dbf
channel ORA_DISK_1: restoring datafile 00009 to /oracle/app/oradata/ORCL/datafile/lee.dbf
channel ORA_DISK_1: restoring datafile 00014 to /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORADATAORCLDRSYS01.DBF
channel ORA_DISK_1: restoring datafile 00015 to /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORADATAORCLINDX01.DBF
channel ORA_DISK_1: restoring datafile 00017 to /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORADATAORCLTOOLS01.DBF
channel ORA_DISK_1: restoring datafile 00018 to /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORADATAORCLXDB01.DBF
channel ORA_DISK_1: restoring datafile 00019 to /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORA92DATABASECA_PARTDATA.DBF
channel ORA_DISK_1: restoring datafile 00020 to /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORA92DATABASECA_INDEX.DBF
channel ORA_DISK_1: restoring datafile 00023 to /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORA92DATABASEOCSP_DATA.DBF
channel ORA_DISK_1: restoring datafile 00024 to /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORA92DATABASEOCSP_INDEX.DBF
channel ORA_DISK_1: restoring datafile 00027 to /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORA92DATABASEBSTRSPACE.DBF
channel ORA_DISK_1: reading from backup piece /backup/orcl_full_ORCL_20150319_3eq27jsk_1_1_L0
channel ORA_DISK_1: piece handle=/backup/orcl_full_ORCL_20150319_3eq27jsk_1_1_L0 tag=VALIDATE
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:15
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00002 to /oracle/app/oradata/ORCL/datafile/o1_mf_sysaux_8xm483f7_.dbf
channel ORA_DISK_1: restoring datafile 00004 to /oracle/app/oradata/ORCL/datafile/o1_mf_users_8xm483jk_.dbf
channel ORA_DISK_1: restoring datafile 00005 to /oracle/app/oradata/ORCL/datafile/o1_mf_example_8xm4gzck_.dbf
channel ORA_DISK_1: restoring datafile 00006 to /oracle/app/oradata/catalog_rman/rmantbs01.dbf
channel ORA_DISK_1: restoring datafile 00010 to /oracle/app/oradata/ORCL/datafile/jon.dbf
channel ORA_DISK_1: restoring datafile 00011 to /oracle/app/oradata/ORCL/datafile/CA_DATA.dbf
channel ORA_DISK_1: restoring datafile 00012 to /oracle/app/oradata/ORCL/datafile/CA_TEMP.dbf
channel ORA_DISK_1: restoring datafile 00013 to /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORADATAORCLCWMLITE01.DBF
channel ORA_DISK_1: restoring datafile 00016 to /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORADATAORCLODM01.DBF
channel ORA_DISK_1: restoring datafile 00021 to /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORA92DATABASEKMC_DATA.DBF
channel ORA_DISK_1: restoring datafile 00022 to /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORA92DATABASEKMC_INDEX.DBF
channel ORA_DISK_1: restoring datafile 00025 to /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORA92DATABASETSADB_DATA.DBF
channel ORA_DISK_1: restoring datafile 00026 to /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORA92DATABASETSADB_INDEX.DBF
channel ORA_DISK_1: restoring datafile 00028 to /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORA92DATABASERA_DATA_01.DBF
channel ORA_DISK_1: reading from backup piece /backup/orcl_full_ORCL_20150319_3fq27jsl_1_1_L0
channel ORA_DISK_1: piece handle=/backup/orcl_full_ORCL_20150319_3fq27jsl_1_1_L0 tag=VALIDATE
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:15
Finished restore at 19-MAR-15
RMAN> recover database;
Starting recover at 19-MAR-15
using channel ORA_DISK_1
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
destination for restore of datafile 00001: /oracle/app/oradata/ORCL/datafile/o1_mf_system_8xm4839m_.dbf
destination for restore of datafile 00007: /oracle/app/oradata/ORCL/datafile/gaoqiang.dbf
destination for restore of datafile 00008: /oracle/app/oradata/ORCL/datafile/gao.dbf
destination for restore of datafile 00010: /oracle/app/oradata/ORCL/datafile/jon.dbf
destination for restore of datafile 00014: /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORADATAORCLDRSYS01.DBF
destination for restore of datafile 00016: /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORADATAORCLODM01.DBF
destination for restore of datafile 00017: /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORADATAORCLTOOLS01.DBF
channel ORA_DISK_1: reading from backup piece /backup/orcl_Inc_ORCL_20150319_3nq27k0e_1_1_L1
channel ORA_DISK_1: piece handle=/backup/orcl_Inc_ORCL_20150319_3nq27k0e_1_1_L1 tag=VALIDATE
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
destination for restore of datafile 00002: /oracle/app/oradata/ORCL/datafile/o1_mf_sysaux_8xm483f7_.dbf
destination for restore of datafile 00009: /oracle/app/oradata/ORCL/datafile/lee.dbf
destination for restore of datafile 00013: /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORADATAORCLCWMLITE01.DBF
destination for restore of datafile 00015: /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORADATAORCLINDX01.DBF
destination for restore of datafile 00018: /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORADATAORCLXDB01.DBF
destination for restore of datafile 00020: /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORA92DATABASECA_INDEX.DBF
destination for restore of datafile 00026: /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORA92DATABASETSADB_INDEX.DBF
channel ORA_DISK_1: reading from backup piece /backup/orcl_Inc_ORCL_20150319_3oq27k0f_1_1_L1
channel ORA_DISK_1: piece handle=/backup/orcl_Inc_ORCL_20150319_3oq27k0f_1_1_L1 tag=VALIDATE
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
destination for restore of datafile 00003: /oracle/app/oradata/ORCL/datafile/o1_mf_undotbs1_8xm483gd_.dbf
destination for restore of datafile 00004: /oracle/app/oradata/ORCL/datafile/o1_mf_users_8xm483jk_.dbf
destination for restore of datafile 00005: /oracle/app/oradata/ORCL/datafile/o1_mf_example_8xm4gzck_.dbf
destination for restore of datafile 00019: /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORA92DATABASECA_PARTDATA.DBF
destination for restore of datafile 00023: /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORA92DATABASEOCSP_DATA.DBF
destination for restore of datafile 00024: /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORA92DATABASEOCSP_INDEX.DBF
destination for restore of datafile 00027: /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORA92DATABASEBSTRSPACE.DBF
channel ORA_DISK_1: reading from backup piece /backup/orcl_Inc_ORCL_20150319_3pq27k0f_1_1_L1
channel ORA_DISK_1: piece handle=/backup/orcl_Inc_ORCL_20150319_3pq27k0f_1_1_L1 tag=VALIDATE
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
destination for restore of datafile 00006: /oracle/app/oradata/catalog_rman/rmantbs01.dbf
destination for restore of datafile 00011: /oracle/app/oradata/ORCL/datafile/CA_DATA.dbf
destination for restore of datafile 00012: /oracle/app/oradata/ORCL/datafile/CA_TEMP.dbf
destination for restore of datafile 00021: /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORA92DATABASEKMC_DATA.DBF
destination for restore of datafile 00022: /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORA92DATABASEKMC_INDEX.DBF
destination for restore of datafile 00025: /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORA92DATABASETSADB_DATA.DBF
destination for restore of datafile 00028: /oracle/app/oracle/product/11.2.0/db_1/dbs/ORACLEORA92DATABASERA_DATA_01.DBF
channel ORA_DISK_1: reading from backup piece /backup/orcl_Inc_ORCL_20150319_3qq27k0f_1_1_L1
channel ORA_DISK_1: piece handle=/backup/orcl_Inc_ORCL_20150319_3qq27k0f_1_1_L1 tag=VALIDATE
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
starting media recovery
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 03/19/2015 13:43:56
RMAN-06053: unable to perform media recovery because of missing log
RMAN-06025: no backup of archived log for thread 1 with sequence 167 and starting SCN of 379521673 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 166 and starting SCN of 379521652 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 165 and starting SCN of 379520892 found to restore
确实是由于归档的问题导致了RMAN-06025报错。
解决方法一般有2个：
1.把最新的归档日志复制到归档路径下，再次执行数据库恢复操作；
2.进行不完全恢复。
3.加参数_allow_resetlogs_corruption恢复
startup mount
alter system set "_allow_resetlogs_corruption"=true scope=spfile;
startup force mount
recover database using backup controlfile until cancel;
alter database open resetlogs;
alter system reset "_allow_resetlogs_corruption" scope=spfile sid='*';
shutdown immediate;
不完全恢复方法：
基于时间点：
startup mount;
restore database until time "to_date('2015-04-20 08:13:50','yyyy-mm-dd hh24:mi:ss')";
recover database until time "to_date('2015-04-20 08:13:50','yyyy-mm-dd hh24:mi:ss')";
alter database open resetlogs;
基于scn号：
startup mount;
restore database until scn 888；
recover database until scn 888；
alter database open resetlogs;
基于归档日志序列号:
startup mount;
restore database until sequence 123 thread 1；
recover database until sequence 123 thread 1；
alter database open resetlogs;
1.2 RMAN-20207报错，使用list incarnation解决一例。
RMAN-20207: UNTIL TIME or RECOVERY WINDOW is before RESETLOGS time错误的解决办法如下：
我们在做RMAN恢复的时候，可以使用list incarnation 命令查看控制文件包含了哪些对应物。
当在做Media Recover的不完全恢复时，通过resetlogs打开库，则Incarnation（数据库对应物）表示这个数据库的特定的逻辑生存期。
DBA可能有时需要这样的恢复：需要使用上次执行resetlogs命令打开数据库前生成的一个备份来进行还原数据库，或者可能需要还原到执行上一个resetlogs命令之前的时间点。
比如下面的操作是将数据库恢复到2014年6月16日的状态。
因为我们没有使用catalog。所以我们先恢复控制文件。
RMAN> restore controlfile from '/db_backup/AJU_POST_CLONE/AJU_POST_BP23_EXP90/pajup/backupset_103_PAJUP_37pb14rh';
Starting restore at 21-JUL-14
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=242 device type=DISK
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
output file name=+DATA/pajup/control01.ctl
output file name=+DATA/pajup/control02.ctl
output file name=+DATA/pajup/control03.ctl
Finished restore at 21-JUL-14
准备恢复数据库
RMAN> alter database mount;
database mounted
released channel: ORA_DISK_1
RMAN> run {
2> restore database;
3> set until time "to_date('Jun 16 2014 23:21:00','Mon DD YYYY HH24:MI:SS')";
4> recover database;
alter database open resetlogs;
}
下面这些是restore的过程。
Starting restore at 21-JUL-14
Starting implicit crosscheck backup at 21-JUL-14
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=242 device type=DISK
Crosschecked 72 objects
Finished implicit crosscheck backup at 21-JUL-14
Starting implicit crosscheck copy at 21-JUL-14
using channel ORA_DISK_1
Finished implicit crosscheck copy at 21-JUL-14
searching for all files in the recovery area
cataloging files...
cataloging done
List of Cataloged Files
=======================
File Name: +reco/pajup/ARCHIVELOG/2014_07_21/thread_2_seq_8.410521.853479197
File Name: +reco/pajup/ARCHIVELOG/2014_07_21/thread_1_seq_9.410522.853479197
File Name: +reco/pajup/ARCHIVELOG/2014_07_21/thread_1_seq_10.410523.853479215
File Name: +reco/pajup/ARCHIVELOG/2014_07_21/thread_1_seq_11.410576.853482583
File Name: +reco/pajup/ARCHIVELOG/2014_07_19/thread_1_seq_8.408628.853351343
File Name: +reco/pajup/ARCHIVELOG/2014_07_17/thread_2_seq_7.405955.853179347
File Name: +reco/pajup/ARCHIVELOG/2014_07_13/thread_1_seq_7.398318.852836481
File Name: +reco/pajup/ARCHIVELOG/2014_07_07/thread_2_seq_6.386816.852292813
File Name: +reco/pajup/ARCHIVELOG/2014_07_07/thread_1_seq_6.387446.852321621
File Name: +reco/pajup/ARCHIVELOG/2014_07_02/thread_1_seq_5.370578.851823445
File Name: +reco/pajup/ARCHIVELOG/2014_06_26/thread_2_seq_4.201949.851231251
File Name: +reco/pajup/ARCHIVELOG/2014_06_26/thread_1_seq_3.362093.851231251
File Name: +reco/pajup/ARCHIVELOG/2014_06_26/thread_1_seq_4.201943.851231313
File Name: +reco/pajup/ARCHIVELOG/2014_06_26/thread_2_seq_5.201969.851231313
File Name: +reco/pajup/ARCHIVELOG/2014_06_25/thread_1_seq_13.336310.851135615
File Name: +reco/pajup/ARCHIVELOG/2014_06_25/thread_1_seq_14.313117.851135615
File Name: +reco/pajup/ARCHIVELOG/2014_06_25/thread_1_seq_12.313662.851135629
File Name: +reco/pajup/ARCHIVELOG/2014_06_25/thread_2_seq_10.336295.851135629
File Name: +reco/pajup/ARCHIVELOG/2014_06_25/thread_2_seq_11.313730.851135633
File Name: +reco/pajup/ARCHIVELOG/2014_06_25/thread_2_seq_9.336277.851135633
File Name: +reco/pajup/ARCHIVELOG/2014_06_25/thread_2_seq_1.313806.851135651
File Name: +reco/pajup/ARCHIVELOG/2014_06_25/thread_2_seq_2.244417.851199885
File Name: +reco/pajup/ARCHIVELOG/2014_06_25/thread_1_seq_1.244552.851199885
File Name: +reco/pajup/ARCHIVELOG/2014_06_25/thread_1_seq_2.359503.851199943
File Name: +reco/pajup/ARCHIVELOG/2014_06_25/thread_2_seq_3.245263.851199945
File Name: +reco/pajup/ARCHIVELOG/2014_06_24/thread_2_seq_10.361501.851124225
File Name: +reco/pajup/ARCHIVELOG/2014_06_23/thread_1_seq_10.368614.850989033
File Name: +reco/pajup/ARCHIVELOG/2014_06_23/thread_1_seq_11.368758.850989567
File Name: +reco/pajup/ARCHIVELOG/2014_06_23/thread_1_seq_12.368840.850990925
File Name: +reco/pajup/ARCHIVELOG/2014_06_23/thread_2_seq_8.368841.850990927
File Name: +reco/pajup/ARCHIVELOG/2014_06_23/thread_1_seq_13.368842.850990985
File Name: +reco/pajup/ARCHIVELOG/2014_06_23/thread_2_seq_9.368843.850990985
File Name: +reco/pajup/ARCHIVELOG/2014_06_21/thread_2_seq_5.364394.850786171
File Name: +reco/pajup/ARCHIVELOG/2014_06_21/thread_2_seq_6.364405.850786185
File Name: +reco/pajup/ARCHIVELOG/2014_06_21/thread_2_seq_7.364406.850786185
File Name: +reco/pajup/ARCHIVELOG/2014_06_21/thread_1_seq_9.364407.850786187
File Name: +reco/pajup/ARCHIVELOG/2014_06_20/thread_1_seq_7.364188.850780167
File Name: +reco/pajup/ARCHIVELOG/2014_06_20/thread_1_seq_8.364176.850780547
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00003 to +DATA/pajup/datafile/undotbs01.dbf
channel ORA_DISK_1: restoring datafile 00007 to +DATA/pajup/datafile/fa_oam.dbf
channel ORA_DISK_1: restoring datafile 00008 to +DATA/pajup/datafile/fa_iassdpm.dbf
channel ORA_DISK_1: restoring datafile 00012 to +DATA/pajup/datafile/fa_oimlob.dbf
channel ORA_DISK_1: reading from backup piece /db_backup/AJU_BACKUP/POST_REL8FA_UPG/pajup/backupset_79_PAJUP_2fp8rnnk
channel ORA_DISK_1: piece handle=/db_backup/AJU_BACKUP/POST_REL8FA_UPG/pajup/backupset_79_PAJUP_2fp8rnnk tag=FULL_ARCHIVE_TO_NFS
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:26
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00005 to +DATA/pajup/datafile/example01.dbf
channel ORA_DISK_1: restoring datafile 00010 to +DATA/pajup/datafile/fa_ias_iau.dbf
channel ORA_DISK_1: restoring datafile 00011 to +DATA/pajup/datafile/fa_oim.dbf
channel ORA_DISK_1: restoring datafile 00015 to +DATA/pajup/datafile/rman_data_1_tbs.3263.839401565
channel ORA_DISK_1: reading from backup piece /db_backup/AJU_BACKUP/POST_REL8FA_UPG/pajup/backupset_78_PAJUP_2ep8rnnk
channel ORA_DISK_1: piece handle=/db_backup/AJU_BACKUP/POST_REL8FA_UPG/pajup/backupset_78_PAJUP_2ep8rnnk tag=FULL_ARCHIVE_TO_NFS
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:35
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00001 to +DATA/pajup/datafile/system01.dbf
channel ORA_DISK_1: restoring datafile 00006 to +DATA/pajup/datafile/fa_iasoif.dbf
channel ORA_DISK_1: restoring datafile 00013 to +DATA/pajup/datafile/fa_soainfra.dbf
channel ORA_DISK_1: restoring datafile 00014 to +DATA/pajup/datafile/undotbs2.dbf
channel ORA_DISK_1: reading from backup piece /db_backup/AJU_BACKUP/POST_REL8FA_UPG/pajup/backupset_80_PAJUP_2gp8rnnl
channel ORA_DISK_1: piece handle=/db_backup/AJU_BACKUP/POST_REL8FA_UPG/pajup/backupset_80_PAJUP_2gp8rnnl tag=FULL_ARCHIVE_TO_NFS
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:45
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00002 to +DATA/pajup/datafile/sysaux01.dbf
channel ORA_DISK_1: restoring datafile 00004 to +DATA/pajup/datafile/users01.dbf
channel ORA_DISK_1: restoring datafile 00009 to +DATA/pajup/datafile/fa_mds.dbf
channel ORA_DISK_1: reading from backup piece /db_backup/AJU_BACKUP/POST_REL8FA_UPG/pajup/backupset_77_PAJUP_2dp8rnnk
channel ORA_DISK_1: piece handle=/db_backup/AJU_BACKUP/POST_REL8FA_UPG/pajup/backupset_77_PAJUP_2dp8rnnk tag=FULL_ARCHIVE_TO_NFS
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:55
Finished restore at 21-JUL-14
executing command: SET until clause
Starting recover at 21-JUL-14
using channel ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 07/21/2014 07:13:24
RMAN-20207: UNTIL TIME or RECOVERY WINDOW is before RESETLOGS time
这是准备recovery时比较常见的一个错误信息。通常我们可以通过下面的办法来解决。
RMAN> list incarnation;
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1 1 PAJUP 2941400143 PARENT 1383125 29-JUL-13
2 2 PAJUP 2941400143 PARENT 32325998 13-FEB-14
4 4 PAJUP 2941400143 PARENT 34279940 11-APR-14
3 3 PAJUP 2941400143 ORPHAN 34279997 20-FEB-14
5 5 PAJUP 2941400143 PARENT 36067904 22-APR-14
8 8 PAJUP 2941400143 PARENT 43039998 16-JUN-14
9 9 PAJUP 2941400143 CURRENT 44911476 25-JUN-14
7 7 PAJUP 2941400143 ORPHAN 45126273 04-JUN-14
6 6 PAJUP 2941400143 ORPHAN 45404604 06-JUN-14
RMAN> reset database to incarnation 8;
database reset to incarnation 8
RMAN> run {
2> restore database;
3> set until time "to_date('Jun 16 2014 23:21:26','Mon DD YYYY HH24:MI:SS')";
4> recover database;
alter database open resetlogs;
} 5> 6>
Starting restore at 21-JUL-14
using channel ORA_DISK_1
skipping datafile 1; already restored to file +DATA/pajup/datafile/system01.dbf
skipping datafile 6; already restored to file +DATA/pajup/datafile/fa_iasoif.dbf
skipping datafile 13; already restored to file +DATA/pajup/datafile/fa_soainfra.dbf
skipping datafile 14; already restored to file +DATA/pajup/datafile/undotbs2.dbf
skipping datafile 2; already restored to file +DATA/pajup/datafile/sysaux01.dbf
skipping datafile 4; already restored to file +DATA/pajup/datafile/users01.dbf
skipping datafile 9; already restored to file +DATA/pajup/datafile/fa_mds.dbf
skipping datafile 3; already restored to file +DATA/pajup/datafile/undotbs01.dbf
skipping datafile 7; already restored to file +DATA/pajup/datafile/fa_oam.dbf
skipping datafile 8; already restored to file +DATA/pajup/datafile/fa_iassdpm.dbf
skipping datafile 12; already restored to file +DATA/pajup/datafile/fa_oimlob.dbf
skipping datafile 5; already restored to file +DATA/pajup/datafile/example01.dbf
skipping datafile 10; already restored to file +DATA/pajup/datafile/fa_ias_iau.dbf
skipping datafile 11; already restored to file +DATA/pajup/datafile/fa_oim.dbf
skipping datafile 15; already restored to file +DATA/pajup/datafile/rman_data_1_tbs.3263.839401565
restore not done; all files read only, offline, or already restored
Finished restore at 21-JUL-14
executing command: SET until clause
Starting recover at 21-JUL-14
using channel ORA_DISK_1
starting media recovery
archived log for thread 1 with sequence 13 is already on disk as file +RECO/pajup/archivelog/2014_05_21/thread_1_seq_13.327534.848158501
archived log for thread 2 with sequence 9 is already on disk as file +RECO/pajup/archivelog/2014_05_21/thread_2_seq_9.327535.848158501
archived log for thread 1 with sequence 1 is already on disk as file +RECO/pajup/archivelog/2014_06_16/thread_1_seq_1.358127.850419155
archived log for thread 1 with sequence 2 is already on disk as file +RECO/pajup/archivelog/2014_06_16/thread_1_seq_2.358128.850419159
archived log for thread 1 with sequence 3 is already on disk as file +RECO/pajup/archivelog/2014_06_16/thread_1_seq_3.358331.850429549
archived log for thread 1 with sequence 4 is already on disk as file +RECO/pajup/archivelog/2014_06_16/thread_1_seq_4.358332.850429567
archived log for thread 1 with sequence 5 is already on disk as file +RECO/pajup/archivelog/2014_06_16/thread_1_seq_5.358553.850432819
archived log for thread 1 with sequence 6 is already on disk as file +RECO/pajup/archivelog/2014_06_16/thread_1_seq_6.358556.850432877
archived log for thread 1 with sequence 7 is already on disk as file +RECO/pajup/archivelog/2014_06_20/thread_1_seq_7.364188.850780167
archived log for thread 2 with sequence 1 is already on disk as file +RECO/pajup/archivelog/2014_06_16/thread_2_seq_1.358123.850419045
archived log for thread 2 with sequence 2 is already on disk as file +RECO/pajup/archivelog/2014_06_16/thread_2_seq_2.358201.850425435
archived log for thread 2 with sequence 3 is already on disk as file +RECO/pajup/archivelog/2014_06_16/thread_2_seq_3.358554.850432821
archived log for thread 2 with sequence 4 is already on disk as file +RECO/pajup/archivelog/2014_06_16/thread_2_seq_4.358557.850432877
archived log for thread 2 with sequence 5 is already on disk as file +RECO/pajup/archivelog/2014_06_21/thread_2_seq_5.364394.850786171
archived log file name=+RECO/pajup/archivelog/2014_05_21/thread_1_seq_13.327534.848158501 thread=1 sequence=13
archived log file name=+RECO/pajup/archivelog/2014_05_21/thread_2_seq_9.327535.848158501 thread=2 sequence=9
archived log file name=+RECO/pajup/archivelog/2014_06_16/thread_1_seq_1.358127.850419155 thread=1 sequence=1
archived log file name=+RECO/pajup/archivelog/2014_06_16/thread_2_seq_1.358123.850419045 thread=2 sequence=1
archived log file name=+RECO/pajup/archivelog/2014_06_16/thread_1_seq_2.358128.850419159 thread=1 sequence=2
archived log file name=+RECO/pajup/archivelog/2014_06_16/thread_2_seq_2.358201.850425435 thread=2 sequence=2
archived log file name=+RECO/pajup/archivelog/2014_06_16/thread_1_seq_3.358331.850429549 thread=1 sequence=3
archived log file name=+RECO/pajup/archivelog/2014_06_16/thread_1_seq_4.358332.850429567 thread=1 sequence=4
archived log file name=+RECO/pajup/archivelog/2014_06_16/thread_2_seq_3.358554.850432821 thread=2 sequence=3
archived log file name=+RECO/pajup/archivelog/2014_06_16/thread_1_seq_5.358553.850432819 thread=1 sequence=5
archived log file name=+RECO/pajup/archivelog/2014_06_16/thread_1_seq_6.358556.850432877 thread=1 sequence=6
archived log file name=+RECO/pajup/archivelog/2014_06_16/thread_2_seq_4.358557.850432877 thread=2 sequence=4
archived log file name=+RECO/pajup/archivelog/2014_06_20/thread_1_seq_7.364188.850780167 thread=1 sequence=7
archived log file name=+RECO/pajup/archivelog/2014_06_21/thread_2_seq_5.364394.850786171 thread=2 sequence=5
media recovery complete, elapsed time: 00:00:23
Finished recover at 21-JUL-14
database opened
检查一下恢复的结果。
RMAN> validate database check logical;
Starting validate at 21-JUL-14
using channel ORA_DISK_1
channel ORA_DISK_1: starting validation of datafile
channel ORA_DISK_1: specifying datafile(s) for validation
input datafile file number=00002 name=+DATA/pajup/datafile/sysaux01.dbf
input datafile file number=00011 name=+DATA/pajup/datafile/fa_oim.dbf
input datafile file number=00001 name=+DATA/pajup/datafile/system01.dbf
input datafile file number=00003 name=+DATA/pajup/datafile/undotbs01.dbf
input datafile file number=00012 name=+DATA/pajup/datafile/fa_oimlob.dbf
input datafile file number=00014 name=+DATA/pajup/datafile/undotbs2.dbf
input datafile file number=00005 name=+DATA/pajup/datafile/example01.dbf
input datafile file number=00008 name=+DATA/pajup/datafile/fa_iassdpm.dbf
input datafile file number=00013 name=+DATA/pajup/datafile/fa_soainfra.dbf
input datafile file number=00015 name=+DATA/pajup/datafile/rman_data_1_tbs.3263.839401565
input datafile file number=00009 name=+DATA/pajup/datafile/fa_mds.dbf
input datafile file number=00007 name=+DATA/pajup/datafile/fa_oam.dbf
input datafile file number=00006 name=+DATA/pajup/datafile/fa_iasoif.dbf
input datafile file number=00010 name=+DATA/pajup/datafile/fa_ias_iau.dbf
input datafile file number=00004 name=+DATA/pajup/datafile/users01.dbf
channel ORA_DISK_1: validation complete, elapsed time: 00:00:15
List of Datafiles
=================
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
1 OK 0 12976 98617 43263327
File Name: +DATA/pajup/datafile/system01.dbf
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data 0 64570
Index 0 14789
Other 0 6225
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
2 OK 0 18614 185673 43263403
File Name: +DATA/pajup/datafile/sysaux01.dbf
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data 0 57085
Index 0 53422
Other 0 56479
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
3 OK 0 1 74252 43263402
File Name: +DATA/pajup/datafile/undotbs01.dbf
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data 0 0
Index 0 0
Other 0 74239
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
4 OK 0 18 667 1540593
File Name: +DATA/pajup/datafile/users01.dbf
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data 0 91
Index 0 39
Other 0 492
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
5 OK 2179 31362 44244 43237510
File Name: +DATA/pajup/datafile/example01.dbf
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data 0 4418
Index 0 1148
Other 0 7312
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
6 OK 0 37 7682 1190254
File Name: +DATA/pajup/datafile/fa_iasoif.dbf
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data 0 5
Index 0 14
Other 0 7624
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
7 OK 0 337 12815 43242072
File Name: +DATA/pajup/datafile/fa_oam.dbf
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data 0 2194
Index 0 1887
Other 0 8382
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
8 OK 0 358 38412 42846314
File Name: +DATA/pajup/datafile/fa_iassdpm.dbf
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data 0 121
Index 0 71
Other 0 37850
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
9 OK 0 6449 19219 43241292
File Name: +DATA/pajup/datafile/fa_mds.dbf
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data 0 1766
Index 0 4339
Other 0 6646
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
10 OK 0 49 7681 1104562
File Name: +DATA/pajup/datafile/fa_ias_iau.dbf
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data 0 38
Index 0 28
Other 0 7565
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
11 OK 2834 7482 115201 43243571
File Name: +DATA/pajup/datafile/fa_oim.dbf
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data 0 49738
Index 0 16023
Other 0 41957
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
12 OK 0 2111 64002 43038970
File Name: +DATA/pajup/datafile/fa_oimlob.dbf
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data 0 0
Index 0 876
Other 0 61013
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
13 OK 0 542 25601 43038980
File Name: +DATA/pajup/datafile/fa_soainfra.dbf
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data 0 188
Index 0 85
Other 0 24785
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
14 OK 0 1 53362 43260164
File Name: +DATA/pajup/datafile/undotbs2.dbf
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data 0 0
Index 0 0
Other 0 53359
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
15 OK 0 1 25601 1638736
File Name: +DATA/pajup/datafile/rman_data_1_tbs.3263.839401565
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data 0 0
Index 0 0
Other 0 25599
channel ORA_DISK_1: starting validation of datafile
channel ORA_DISK_1: specifying datafile(s) for validation
including current control file for validation
including current SPFILE in backup set
channel ORA_DISK_1: validation complete, elapsed time: 00:00:01
List of Control File and SPFILE
===============================
File Type Status Blocks Failing Blocks Examined
------------ ------ -------------- ---------------
SPFILE OK 0 2
Control File OK 0 614
Finished validate at 21-JUL-14
RMAN> exit
1.3 增量数据库恢复
1.3.1 ORA-19909: datafile 1 belongs to an orphan incarnation 一例
ORA-19909: datafile 1 belongs to an orphan incarnation
SQL> startup mount;
ORACLE instance started.
Total System Global Area 6847938560 bytes
Fixed Size 2219808 bytes
Variable Size 3539992800 bytes
Database Buffers 3288334336 bytes
Redo Buffers 17391616 bytes
Database mounted.
SQL> recover database using backup controlfile;
ORA-00283: recovery session canceled due to errors
ORA-19909: datafile 1 belongs to an orphan incarnation
ORA-01110: data file 1: '/u01/app/oracle/oradata/orcl/system01.dbf'
Cause & Background information
The standby database has been activated previously but since then reverted back into its standby role. Prior to the RMAN duplicate operation the "alter system reset control_files scope=spfile sid='*';" has not been executed (i.e. the control files have not been overwritten).
Analysis
Primary and standby have different incarnations:
在我的实验中，实验数据库是利用RMAN duplicate 生成的，猜想可能是这个原因造成的。
$ rman target /
Recovery Manager: Release 11.2.0.1.0 - Production on Wed Apr 13 15:33:18 2011
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
connected to target database: ORCL (DBID=1276064171, not open)
RMAN> list incarnation of database;
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- -------- ---------------- --- ---------- ----------
2 2 ORCL 1276064171 CURRENT 979911 12-APR-11
1 1 ORCL 1276064171 ORPHAN 1094407 12-APR-11
RMAN> reset database to incarnation 1;
database reset to incarnation 1
RMAN> list incarnation of database;
using target database control file instead of recovery catalog
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- -------- ---------------- --- ---------- ----------
2 2 ORCL 1276064171 PARENT 979911 12-APR-11
1 1 ORCL 1276064171 CURRENT 1094407 12-APR-11
RMAN> exit
Recovery Manager complete.
SQL> recover database using backup controlfile; --再次执行，问题已经解决
ORA-00279: change 1181302 generated at 04/13/2011 02:13:32 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2011_04_13/o1_mf_1_7_%u_.arc
ORA-00280: change 1181302 for thread 1 is in sequence #7
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/u01/app/oracle/oradata/orcl/redo01.log
ORA-00283: recovery session canceled due to errors
ORA-01244: unnamed datafile(s) added to control file by media recovery
ORA-01110: data file 6: '/u01/app/oracle/oradata/orcl/app01.dbf'
ORA-01112: media recovery not started
SQL> col error for a18
SQL> select * from v$recover_file;
FILE# ONLINE ONLINE_ ERROR CHANGE# TIME
---------- ------- ------- ------------------ ---------- ---------
6 ONLINE ONLINE FILE MISSING 0
SQL> col name for a50
SQL> select file#,name from v$datafile;
FILE# NAME
---------- --------------------------------------------------
1 /u01/app/oracle/oradata/orcl/system01.dbf
2 /u01/app/oracle/oradata/orcl/sysaux01.dbf
3 /u01/app/oracle/oradata/orcl/undotbs01.dbf
4 /u01/app/oracle/oradata/orcl/users01.dbf
5 /u01/app/oracle/oradata/orcl/example01.dbf
6 /u01/app/oracle/product/11.2.0/db_1/dbs/UNNAMED000
06
6 rows selected.
SQL> alter database rename file '/u01/app/oracle/product/11.2.0/db_1/dbs/UNNAMED00006' to '/u01/app/oracle/oradata/orcl/app01.dbf';
Database altered.
SQL> select file#,name from v$datafile;
FILE# NAME
---------- --------------------------------------------------
1 /u01/app/oracle/oradata/orcl/system01.dbf
2 /u01/app/oracle/oradata/orcl/sysaux01.dbf
3 /u01/app/oracle/oradata/orcl/undotbs01.dbf
4 /u01/app/oracle/oradata/orcl/users01.dbf
5 /u01/app/oracle/oradata/orcl/example01.dbf
6 /u01/app/oracle/oradata/orcl/app01.dbf
6 rows selected.
SQL> recover database using backup controlfile;
ORA-00279: change 1181454 generated at 04/13/2011 02:14:58 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2011_04_13/o1_mf_1_7_%u_.arc
ORA-00280: change 1181454 for thread 1 is in sequence #7
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/u01/app/oracle/oradata/orcl/redo01.log
Log applied.
Media recovery complete.
SQL> alter database open resetlogs;
Database altered.
到此成功恢复。
ORA-19909 参考：
http://blog.csdn.net/leishifei/archive/2011/04/13/6320926.aspx
1.3.2 记一次 ORA-01206: file is not part of this database - wrong database id
在primary DB RMAN DUPLICATE方式创建好STANDBY DATABASE后，在启用日志应用的时候发现后台报如下错误：
DBW0 started with pid=5, OS id=3142
LGWR started with pid=6, OS id=3144
CKPT started with pid=7, OS id=3146
SMON started with pid=8, OS id=3148
RECO started with pid=9, OS id=3150
CJQ0 started with pid=10, OS id=3152
MMON started with pid=11, OS id=3154
Sat Feb 12 21:26:34 2011
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
MMNL started with pid=12, OS id=3156
Sat Feb 12 21:26:34 2011
starting up 1 shared server(s) ...
Sat Feb 12 21:26:35 2011
ALTER DATABASE MOUNT
Sat Feb 12 21:26:39 2011
Setting recovery target incarnation to 3
ARCH: STARTING ARCH PROCESSES
ARC0 started with pid=16, OS id=3163
Sat Feb 12 21:26:39 2011
ARC0: Archival started
ARC1: Archival started
ARCH: STARTING ARCH PROCESSES COMPLETE
Sat Feb 12 21:26:39 2011
ARC0: Becoming the 'no FAL' ARCH
ARC0: Becoming the 'no SRL' ARCH
ARC0: Thread not mounted
ARC1 started with pid=17, OS id=3165
ARC1: Becoming the heartbeat ARCH
ARC1: Thread not mounted
Sat Feb 12 21:26:39 2011
Successful mount of redo thread 1, with mount id 574531083
Sat Feb 12 21:26:39 2011
Physical Standby Database mounted.
Completed: ALTER DATABASE MOUNT
Sat Feb 12 21:27:24 2011
alter database recover managed standby database disconnect from session
Sat Feb 12 21:27:24 2011
Attempt to start background Managed Standby Recovery process (qqdb)
MRP0 started with pid=18, OS id=3171
Sat Feb 12 21:27:24 2011
MRP0: Background Managed Standby Recovery process started (qqdb)
Managed Standby Recovery not using Real Time Apply
MRP0: Background Media Recovery terminated with error 1110
Sat Feb 12 21:27:29 2011
Errors in file /u01/admin/qqdb/bdump/qqdb_mrp0_3171.trc:
ORA-01110: data file 1: '/u01/oradata/qqdb/system01.dbf'
ORA-01122: database file 1 failed verification check
ORA-01110: data file 1: '/u01/oradata/qqdb/system01.dbf'
ORA-01206: file is not part of this database - wrong database id
Sat Feb 12 21:27:29 2011
Errors in file /u01/admin/qqdb/bdump/qqdb_mrp0_3171.trc:
ORA-01110: data file 1: '/u01/oradata/qqdb/system01.dbf'
ORA-01122: database file 1 failed verification check
ORA-01110: data file 1: '/u01/oradata/qqdb/system01.dbf'
ORA-01206: file is not part of this database - wrong database id
Sat Feb 12 21:27:29 2011
MRP0: Background Media Recovery process shutdown (qqdb)
经过对问题的分析以及查阅以下文档：
http://www.pythian.com/news/512/ora-01206-file-is-not-part-of-this-database-wrong-database-id/
Pythian is hiring the best and brightest at all levels across all practices: Oracle DBAs & Apps DBAs, MySQL DBAs, SQL Server DBAs, and Systems Admins. If you want a job experience like this then submit your candidacy here.
ORA-01206: file is not part of this database – wrong database id
Posted by Alex Gorbachev on Jun 15, 2007
This was posted yesterday on Oracle-L by Li Li. I feel I should blog about it to spread the word, especially since not everyone in this world performs test-restores.
Li was executing a test-restore and hit a problem at the end of the point-in-time recovery phase:
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error belowORA-01122: database file 9 failed verification checkORA-01110: data file 9: 'H:xxxxxxxxx.dbf'ORA-01206: file is not part of this database - wrong database id
Datafile 9 was a read-only tablespace, and the source database was actually created with RMAN DUPLICATE. Datafile 9 was read-only during that duplicate operation, and the status hadn’t changed since then. As you can imagine, the read-only datafiles were not changed and their headers still contained the DBID of the database that was the source of the RMAN DUPLICATE. A similar situation could probably happen if tablespaces were imported using transportable tablespaces feature, and left read only.
The fix in this case is to make tablespaces read-write for a moment, and then change back to read-only. The read-write operation will write new datafile headers and, consequently, put there the “right” DBID. IMPORTANT — this has to be done before backup and not after a disaster strikes. This case just emphasizes again the most important rule of any backup/recovery strategy is to do regular test-restores.
If it’s too late and something hit the fan — well, you probably have a chance to offline drop those tablespaces and, hopefully, be able to import them back, if those are transportable tablespaces, and the metadata dump file is still available.
Another idea would be to offline datafiles and then online them after OPEN RESETLOGS. Should someone try that — let us know if it works
最终解决方式：对standby database做一次完整恢复：
RMAN> restore database;
Starting restore at 12-FEB-11
Starting implicit crosscheck backup at 12-FEB-11
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=153 devtype=DISK
Crosschecked 3 objects
Finished implicit crosscheck backup at 12-FEB-11
Starting implicit crosscheck copy at 12-FEB-11
using channel ORA_DISK_1
Finished implicit crosscheck copy at 12-FEB-11
searching for all files in the recovery area
cataloging files...
no files cataloged
using channel ORA_DISK_1
datafile 5 not processed because file is read-only
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00001 to /u01/oradata/qqdb/system01.dbf
restoring datafile 00002 to /u01/oradata/qqdb/undotbs01.dbf
restoring datafile 00003 to /u01/oradata/qqdb/sysaux01.dbf
restoring datafile 00004 to /u01/oradata/qqdb/users01.dbf
restoring datafile 00006 to /u01/oradata/qqdb/test_tran01.dbf
channel ORA_DISK_1: reading from backup piece /u01/flash_recovery_area/QQDB/backupset/2011_02_12/o1_mf_nnndf_TAG20110212T201720_6odylk88_.bkp
channel ORA_DISK_1: restored backup piece 1
piece handle=/u01/flash_recovery_area/QQDB/backupset/2011_02_12/o1_mf_nnndf_TAG20110212T201720_6odylk88_.bkp tag=TAG20110212T201720
channel ORA_DISK_1: restore complete, elapsed time: 00:01:06
Finished restore at 12-FEB-11
RMAN> recover database;
Starting recover at 12-FEB-11
using channel ORA_DISK_1
datafile 5 not processed because file is read-only
starting media recovery
channel ORA_DISK_1: starting archive log restore to default destination
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=26
channel ORA_DISK_1: reading from backup piece /u01/flash_recovery_area/QQDB/backupset/2011_02_12/o1_mf_annnn_TAG20110212T201839_6odyo0wf_.bkp
channel ORA_DISK_1: restored backup piece 1
piece handle=/u01/flash_recovery_area/QQDB/backupset/2011_02_12/o1_mf_annnn_TAG20110212T201839_6odyo0wf_.bkp tag=TAG20110212T201839
channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
archive log filename=/u01/flash_recovery_area/QQDB/1_26_736032558.dbf thread=1 sequence=26
unable to find archive log
archive log thread=1 sequence=27
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 02/12/2011 21:34:34
RMAN-06054: media recovery requesting unknown log: thread 1 seq 27 lowscn 11338164342448
将sequence为27的日志拷贝过来继续恢复：
RMAN> recover database;
Starting recover at 12-FEB-11
using channel ORA_DISK_1
datafile 5 not processed because file is read-only
starting media recovery
archive log filename=/u01/flash_recovery_area/QQDB/1_27_736032558.dbf thread=1 sequence=27
archive log filename=/u01/flash_recovery_area/QQDB/1_27_736032558.dbf thread=1 sequence=28
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 02/12/2011 21:35:38
RMAN-11003: failure during parse/execution of SQL statement: alter database recover logfile '/u01/flash_recovery_area/QQDB/1_27_736032558.dbf'
ORA-00310: archived log contains sequence 27; sequence 28 required
ORA-00334: archived log: '/u01/flash_recovery_area/QQDB/1_27_736032558.dbf'
RMAN> recover database until sequence 28;
Starting recover at 12-FEB-11
using channel ORA_DISK_1
datafile 5 not processed because file is read-only
starting media recovery
media recovery complete, elapsed time: 00:00:03
Finished recover at 12-FEB-11
RMAN> exit
[oracle@localhost ~]$ sqlplus / as sysdba
SQL*Plus: Release 10.2.0.1.0 - Production on Sat Feb 12 21:37:05 2011
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options
SQL> select status from v$instance;
STATUS
------------
MOUNTED
SQL> alter database open;
Database altered.
SQL> startup mount;
ORA-01081: cannot start already-running ORACLE - shut it down first
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount;
ORACLE instance started.
Total System Global Area 243269632 bytes
Fixed Size 2019864 bytes
Variable Size 83889640 bytes
Database Buffers 150994944 bytes
Redo Buffers 6365184 bytes
Database mounted.
SQL> alter database recover managed standby database disconnect from session;
Database altered.
SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
--------------
27
问题解决。。
解决思路：
问题并不重要，重要的是解决问题的思路及问题定位，查找出主要的问题点进行解决！
1.3.3 crosscheck archivelog all error ORA-19587
前两天同事打电话来说在一个有catalog库的数据库中，做crosscheck时候报错：
ORA-19587: error occurred reading 512 bytes at block number 1
ORA-27091: skgfqio: unable to queue I/O
ORA-27072: skgfdisp: I/O error
SVR4 Error: 2: No such file or directory
Additional information: 1
开始怀疑是系统目录或者文件出问题了，经过检查没有发现异常，目录可读可写，归档文件也都在，后经查找metalink，说明如下：
RMAN CROSSCHECK ARCHIVELOG ALL fails: Ora-19587: Error Occurred Reading 1024 Bytes At Block Number 1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of crosscheck command on ORA_MAINT_DISK_1 channel at
06/29/2006 18:45:56
ORA-19587: error occurred reading 1024 bytes at block number 1
ORA-27091: unable to queue I/O
ORA-27069: attempt to do I/O beyond the range of the file
CauseOne of the archivelogs is not the expected size.
You can confirm this by checking by getting a debug trace:
rman target / trace rman.trc debug
RMAN>crosscheck archivelog all;
Trace file is generated in target udump directory and shows:
DBGPLSQL: channel ORA_MAINT_DISK_1: processing (file/handle=
/odsprd/archive2/log_2_25283_550106137.arc,recid=81233, old_status=A,
hdl_isdisk=0, devicetype=DISK) (change)
DBGPLSQL: channel ORA_MAINT_DISK_1: force: 0 (change)
DBGRPC: krmxrpc: xc=6917529027646298352 kpurpc2 rc=19587 db=target proc=
DBMS_BACKUP_RESTORE.VALIDATEARCHIVEDLOG
DBGRPC: krmxrpc: xc=6917529027646298352 chid=ORA_MAINT_DISK_1 increment rpc
count=21
DBGMISC: krmqexe: unhandled exception on channel ORA_MAINT_DISK_1
So the problem log is:
/odsprd/archive2/log_2_25283_550106137.arc and checking the physical file we find it is zeo bytes in length.
.SolutionDelete the log using an OS command and run the crosscheck again.
解决方法就是：打开rman trace找到一个异常大小的归档文件，删除该归档文件，然后try again即可。
1.4 其他错误
1.4.1 RMAN-06172: no AUTOBACKUP found or specified handle is not a valid copy or piece
恢复过程出现RMAN-06172: no AUTOBACKUP found or specified handle is not a valid copy or piece，下面我们来详细地讨论一下这个错误产生的原因和解决的方法。
我们把错误再次贴出来：
RMAN> restore spfile from autobackup;
Starting restore at 16-AUG-14
using channel ORA_DISK_1
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20140816
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20140815
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20140814
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20140813
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20140812
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20140811
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20140810
channel ORA_DISK_1: no AUTOBACKUP in 7 days found
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 08/16/2014 03:39:24
RMAN-06172: no AUTOBACKUP found or specified handle is not a valid copy or piece
（1）rman中没有配置configure controlfile autobackup on;
RMAN> show all;
RMAN configuration parameters for database with db_unique_name DUMMY 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 1 BACKUP TYPE TO BACKUPSET; # default
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 COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE ; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
这是自动备份控制文件和参数文件的开关，如果没有打开的话，那么就不可能产生自动备份。
（2）rman默认查找7天内的备份，如果7天之内没有发生自动备份，那么rman也将无法找到自动备份。
遇到这种情况一般有两种解决方式：
①restore spfile from autobackup until time 'SYSDATE-N';
②restore spfile from autobackup maxdays N;
③restore spfile from '/u01/app/oracle/flash_recovery_area/ORCL/autobackup/2014_08_16/o1_mf_s_855716497_9yyc01qb_.bkp'; 如果这个语句报错的话，就检查是否备份集的owner不是oracle用户（chown oracle:oinstall LIHUARONG/*）
（3）第三种情况就是上篇试验中遇到的。由于autobackup的默认设置发生了变化，也就是说，原来我们已经设置了
configure controlfile autobackup on;但是再重新使用rman进行spfile的恢复时，这个设置已经变成了off了。这种情况
在错误中不会提示，所以较难发现。出现这种情况是由于目前数据库只是通过rman的默认设置启动，而且处在nomount
状态。解决的方法是找到自动备份的路径，直接将路径告诉rman。
RMAN> restore spfile from '/u01/app/oracle/flash_recovery_area/ORCL/autobackup/2014_08_16
2> /o1_mf_s_855716497_9yyc01qb_.bkp
3> ';
Starting restore at 16-AUG-14
using channel ORA_DISK_1
channel ORA_DISK_1: restoring spfile from AUTOBACKUP /u01/app/oracle/flash_recovery_area/ORCL/autobackup/2014_08_16/o1_mf_s_855716497_9yyc01qb_.bkp
channel ORA_DISK_1: SPFILE restore from AUTOBACKUP complete
Finished restore at 16-AUG-14
1.4.2 RMAN-00554 RMAN-04005 ORA-12528
RMAN在使用recover catalog的情况下在nomount状态连接实例出现以下错误信息：
RMAN-00554: initialization of internal recovery manager package failedRMAN-04005: error from target database:ORA-12528: TNS:listener: all appropriate instances are blocking new connections
下面我来模拟一下这种情况
1.将数据库置于nomount状态
SQL> startup nomountORACLE instance started.Total System Global Area 327155712 bytesFixed Size 1273516 bytesVariable Size 138412372 bytesDatabase Buffers 184549376 bytesRedo Buffers 2920448 bytes
2.连接目标数据库
[oracle@oracle11g ~]$ rman target sys/zzh_2046@test catalog rman/rman@jyRecovery Manager: Release 10.2.0.5.0 - Production on Sun Feb 1 23:01:08 2015Copyright (c) 1982, 2007, Oracle. All rights reserved.RMAN-00571: ===========================================================RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============RMAN-00571: ===========================================================RMAN-00554: initialization of internal recovery manager package failedRMAN-04005: error from target database:ORA-12528: TNS:listener: all appropriate instances are blocking new connections
3.检查监听状态
[oracle@oracle11g ~]$ lsnrctl statusLSNRCTL for Linux: Version 10.2.0.5.0 - Production on 01-FEB-2015 23:00:49Copyright (c) 1991, 2010, Oracle. All rights reserved.Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))STATUS of the LISTENER------------------------Alias LISTENERVersion TNSLSNR for Linux: Version 10.2.0.5.0 - ProductionStart Date 01-FEB-2015 22:51:09Uptime 0 days 0 hr. 9 min. 40 secTrace Level offSecurity ON: Local OS AuthenticationSNMP OFFListener Log File /u01/app/oracle/10.2.0/db/network/log/listener.logListening Endpoints Summary... (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=oracle11g)(PORT=1521)))Services Summary...Service "test" has 1 instance(s). Instance "test", status BLOCKED, has 1 handler(s) for this service...Service "test_XPT" has 1 instance(s). Instance "test", status BLOCKED, has 1 handler(s) for this service...The command completed successfully
从上面的信息可以看到Instance "test",status BLOCKED，对于ora-12528错误在MOS有一篇文章描述造成这种问题的原因:
CauseWhen an instance is in restricted mode, PMON updates the listener with that information and blocks new connections from being established.The lsnrctl services output will show the handler is blocked for new connections or lsnrctl status may show the instance is in RESTRICTED mode.
解决方法如下:
The (UR=A) clause for TNS connect strings was created in response to an enhancement request. This clause can be inserted into the "(CONNECT_DATA=" section of a TNS connect string and allow a privileged or administrative user to connect via the listener even when the service handler is blocking connections for non-privileged users.Here's an example of a connect string configured with (UR=A):PROD = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = myhost.oracle.com)(PORT = 1521))) (CONNECT_DATA = (UR=A) (SERVICE_NAME = prod10ib.oracle.com) ) )Please note that the (UR=A) clause is intended to work with a dynamically registered handler so the use of SERVICE_NAME versus SID is required when using dynamic registration (i.e. handler exists in lsnrctl output but is BLOCKED). The use of SID in a TNS connect string may allow a connection if using a static handler in the listener.ora file under SID_DESC.
4.修改tns文件增加(UR=A)
[oracle@oracle11g admin]$ vi tnsnames.oratest = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.56.2)(PORT = 1521)) ) (CONNECT_DATA = (UR=A) (SERVICE_NAME = test) ) )jy = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST =192.168.56.11)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = jy) ) )
5.再次连接目标数据库执行恢复
[oracle@oracle11g admin]$ rman target sys/zzh_2046@test catalog rman/rman@jyRecovery Manager: Release 10.2.0.5.0 - Production on Sun Feb 1 23:04:03 2015Copyright (c) 1982, 2007, Oracle. All rights reserved.connected to target database: test (not mounted)connected to recovery catalog databaseRMAN> restore controlfile;Starting restore at 01-FEB-15allocated channel: ORA_DISK_1channel ORA_DISK_1: sid=155 devtype=DISKchannel ORA_DISK_1: starting datafile backupset restorechannel ORA_DISK_1: restoring control filechannel ORA_DISK_1: reading from backup piece /u01/app/oracle/10.2.0/db/dbs/c-2155613261-20150201-01channel ORA_DISK_1: restored backup piece 1piece handle=/u01/app/oracle/10.2.0/db/dbs/c-2155613261-20150201-01 tag=TAG20150201T213315channel ORA_DISK_1: restore complete, elapsed time: 00:00:04output filename=/u01/app/oracle/oradata/test/control01.ctloutput filename=/u01/app/oracle/oradata/test/control02.ctloutput filename=/u01/app/oracle/oradata/test/control03.ctlFinished restore at 01-FEB-15RMAN> sql 'alter database mount';sql statement: alter database mountreleased channel: ORA_DISK_1RMAN> recover database;Starting recover at 01-FEB-15Starting implicit crosscheck backup at 01-FEB-15allocated channel: ORA_DISK_1channel ORA_DISK_1: sid=155 devtype=DISKCrosschecked 8 objectsFinished implicit crosscheck backup at 01-FEB-15Starting implicit crosscheck copy at 01-FEB-15using channel ORA_DISK_1Crosschecked 6 objectsFinished implicit crosscheck copy at 01-FEB-15searching for all files in the recovery areacataloging files...no files catalogedusing channel ORA_DISK_1starting media recoveryarchive log thread 1 sequence 3 is already on disk as file /u01/app/oracle/oradata/test/redo03.logarchive log thread 1 sequence 4 is already on disk as file /u01/app/oracle/oradata/test/redo01.logarchive log filename=/u01/app/oracle/oradata/test/redo03.log thread=1 sequence=3archive log filename=/u01/app/oracle/oradata/test/redo01.log thread=1 sequence=4media recovery complete, elapsed time: 00:00:01Finished recover at 01-FEB-15RMAN> sql 'alter database open resetlogs';sql statement: alter database open resetlogsnew incarnation of database registered in recovery catalogstarting full resync of recovery catalogfull resync complete
出现这个问题的原因是当使用动态注册监听时，当实例处于限制模式或受阻的情况下PMON将会更新监听程序来阻新的连接，解决方法其实有两种：
一是在tns连接描述串中增加(UR=A)子句来让动态监听程序使用service_name来进行注册
二是使用静态监听注册
第二章 删除备份报错
2.1 ORA-19606: 无法复制到 (或还原为) 快照控制文件
ORA-19606: Cannot copy or restore to snapshot control file
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/oracle/product/11.2.0/dbhome_1/dbs/snapcf_finaprim.f_bak';
crosscheck controlfilecopy '/u01/app/oracle/product/11.2.0/dbhome_1/dbs/snapcf_finaprim.f';
delete expired controlfilecopy '/u01/app/oracle/product/11.2.0/dbhome_1/dbs/snapcf_finaprim.f';
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/oracle/product/11.2.0/dbhome_1/dbs/snapcf_finaprim.f';
CONFIGURE SNAPSHOT CONTROLFILE NAME clear;
问题：
在控制文件中登记的控制文件的镜像文件已经被过期废弃，但通过rman命令无法删除。
发生问题的版本：
Oracle Server - Enterprise Edition - Version: 11.2.0.2 and later [Release: 11.2 and later ]
现象如下：
RMAN> delete noprompt obsolete device type disk;
RMAN 保留策略将应用于该命令
将 RMAN 保留策略设置为冗余 2
释放的通道: ORA_DISK_1
分配的通道: ORA_DISK_1
通道 ORA_DISK_1: SID=1867 设备类型=DISK
删除以下已废弃的备份和副本:
类型 关键字 完成时间 文件名/句柄
-------------------- ------ ------------------ --------------------
控制文件副本 1 07-2月 -12 /u01/app/ora11g/product/11.2.0/db_1/dbs/snapcf_wxxqccdb.f
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: delete 命令 (ORA_DISK_1 通道上, 在 02/29/2012 15:37:51 上) 失败
ORA-19606: 无法复制到 (或还原为) 快照控制文件
--crosscheck后再尝试删除，问题依旧
RMAN> crosscheck copy ;
释放的通道: ORA_DISK_1
分配的通道: ORA_DISK_1
通道 ORA_DISK_1: SID=1867 设备类型=DISK
说明与资料档案库中的任何数据文件副本都不匹配
对控制文件副本的验证失败
控制文件副本文件名=/u01/app/ora11g/product/11.2.0/db_1/dbs/snapcf_wxxqccdb.f RECID=1 STAMP=774635982
对归档日志的验证成功
归档日志文件名=+FRA/wxxqccdb/archivelog/2012_02_29/thread_1_seq_345.299.776481697 RECID=661 STAMP=776481698
已交叉检验的 2 对象
RMAN> delete expired copy;
释放的通道: ORA_DISK_1
分配的通道: ORA_DISK_1
通道 ORA_DISK_1: SID=1867 设备类型=DISK
说明与资料档案库中的任何数据文件副本都不匹配
说明与资料档案库中的任何归档日志都不匹配
控制文件副本列表
===========================
关键字 S 完成时间 Ckp SCN Ckp 时间
------- - ---------- ---------- ----------
1 X 07-2月 -12 1054822 07-2月 -12
名称: /u01/app/ora11g/product/11.2.0/db_1/dbs/snapcf_wxxqccdb.f
标记: TAG20120207T163942
是否确定要删除以上对象 (输入 YES 或 NO)? yes
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: delete 命令 (ORA_DISK_1 通道上, 在 02/29/2012 12:32:03 上) 失败
ORA-19606: 无法复制到 (或还原为) 快照控制文件
解决：
--1. Set new name (or location) for RMAN to use for snapshot controlfile:
RMAN> CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/ora11g/product/11.2.0/db_1/dbs/snapcf_wxxqccdb.f.new';
新的 RMAN 配置参数:
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/ora11g/product/11.2.0/db_1/dbs/snapcf_wxxqccdb.f.new';
已成功存储新的 RMAN 配置参数
--2. Remove the snapshot controlfile from the RMAN information as a controlfile copy.
delete '/u01/app/ora11g/product/11.2.0/db_1/dbs/snapcf_wxxqccdb.f' on operating system.
--3. Crosscheck and delete the file from RMAN:
RMAN> crosscheck controlfilecopy '/u01/app/ora11g/product/11.2.0/db_1/dbs/snapcf_wxxqccdb.f';
释放的通道: ORA_DISK_1
分配的通道: ORA_DISK_1
通道 ORA_DISK_1: SID=1867 设备类型=DISK
对控制文件副本的验证失败
控制文件副本文件名=/u01/app/ora11g/product/11.2.0/db_1/dbs/snapcf_wxxqccdb.f RECID=1 STAMP=774635982
已交叉检验的 1 对象
RMAN> delete expired controlfilecopy '/u01/app/ora11g/product/11.2.0/db_1/dbs/snapcf_wxxqccdb.f';
释放的通道: ORA_DISK_1
分配的通道: ORA_DISK_1
通道 ORA_DISK_1: SID=1867 设备类型=DISK
控制文件副本列表
===========================
关键字 S 完成时间 Ckp SCN Ckp 时间
------- - ---------- ---------- ----------
1 X 07-2月 -12 1054822 07-2月 -12
名称: /u01/app/ora11g/product/11.2.0/db_1/dbs/snapcf_wxxqccdb.f
标记: TAG20120207T163942
是否确定要删除以上对象 (输入 YES 或 NO)? yes
已删除控制文件副本
控制文件副本文件名=/u01/app/ora11g/product/11.2.0/db_1/dbs/snapcf_wxxqccdb.f RECID=1 STAMP=774635982
1 EXPIRED 对象已删除
--4. Set the snapshot controlfile name (or location) to original:
RMAN> CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/ora11g/product/11.2.0/db_1/dbs/snapcf_wxxqccdb.f';
旧的 RMAN 配置参数:
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/ora11g/product/11.2.0/db_1/dbs/snapcf_wxxqccdb.f.new';
新的 RMAN 配置参数:
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/ora11g/product/11.2.0/db_1/dbs/snapcf_wxxqccdb.f';
已成功存储新的 RMAN 配置参数
--5. To set the snapshot controlfile name back to default value:
RMAN> CONFIGURE SNAPSHOT CONTROLFILE NAME clear;
旧的 RMAN 配置参数:
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/ora11g/product/11.2.0/db_1/dbs/snapcf_wxxqccdb.f';
RMAN 配置参数已成功重置为默认值
参考：metalink ID 1215493.1
因发现 flash area 不多了，
通过 select * from v$flash_recovery_area_usage ； 发现是备份集占用空间太多。
于是delete obsolete; 发现出现报错 ORA-19606: Cannot copy or restore to snapshot control file
RMAN> delete obsolete;
RMAN retention policy will be applied to the command
RMAN retention policy is set to redundancy 1
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=174 device type=DISK
Deleting the following obsolete backups and copies:
Type Key Completion Time Filename/Handle
-------------------- ------ ------------------ --------------------
Control File Copy 1 23-AUG-13 /u01/app/oracle/product/11.2.0/dbhome_1/dbs/snapcf_finaprim.f
Backup Set 560 20-SEP-13
Backup Piece 560 20-SEP-13 +DATADG/finaprim/backupset/2013_09_20/annnf0_tag20130920t233259_0.1829.826673579
Backup Set 561 20-SEP-13
Backup Piece 561 20-SEP-13 +DATADG/finaprim/autobackup/2013_09_20/s_826673580.945.826673581
Backup Set 562 21-SEP-13
Backup Piece 562 21-SEP-13 +DATADG/finaprim/backupset/2013_09_21/annnf0_tag20130921t233004_0.623.826759805
Backup Set 563 21-SEP-13
Backup Piece 563 21-SEP-13 +DATADG/finaprim/backupset/2013_09_21/nnndf0_tag20130921t233011_0.693.826759813
Backup Set 564 21-SEP-13
Backup Piece 564 21-SEP-13 +DATADG/finaprim/backupset/2013_09_21/annnf0_tag20130921t233257_0.807.826759977
Backup Set 565 21-SEP-13
Backup Piece 565 21-SEP-13 +DATADG/finaprim/autobackup/2013_09_21/s_826759979.743.826759979
Backup Set 566 22-SEP-13
Backup Piece 566 22-SEP-13 +DATADG/finaprim/backupset/2013_09_22/annnf0_tag20130922t233005_0.1800.826846207
Backup Set 567 22-SEP-13
Backup Piece 567 22-SEP-13 +DATADG/finaprim/backupset/2013_09_22/nnndf0_tag20130922t233021_0.624.826846223
Backup Set 568 22-SEP-13
Backup Piece 568 22-SEP-13 +DATADG/finaprim/backupset/2013_09_22/annnf0_tag20130922t233307_0.1887.826846387
Backup Set 569 22-SEP-13
Backup Piece 569 22-SEP-13 +DATADG/finaprim/autobackup/2013_09_22/s_826846388.1891.826846389
Backup Set 570 23-SEP-13
Backup Piece 570 23-SEP-13 +DATADG/finaprim/backupset/2013_09_23/annnf0_tag20130923t233004_0.1041.826932605
Backup Set 571 23-SEP-13
Backup Piece 571 23-SEP-13 +DATADG/finaprim/backupset/2013_09_23/nnndf0_tag20130923t233020_0.776.826932621
Backup Set 572 23-SEP-13
Backup Piece 572 23-SEP-13 +DATADG/finaprim/backupset/2013_09_23/annnf0_tag20130923t233306_0.1895.826932787
Backup Set 573 23-SEP-13
Backup Piece 573 23-SEP-13 +DATADG/finaprim/autobackup/2013_09_23/s_826932787.1061.826932789
Backup Set 574 24-SEP-13
Backup Piece 574 24-SEP-13 +DATADG/finaprim/backupset/2013_09_24/annnf0_tag20130924t233005_0.1082.827019005
Do you really want to delete the above objects (enter YES or NO)? yes
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of delete command on ORA_DISK_1 channel at 09/25/2013 09:16:59
ORA-19606: Cannot copy or restore to snapshot control file
解决办法：
就是把SNAPSHOT CONTROLFILE的配置路径改变,然后删除控制文件快照
---重命名SNAPSHOT 文件
RMAN> CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/oracle/product/11.2.0/dbhome_1/dbs/snapcf_finaprim.f_bak';
new RMAN configuration parameters:
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/oracle/product/11.2.0/dbhome_1/dbs/snapcf_finaprim.f_bak';
new RMAN configuration parameters are successfully stored
---- crosscheck
RMAN> crosscheck controlfilecopy '/u01/app/oracle/product/11.2.0/dbhome_1/dbs/snapcf_finaprim.f';
released channel: ORA_DISK_1
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=174 device type=DISK
validation failed for control file copy
control file copy file name=/u01/app/oracle/product/11.2.0/dbhome_1/dbs/snapcf_finaprim.f RECID=1 STAMP=824231734
Crosschecked 1 objects
RMAN> delete expired controlfilecopy '/u01/app/oracle/product/11.2.0/dbhome_1/dbs/snapcf_finaprim.f';
released channel: ORA_DISK_1
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=174 device type=DISK
List of Control File Copies
===========================
Key S Completion Time Ckp SCN Ckp Time
------- - --------------- ---------- ---------------
1 X 23-AUG-13 128277627 23-AUG-13
Name: /u01/app/oracle/product/11.2.0/dbhome_1/dbs/snapcf_finaprim.f
Tag: TAG20130823T171534
Do you really want to delete the above objects (enter YES or NO)? yes
deleted control file copy
control file copy file name=/u01/app/oracle/product/11.2.0/dbhome_1/dbs/snapcf_finaprim.f RECID=1 STAMP=824231734
Deleted 1 EXPIRED objects
RMAN> CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/oracle/product/11.2.0/dbhome_1/dbs/snapcf_finaprim.f';
old RMAN configuration parameters:
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/oracle/product/11.2.0/dbhome_1/dbs/snapcf_finaprim.f_bak';
new RMAN configuration parameters:
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/oracle/product/11.2.0/dbhome_1/dbs/snapcf_finaprim.f';
new RMAN configuration parameters are successfully stored
RMAN> CONFIGURE SNAPSHOT CONTROLFILE NAME clear;
old RMAN configuration parameters:
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/oracle/product/11.2.0/dbhome_1/dbs/snapcf_finaprim.f';
RMAN configuration parameters are successfully reset to default value
至此，就可以再执行上面的删除命令了。
About Me
...............................................................................................................................
● 本文作者：小麦苗，只专注于数据库的技术，更注重技术的运用
● 本文在itpub（http://blog.itpub.net/26736162）、博客园（http://www.cnblogs.com/lhrbest）和个人微信公众号（xiaomaimiaolhr）上有同步更新
● 本文itpub地址：http://blog.itpub.net/26736162/abstract/1/
● 本文博客园地址：http://www.cnblogs.com/lhrbest
● 本文pdf版及小麦苗云盘地址：http://blog.itpub.net/26736162/viewspace-1624453/
● 数据库笔试面试题库及解答：http://blog.itpub.net/26736162/viewspace-2134706/
● QQ群：230161599 微信群：私聊
● 联系我请加QQ好友(646634621)，注明添加缘由
● 于 2017-07-01 09:00 ~ 2017-07-31 22:00 在魔都完成
● 文章内容来源于小麦苗的学习笔记，部分整理自网络，若有侵权或不当之处还请谅解
● 版权所有，欢迎分享本文，转载请保留出处
...............................................................................................................................
拿起手机使用微信客户端扫描下边的左边图片来关注小麦苗的微信公众号：xiaomaimiaolhr，扫描右边的二维码加入小麦苗的QQ群，学习最实用的数据库技术。
