| RMAN-20003: target database incarnation .. [message #335320] |
Mon, 21 July 2008 19:49  |
lotusdeva Messages: 172 Registered: March 2005 |
Senior Member |
|
|
Hi, I am trying to recover from the loss of a control file (which is multiplexed). I am on Oracle 10g, implementing FRA and a recovery catalog. We have taken a most recent hot backup this morning. I have performed the following steps:
1.
prodDb> rman target sys/*****@PROD catalog rman@catdb
2.
3.
RMAN> restore controlfile from autobackup;
4.
RMAN> alter database mount;
5.
Here I get the following errors:
Starting recover at 21-JUL-08
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 07/21/2008 20:39:16
RMAN-12010: automatic channel allocation initialization failed
RMAN-06004: ORACLE error from recovery catalog database: RMAN-20003: target database incarnation not found in recovery catalog
Any ideas as of what can be wrong? Thank you!
|
|
|
| Re: RMAN-20003: target database incarnation .. [message #335327 is a reply to message #335320 ] |
Mon, 21 July 2008 20:15   |
anacedent Messages: 6620 Registered: July 2005 Location: surf meets turf in SoCal |
Senior Member |
|
|
http://www.orafaq.com/forum/t/88153/0/
Please read & follow the Posting Guidelines as stated in URL above
>Any ideas as of what can be wrong?
You are not following the documented & tested Recovery Procedures
Do you realize that the contents of the control file changes after every COMMIT?
What do you expect a control file that is hours old will do for you?
Even if you restore a copy of the control file from backups, Oracle can not & will not use it.
I suggest you contact the local/resident DBA for assistance.
[Updated on: Mon, 21 July 2008 20:15]
|
|
|
| Re: RMAN-20003: target database incarnation .. [message #335332 is a reply to message #335327 ] |
Mon, 21 July 2008 20:25   |
lotusdeva Messages: 172 Registered: March 2005 |
Senior Member |
|
|
1. I am a DBA and I am working on the restore/recovery scenarios for one of my databases.
2. There was ZERO activity on the database, it is there purelly for my testing purposes.
2. I have followed documented procedures to recover from the loss of the multiplexed control file.
2. Why do you ALWAYS replay in such an unpleasant manner?
|
|
|
| Re: RMAN-20003: target database incarnation .. [message #335333 is a reply to message #335320 ] |
Mon, 21 July 2008 20:35   |
anacedent Messages: 6620 Registered: July 2005 Location: surf meets turf in SoCal |
Senior Member |
|
|
>There was ZERO activity on the database, it is there purelly for my testing purposes.
I'll give you 100 to 1 odds that the current SCN does NOT match the SCN in the backed up control file.
AWR regularly writes performance statistics into the database; in addition to other "background" sessions.
The backed up control file will do NOTHING for you now.
|
|
|
| Re: RMAN-20003: target database incarnation .. [message #335335 is a reply to message #335333 ] |
Mon, 21 July 2008 20:44   |
lotusdeva Messages: 172 Registered: March 2005 |
Senior Member |
|
|
|
so do you know of a solution then?
|
|
|
| Re: RMAN-20003: target database incarnation .. [message #335337 is a reply to message #335320 ] |
Mon, 21 July 2008 20:50   |
anacedent Messages: 6620 Registered: July 2005 Location: surf meets turf in SoCal |
Senior Member |
|
|
>I am trying to recover from the loss of a control file
What happened to the control file?
> I have followed documented procedures to recover from the loss of the multiplexed control file.
Who wrote & tested these procedures?
Is instance normally started with spfile or pfile?
|
|
|
| Re: RMAN-20003: target database incarnation .. [message #335338 is a reply to message #335337 ] |
Mon, 21 July 2008 20:53   |
lotusdeva Messages: 172 Registered: March 2005 |
Senior Member |
|
|
1. I deleted it from the OS level as part of my restore/recover scenarios.
2. SPFILE
3. I wrote them (drawing from Oracle documentation, as well as several books and my own experience). Although I dont have much experience with RMAN
p.s. I can easily recover from the loss of a control file not using RMAN..
[Updated on: Mon, 21 July 2008 20:54]
|
|
|
| Re: RMAN-20003: target database incarnation .. [message #335339 is a reply to message #335320 ] |
Mon, 21 July 2008 20:57   |
anacedent Messages: 6620 Registered: July 2005 Location: surf meets turf in SoCal |
Senior Member |
|
|
>p.s. I can easily recover from the loss of a control file not using RMAN..
Then proceed to do so.
|
|
|
| Re: RMAN-20003: target database incarnation .. [message #335340 is a reply to message #335339 ] |
Mon, 21 July 2008 20:58   |
lotusdeva Messages: 172 Registered: March 2005 |
Senior Member |
|
|
|
the whole point is to learn how to use RMAN.
|
|
|
| Re: RMAN-20003: target database incarnation .. [message #335547 is a reply to message #335320 ] |
Tue, 22 July 2008 09:40   |
 |
Mahesh Rajendran Messages: 8690 Registered: March 2002 |
Senior Member |
|
|
Kind of expected behavior (based on the partial session you have posted with only commands and no output is included) as you broke all basic rules.
Quoting Docs
If you want to restore the control file from autobackup, the database must be in a NOMOUNT state.
You must first set the DBID for your database, and then use the RESTORE CONTROLFILE FROM AUTOBACKUP command:
Edit: Broke the paragraph
[Updated on: Tue, 22 July 2008 09:41]
|
|
|
| Re: RMAN-20003: target database incarnation .. [message #335550 is a reply to message #335547 ] |
Tue, 22 July 2008 09:47   |
lotusdeva Messages: 172 Registered: March 2005 |
Senior Member |
|
|
1. My db was in NOMOUNT state, sorry if I wasn't clear
2. You dont have to use DBid if you are in 10g, have FRA set up and configured controlfile autobackup on.
|
|
|
|
| Re: RMAN-20003: target database incarnation .. [message #335560 is a reply to message #335552 ] |
Tue, 22 July 2008 11:47  |
lotusdeva Messages: 172 Registered: March 2005 |
Senior Member |
|
|
I started from scratch - droped the catalog, recreated it and followed all of the steps outlined in my original post without any errors. So, with FRA + autobackup on you dont have to get DBid:
RMAN> restore controlfile from autobackup;
Starting restore at 22-JUL-08
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=541 devtype=DISK
recovery area destination: /prod/flash_recovery
database name (or database unique name) used for search: *****
channel ORA_DISK_1: autobackup found in the recovery area
channel ORA_DISK_1: autobackup found: /prod/flash_recovery/PPMTST/autobackup/2008_07_22/o1_mf_s_660744028_48d10x09_.bkp
channel ORA_DISK_1: control file restore from autobackup complete
output filename=/prod/dbf/ppmtstdata/cntrl01.dbf
output filename=/prod/dbf/ppmtstdata/cntrl02.dbf
output filename=/prod/dbf/ppmtstdata/cntrl03.dbf
Finished restore at 22-JUL-08
Then I recovered db as follows:
RMAN> recover database;
Starting recover at 22-JUL-08
Starting implicit crosscheck backup at 22-JUL-08
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=541 devtype=DISK
Crosschecked 6 objects
Finished implicit crosscheck backup at 22-JUL-08
Starting implicit crosscheck copy at 22-JUL-08
using channel ORA_DISK_1
Finished implicit crosscheck copy at 22-JUL-08
searching for all files in the recovery area
cataloging files...
cataloging done
List of Cataloged Files
=======================
File Name: /prod/flash_recovery/*****/autobackup/2008_07_22/o1_mf_s_660744028_48d10x09_.bkp
using channel ORA_DISK_1
starting media recovery
archive log thread 1 sequence 12022 is already on disk as file /prod/dbf/log01a.dbf
archive log filename=/data/dbf/log01a.dbf thread=1 sequence=12022
media recovery complete, elapsed time: 00:00:02
Finished recover at 22-JUL-08
And then opened it with resetlogs...
RMAN> alter database open resetlogs;
database opened
new incarnation of database registered in recovery catalog
starting full resync of recovery catalog
full resync complete
|
|
|