RMAN Incarnations revisited (11G)
13/02/2013 3 Comments
Time for an update to a older post. I have previously talked about the annoyance of connecting to RMAN with a duplicated database where the DBID has not been changed. RMAN happily breaks the catalog by assuming the “new” database is a new incarnation, and prevents the previous owner of the catalog from using the backups.
I wrote a blog post a while ago about hacking your way past this problem, but was recently informed by Martin Bach that there was actually an RMAN command to fix the Incarnation problem I had encountered, so I though I had better take a look and see if it worked!
Well, the first thing I noticed was that Oracle 11G does not break when connecting from a different database with the same DBID the way it did in Oracle 10G:
[oracle@localhost ~]$ rman target system/oracle catalog rman/rman@orcl1
Recovery Manager: Release 11.2.0.2.0 - Production on Sat Jan 26 12:26:10 2013
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
connected to target database: ORCL1 (DBID=1229390655)
connected to recovery catalog database
RMAN> list incarnation;
starting full resync of recovery catalog
full resync complete
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1 18 ORCL1 1229390655 PARENT 1 13/08/09 23:00:48
1 2 ORCL1 1229390655 CURRENT 754488 30/10/09 11:38:43
RMAN> list backup summary;
List of Backups
===============
Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
------- -- -- - ----------- ----------------- ------- ------- ---------- ---
331 B A A DISK 26/01/13 08:55:32 1 1 NO BACKUP1
375 B A A DISK 26/01/13 09:06:44 1 1 NO BACKUP2
400 B A A DISK 26/01/13 09:07:02 1 1 NO BACKUP3
587 B F A DISK 26/01/13 11:20:09 1 1 YES FULL BACKUP
609 B F A DISK 26/01/13 11:20:11 1 1 NO TAG20130126T112010
And on the alternate database:
[oracle@localhost ~]$ rman target system/oracle catalog rman/rman@orcl1
Recovery Manager: Release 11.2.0.2.0 - Production on Sat Jan 26 12:15:07 2013
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
connected to target database: ORCL2 (DBID=1229390655)
connected to recovery catalog database
RMAN> list incarnation;
starting full resync of recovery catalog
full resync complete
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1 18 ORCL2 1229390655 PARENT 1 13/08/09 23:00:48
1 2 ORCL2 1229390655 CURRENT 754488 30/10/09 11:38:43
RMAN> list backup summary;
specification does not match any backup in the repository
RMAN>
Whilst the incarnations look a little incorrect (referring to ORCL2), the system does not break. So, no more need to hack around with incarnations if the system breaks accidentally. However, what if you register the other database…
[oracle@localhost ~]$ rman target system/oracle catalog rman/rman@orcl1 Recovery Manager: Release 11.2.0.2.0 - Production on Sun Jan 27 05:44:06 2013 Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved. connected to target database: ORCL2 (DBID=1229390655) connected to recovery catalog database RMAN> register database; starting full resync of recovery catalog full resync complete RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03009: failure of register command on default channel at 01/27/2013 05:44:12 RMAN-20002: target database already registered in recovery catalog
So, after a little effort it would appear I can’t easily break the incarnations in Oracle 11G. So let’s try. I recovered the ORCL1 database to create a new incarnation to see how ORCL2 would behave when connected:
on ORCL1:
[oracle@localhost ~]$ rman target system/oracle catalog rman/rman@orcl1 Recovery Manager: Release 11.2.0.2.0 - Production on Sun Jan 27 12:32:09 2013 Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved. connected to target database: ORCL1 (DBID=1229390655) connected to recovery catalog database RMAN> list incarnation; List of Database Incarnations DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time ------- ------- -------- ---------------- --- ---------- ---------- 1 18 ORCL1 1229390655 PARENT 1 13/08/09 23:00:48 1 2 ORCL1 1229390655 PARENT 754488 30/10/09 11:38:43 1 921 ORCL1 1229390655 CURRENT 10215936 27/01/13 12:27:12 <- new incarnation
<BR>
And now ORCL2 behaves a little differently, recognising the ORCL1 incarnations correctly, and throwing an error:
[oracle@localhost ~]$ rman target system/oracle catalog rman/rman@orcl1 Recovery Manager: Release 11.2.0.2.0 - Production on Sun Jan 27 12:19:27 2013 Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved. connected to target database: ORCL2 (DBID=1229390655) connected to recovery catalog database RMAN> list incarnation; List of Database Incarnations DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time ------- ------- -------- ---------------- --- ---------- ---------- 1 18 ORCL1 1229390655 PARENT 1 13/08/09 23:00:48 1 2 ORCL1 1229390655 PARENT 754488 30/10/09 11:38:43 1 921 ORCL1 1229390655 CURRENT 10215936 27/01/13 12:27:12 RMAN> list backup summary; RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of list command at 01/27/2013 12:19:38 RMAN-06004: ORACLE error from recovery catalog database: RMAN-20004: target database name does not match name in recovery catalog
So, what if I change the name of ORCL2 back to ORCL1. Can I reproduce my error then?
[oracle@localhost dbs]$ sqlplus / as sysdba SQL*Plus: Release 11.1.0.7.0 - Production on Sun Jan 27 12:23:29 2013 Copyright (c) 1982, 2008, Oracle. All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - Production With the Partitioning, OLAP, Data Mining and Real Application Testing options SQL> shutdown immediate; Database closed. Database dismounted. ORACLE instance shut down. SQL> startup mount; ORACLE instance started. Total System Global Area 456146944 bytes Fixed Size 1344840 bytes Variable Size 381684408 bytes Database Buffers 67108864 bytes Redo Buffers 6008832 bytes Database mounted. SQL> exit Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - Production With the Partitioning, OLAP, Data Mining and Real Application Testing options [oracle@localhost dbs]$ nid target=system/oracle dbname=orcl1 setname=yes DBNEWID: Release 11.2.0.2.0 - Production on Sun Jan 27 12:24:10 2013 Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved. Connected to database ORCL2 (DBID=1229390655) Connected to server version 11.2.0 Control Files in database: /home/oracle/app/oracle/oradata/orcl/control01.ctl /home/oracle/app/oracle/flash_recovery_area/orcl/control02.ctl Change database name of database ORCL2 to ORCL1? (Y/[N]) => Y Proceeding with operation Changing database name from ORCL2 to ORCL1 Control File /home/oracle/app/oracle/oradata/orcl/control01.ctl - modified Control File /home/oracle/app/oracle/flash_recovery_area/orcl/control02.ctl - modified Datafile /home/oracle/app/oracle/oradata/orcl/system01.db - wrote new name Datafile /home/oracle/app/oracle/oradata/orcl/sysaux01.db - wrote new name Datafile /home/oracle/app/oracle/oradata/orcl/undotbs01.db - wrote new name Datafile /home/oracle/app/oracle/oradata/orcl/users01.db - wrote new name Datafile /home/oracle/app/oracle/oradata/orcl/example01.db - wrote new name Datafile /home/oracle/app/oracle/oradata/orcl/APEX_1246426611663638.db - wrote new name Datafile /home/oracle/app/oracle/oradata/orcl/APEX_1265209995679366.db - wrote new name Datafile /home/oracle/app/oracle/oradata/orcl/temp01.db - wrote new name Control File /home/oracle/app/oracle/oradata/orcl/control01.ctl - wrote new name Control File /home/oracle/app/oracle/flash_recovery_area/orcl/control02.ctl - wrote new name Instance shut down Database name changed to ORCL1. Modify parameter file and generate a new password file before restarting. Succesfully changed database name. DBNEWID - Completed succesfully. [note: I have already got the relevant init.ora and oratab setup] [oracle@localhost dbs]$ . oraenv ORACLE_SID = [orcl2] ? orcl1 The Oracle base has been set to /home/oracle/app/oracle [oracle@localhost dbs]$ sqlplus / as sysdba SQL*Plus: Release 11.1.0.7.0 - Production on Sun Jan 27 12:24:31 2013 Copyright (c) 1982, 2008, Oracle. All rights reserved. Connected to an idle instance. SQL> startup mount; ORACLE instance started. Total System Global Area 456146944 bytes Fixed Size 1344840 bytes Variable Size 381684408 bytes Database Buffers 67108864 bytes Redo Buffers 6008832 bytes Database mounted. SQL> alter database open; Database altered. SQL >exit [oracle@localhost dbs]$ rman target system/oracle catalog rman/rman@orcl1
Recovery Manager: Release 11.2.0.2.0 – Production on Sun Jan 27 12:52:45 2013
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
connected to target database: ORCL1 (DBID=1229390655)
connected to recovery catalog database
RMAN> list incarnation;
database reset to incarnation 2
starting full resync of recovery catalog
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
——- ——- ——– —————- — ———- ———-
1 18 ORCL1 1229390655 PARENT 1 13/08/09 23:00:48
1 2 ORCL1 1229390655 CURRENT 754488 30/10/09 11:38:43
1 921 ORCL1 1229390655 ORPHAN 10215936 27/01/13 12:27:12
So, the newly rename-to ORCL1 thinks we are at incarnation 2. However, log back into the original ORCL1 and it resets the incarnation back to 921. Still no corruption, still no problem!
So, I still can’t prove whether the ALTER DATABASE SET INCARNATION command will work as mentioned to me, or whether it’s just something that allows me to recover across a resetlogs command. Looks like I’ll have to reinstall Oracle 10G… tomorrow.
Neil Chandler's DB Blog 