Database Incarnation
Hi all
Does it matter whether after a database incarnation has been made that there are files from both incarnations around? I performed a test recovery from tape, basically all files that could be used to recover, to a test server, and performed an Oracle (full database) suggested recovery. It worked, but in the aftermath, there are archivelogs with different database incarnation number, and redo logs with differerent incarnation number. I understand that the database is essentially a 'new database' as far as creation is considered.
Thanks, David
Hi Nicolas
Yes, I was actually doing a restore from one machine to another so the incarnation was different. My confusion was about whether having files with different incarnation numbers around made a difference; logically it can't - except for maybe my suspicion. The restore was an OEM rman suggested recovery; don't think it did resetlogs. It was a total (all files) recovery.
Thanks, David
Similar Messages
-
About database incarnations in catalog versus non-catalog
Hi all
Listing out the incarnations of my target database when not connected to the recovery catalog :
RMAN> list incarnation of database testdb;
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
1 1 TESTDB 2539541829 PARENT 1 11-JUL-11
2 2 TESTDB 2539541829 PARENT 591584 12-JUL-11
3 3 TESTDB 2539541829 PARENT 2061948 19-JUL-11
4 4 TESTDB 2539541829 ORPHAN 1345130669 13-MAY-13
5 5 TESTDB 2539541829 CURRENT 1345130669 15-MAY-13And listing out the incarnations when connected to the catalog:
RMAN> list incarnation of database testdb;
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
1178485 1178523 TESTDB 2539541829 PARENT 1 11-JUL-11
1178485 1178524 TESTDB 2539541829 PARENT 591584 12-JUL-11
1178485 1178525 TESTDB 2539541829 PARENT 2061948 19-JUL-11
1178485 1178526 TESTDB 2539541829 ORPHAN 1345130669 13-MAY-13
1178485 1178486 TESTDB 2539541829 CURRENT 1345130669 15-MAY-13Why are INC KEY numbers not matching? Is this a bug or is it expected behaviour?
Please help me shed some light on this..
Thanks.Hi,
Manual said:
DB Key- When combined with the Inc Key, the unique key by which RMAN identifies the database incarnation in the recovery catalog. Use this key to unregister a database from a recovery catalog, that is, delete all the rows associated with that database from the recovery catalog.
INC Key- When combined with DB Key, the unique key by which RMAN identifies the database incarnation in the recovery catalog. Use this key in RESET DATABASE TO INCARNATION when recovering the database to a time before the most recent RESETLOGS.
<<http://docs.oracle.com/cd/E11882_01/backup.112/e10643/rcmsynta027.htm#CHDGGAFF>>
recovery-catalog and control file-catalog is a catalog of different, So not match.
Regards, -
RMAN and database incarnations
In experimenting with RMAN, I got our team into a situation where a test database would not restore and recover. I performed an incomplete recovery, opened resetlogs, and without performing a backup, did the same thing again.
In any case, we started reading up on how to return to a previous database incarnation. We're not using a Recovery Catalog w RMAN, but 10g has been enhanced so that the control file now tracks db incarnations.
We set the db incarnation back 2 previous, and then performed:
RMAN> restore database until "to_date('9/2/04 23:59:59','mm/dd/yy hr24:mi:ss');
RMAN> recover database until "to_date('9/2/04 23:59:59','mm/dd/yy hr24:mi:ss');
and all seems well.
I have 2 questions:
1) Was the return back 2 incarnations really necessary? It seems like the database would've considered the 2 lines above an incomplete recovery and restore/recovered anyway.
2) Do I need to manually remove the archive logs created for incarnations 3 & 4, or will RMAN know that they are not applicaable? And how does it know they're inapplicable, if so? The incarnation?
Thanks for reading this looong question,
ChuckIn experimenting with RMAN, I got our team into a situation where a test database would not restore and recover. I performed an incomplete recovery, opened resetlogs, and without performing a backup, did the same thing again.
In any case, we started reading up on how to return to a previous database incarnation. We're not using a Recovery Catalog w RMAN, but 10g has been enhanced so that the control file now tracks db incarnations.
We set the db incarnation back 2 previous, and then performed:
RMAN> restore database until "to_date('9/2/04 23:59:59','mm/dd/yy hr24:mi:ss');
RMAN> recover database until "to_date('9/2/04 23:59:59','mm/dd/yy hr24:mi:ss');
and all seems well.
I have 2 questions:
1) Was the return back 2 incarnations really necessary? It seems like the database would've considered the 2 lines above an incomplete recovery and restore/recovered anyway.
2) Do I need to manually remove the archive logs created for incarnations 3 & 4, or will RMAN know that they are not applicaable? And how does it know they're inapplicable, if so? The incarnation?
Thanks for reading this looong question,
Chuck -
What is Database Incarnations in rman ?
hi all
What is incarnation in rman , what is the use of it.....
tell me in simple words, i googled it i did not get exactly what it means...
Regards,
Vamsi,'Incarnation' literally means 'became flesh'. So 'was born'. And there is nothing before birth.
You can also compare it with crossing a wooden bridge over a ravine (what you always see in cartoons like 'Speedy Gonzales'), after you have crossed, the bridge collapses, and there is no way back. That is incarnation too.
During alter database open resetlogs, the logsequence of the database is reset, this is an incarnation (act of birth) and without RMAN there is no way of going back to a previous incarnation.
You will have an incarnation when the database is created and every time you use resetlogs. RMAN allows you to reset the database to a 'previous incarnation'.
Sybrand Bakker
Senior Oracle DBA -
DATABASE VERSION = 10.2.0.3
PLATFORM = AIX 3
Could some one please let me know the meaning of ORPHAN, which is visible when ever i give list incarnation command.
RMAN> list incarnation of database merlinp;
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
1142887 1142888 MERLINP 3538586174 ORPHAN 1 06-APR-07.
every time my rman backup is failing with the errors as
RMAN-06004: ORACLE error from recovery catalog database: RMAN-20011: target database incarnation is not current in recovery catalog
Target database was not opened with resetlogs. See below
From TARGET DATABASE
SQL> select RESETLOGS_CHANGE#, RESETLOGS_TIME from v$database;
RESETLOGS_CHANGE# RESETLOGS
1 06-APR-07
From this we can see that Incarnation is already been registered in the catalog database.
Plz let me know why my backup's are failing by looking at the above information.
kumareshanThere two points
If 'reset database to incarnation <key>' was used to make an old incarnation current then restore the target database from a backup that matches the incarnation and mount it.You will need to do 'startup nomount' before you can restore the controlfile using RMAN Or use 'reset database to incarnation <key>' make the intended incarnation current in the recovery catalog.
Additionally you can see Doc ID: Note:48364.1.
Adith -
Can any one please explain me what is mean by incarnation of database
user12661962 wrote:
Can any one please explain me what is mean by incarnation of databaseEach time an OPEN RESETLOGS operation is performed on a database, this operation creates a new incarnation of the database. Database incarnations and their effect upon database recovery with RMAN are explained in more detail in Oracle database backup and recovery
http://download.oracle.com/docs/cd/B19306_01/backup.102/b14191/toc.htm -
Unable to recover database after rman recovery and database open resetlogs
I am running Oracle 10.2.0.5 on OpenSUSE 9. I have been trying to upgrade the database to 11g, through dbua. I was getting stuck at one point during the Oracle Server install and the upgrade failed and I was forced to restore the database to an earlier backup.
Below is the current place that I am stuck. As you can see I opened the database multiple times and reset the logs. Now I am afraid that my controlfile and redo log backups are out of sync and i can't get them back on track. Before when I actually got the database recovered RMAN would immediately throw:
RMAN-06900: WARNING: unable to generate V$RMAN_STATUS or V$RMAN_OUTPUT row
RMAN-06901: WARNING: disabling update of the V$RMAN_STATUS and V$RMAN_OUTPUT rows
OPA-00600: ORA-00600: internal error code, arguments: ...
The database would open with ALTER DATABASE RESETLOGS but any query on non-system tables would fail and throw:
ORA-04045: errors during recompilation/revalidation of LCRS_DEV1.FACILITY_REF
ORA-00600: internal error code, arguments: [17069], [0x1158ED180], [], [], [],
I hope I have not dug myself into too deep of a hole here.
Here is the trace from my most recent attempt.
RMAN> startup nomount;
connected to target database (not started)
Oracle instance started
Total System Global Area 3070230528 bytes
Fixed Size 2099424 bytes
Variable Size 301991712 bytes
Database Buffers 2751463424 bytes
Redo Buffers 14675968 bytes
RMAN> list incarnation of database;
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of list command at 08/02/2011 15:49:04
ORA-01507: database not mounted
RMAN> restore controlfile from autobackup;
Starting restore at 02-AUG-11
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=156 devtype=DISK
recovery area destination: /opt/oracle/flash_recovery_area
database name (or database unique name) used for search: LCRSDEV
channel ORA_DISK_1: autobackup found in the recovery area
channel ORA_DISK_1: autobackup found: /opt/oracle/flash_recovery_area/LCRSDEV/autobackup/2011_08_02/o1_mf_s_758129928_73jr2s7p_.bkp
channel ORA_DISK_1: control file restore from autobackup complete
output filename=/opt/oracle/oradata/LCRSDEV/control01.ctl
output filename=/opt/oracle/oradata/LCRSDEV/control02.ctl
output filename=/opt/oracle/oradata/LCRSDEV/control03.ctl
Finished restore at 02-AUG-11
RMAN> alter database mount;
database mounted
released channel: ORA_DISK_1
RMAN> list incarnation of database;
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
1 1 LCRSDEV 756543625 PARENT 1 22-OCT-05
2 2 LCRSDEV 756543625 PARENT 525876 20-JAN-11
3 3 LCRSDEV 756543625 PARENT 92348137 18-JUL-11
4 4 LCRSDEV 756543625 PARENT 95654931 01-AUG-11
5 5 LCRSDEV 756543625 PARENT 95675699 01-AUG-11
6 6 LCRSDEV 756543625 PARENT 95676699 02-AUG-11
7 7 LCRSDEV 756543625 PARENT 95676700 02-AUG-11
8 8 LCRSDEV 756543625 CURRENT 95676701 02-AUG-11
RMAN> restore database until scn 95676700;
Starting restore at 02-AUG-11
Starting implicit crosscheck backup at 02-AUG-11
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=156 devtype=DISK
Crosschecked 6 objects
Finished implicit crosscheck backup at 02-AUG-11
Starting implicit crosscheck copy at 02-AUG-11
using channel ORA_DISK_1
Finished implicit crosscheck copy at 02-AUG-11
searching for all files in the recovery area
cataloging files...
cataloging done
List of Cataloged Files
=======================
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/autobackup/2011_08_02/o1_mf_s_758129928_73jr2s7p_.bkp
using channel ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 08/02/2011 15:52:04
RMAN-20208: UNTIL CHANGE is before RESETLOGS change
RMAN> restore database;
Starting restore at 02-AUG-11
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00001 to /opt/oracle/oradata/LCRSDEV/system01.dbf
restoring datafile 00002 to /opt/oracle/oradata/LCRSDEV/undotbs01.dbf
restoring datafile 00003 to /opt/oracle/oradata/LCRSDEV/sysaux01.dbf
restoring datafile 00004 to /opt/oracle/oradata/LCRSDEV/users01.dbf
restoring datafile 00005 to /opt/oracle/oradata/LCRSDEV/LCRS_TBS.dbf
channel ORA_DISK_1: reading from backup piece /opt/oracle/flash_recovery_area/LCRSDEV/backupset/2011_07_22/o1_mf_nnndf_TAG20110722T111922_72m8rc5x_.bkp
channel ORA_DISK_1: restored backup piece 1
piece handle=/opt/oracle/flash_recovery_area/LCRSDEV/backupset/2011_07_22/o1_mf_nnndf_TAG20110722T111922_72m8rc5x_.bkp tag=TAG20110722T111922
channel ORA_DISK_1: restore complete, elapsed time: 00:23:36
Finished restore at 02-AUG-11
RMAN> recover database until scn 95676700;
Starting recover at 02-AUG-11
using channel ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 08/02/2011 16:16:28
RMAN-20208: UNTIL CHANGE is before RESETLOGS change
RMAN> recover database;
Starting recover at 02-AUG-11
using channel ORA_DISK_1
starting media recovery
archive log thread 1 sequence 90 is already on disk as file /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_22/o1_mf_1_90_72ml85v3_.arc
archive log filename=/opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_08_02/o1_mf_1_1_73jr20qc_.arc thread=1 sequence=1
unable to find archive log
archive log thread=1 sequence=1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 08/02/2011 16:25:04
RMAN-06054: media recovery requesting unknown log: thread 1 seq 1 lowscn 95676701Thanks for the reply Hemant. I have reset the database for the controlfile that I am using as backup and now I am not able to recover until the correct SCN. I am thinking that my recovery catalog is bad. If I mount with the current controlfile I have this list of incarnations:
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
*1 1 LCRSDEV 756543625 PARENT 1 22-OCT-05*
*2 2 LCRSDEV 756543625 PARENT 525876 20-JAN-11*
*3 3 LCRSDEV 756543625 PARENT 92348137 18-JUL-11*
*4 4 LCRSDEV 756543625 PARENT 95654931 01-AUG-11*
*5 5 LCRSDEV 756543625 PARENT 95675699 01-AUG-11*
*6 6 LCRSDEV 756543625 PARENT 95676699 02-AUG-11*
*7 7 LCRSDEV 756543625 PARENT 95676700 02-AUG-11*
*8 8 LCRSDEV 756543625 PARENT 95676701 02-AUG-11*
*9 9 LCRSDEV 756543625 CURRENT 95676702 02-AUG-11*
However if I restore the controlfile to the earlier version I am getting the following output from the process:
RMAN> startup nomount;
connected to target database (not started)
Oracle instance started
Total System Global Area 3070230528 bytes
Fixed Size 2099424 bytes
Variable Size 301991712 bytes
Database Buffers 2751463424 bytes
Redo Buffers 14675968 bytes
RMAN> restore controlfile from '/opt/oracle/flash_recovery_area/LCRSDEV/autobackup/2011_07_22/o1_mf_s_757164997_72m9rqw3_.bkp';
Starting restore at 03-AUG-11
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=156 devtype=DISK
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
output filename=/opt/oracle/oradata/LCRSDEV/control01.ctl
output filename=/opt/oracle/oradata/LCRSDEV/control02.ctl
output filename=/opt/oracle/oradata/LCRSDEV/control03.ctl
Finished restore at 03-AUG-11
RMAN> alter database mount;
database mounted
released channel: ORA_DISK_1
RMAN> list incarnation of database;
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
1 1 LCRSDEV 756543625 PARENT 1 22-OCT-05
2 2 LCRSDEV 756543625 PARENT 525876 20-JAN-11
3 3 LCRSDEV 756543625 CURRENT 92348137 18-JUL-11
RMAN> restore database until scn 92348137;
Starting restore at 03-AUG-11
Starting implicit crosscheck backup at 03-AUG-11
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=156 devtype=DISK
Crosschecked 1 objects
Finished implicit crosscheck backup at 03-AUG-11
Starting implicit crosscheck copy at 03-AUG-11
using channel ORA_DISK_1
Finished implicit crosscheck copy at 03-AUG-11
searching for all files in the recovery area
cataloging files...
cataloging done
List of Cataloged Files
=======================
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_08_01/o1_mf_1_1_73g3hn6o_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_08_01/o1_mf_1_2_73g3hnxq_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_08_01/o1_mf_1_1_73g0rts6_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_25/o1_mf_1_134_72v9gv4s_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_25/o1_mf_1_138_72v9p4b4_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_25/o1_mf_1_120_72v8wwg0_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_25/o1_mf_1_121_72v8x5ty_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_25/o1_mf_1_131_72v9cnrv_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_25/o1_mf_1_139_72v9q5ok_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_25/o1_mf_1_137_72v9n4t5_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_25/o1_mf_1_136_72v9l88q_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_25/o1_mf_1_123_72v8ytm8_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_25/o1_mf_1_132_72v9dcxd_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_25/o1_mf_1_124_72v8zkg0_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_25/o1_mf_1_128_72v96qm1_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_25/o1_mf_1_135_72v9jqmx_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_25/o1_mf_1_129_72v98q3r_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_25/o1_mf_1_125_72v91g3b_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_25/o1_mf_1_118_72v8v8r4_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_25/o1_mf_1_127_72v9626w_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_25/o1_mf_1_130_72v9bqtb_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_25/o1_mf_1_141_72vncy6g_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_25/o1_mf_1_122_72v8ycd4_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_25/o1_mf_1_126_72v94cns_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_25/o1_mf_1_133_72v9fb17_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_25/o1_mf_1_140_72vn6wgo_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_25/o1_mf_1_119_72v8v9hf_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_08_02/o1_mf_1_1_73j3wo01_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_08_02/o1_mf_1_2_73josgf1_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_08_02/o1_mf_1_1_73jr20qc_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_08_02/o1_mf_1_2_73jh223h_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_08_02/o1_mf_1_1_73josflf_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_08_02/o1_mf_1_1_73jvqdqs_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_08_02/o1_mf_1_3_73josh91_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_08_02/o1_mf_1_1_73j91rh9_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_22/o1_mf_1_91_72mqlnx9_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_22/o1_mf_1_111_72mrdr5m_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_22/o1_mf_1_96_72mqx958_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_22/o1_mf_1_114_72mrgsf9_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_22/o1_mf_1_94_72mqs6gj_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_22/o1_mf_1_102_72mr3893_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_22/o1_mf_1_99_72mr2h6c_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_22/o1_mf_1_104_72mr5hfm_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_22/o1_mf_1_109_72mrc83z_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_22/o1_mf_1_98_72mr080w_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_22/o1_mf_1_93_72mqq36m_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_22/o1_mf_1_97_72mqz0mm_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_22/o1_mf_1_116_72mrk268_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_22/o1_mf_1_101_72mr31yv_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_22/o1_mf_1_110_72mrddhg_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_22/o1_mf_1_95_72mqv3hp_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_22/o1_mf_1_105_72mr5vq4_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_22/o1_mf_1_115_72mrjd2s_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_22/o1_mf_1_106_72mr7hnt_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_22/o1_mf_1_100_72mr2qfc_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_22/o1_mf_1_112_72mrfc5j_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_22/o1_mf_1_107_72mr909t_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_22/o1_mf_1_103_72mr4pol_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_22/o1_mf_1_113_72mrfsb9_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_22/o1_mf_1_117_72mrl5mf_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_22/o1_mf_1_108_72mrb13l_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_22/o1_mf_1_90_72ml85v3_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_22/o1_mf_1_92_72mqnxz1_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_26/o1_mf_1_143_72y6ww71_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_26/o1_mf_1_144_72ybybps_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_26/o1_mf_1_142_72xt10j7_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/archivelog/2011_07_26/o1_mf_1_145_72yccy5z_.arc
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/autobackup/2011_08_01/o1_mf_s_758043324_73g3jfxx_.bkp
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/autobackup/2011_08_01/o1_mf_s_758035850_73fw6vrc_.bkp
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/autobackup/2011_08_02/o1_mf_s_758133684_73jvr5px_.bkp
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/autobackup/2011_08_02/o1_mf_s_758127608_73jot9x0_.bkp
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/autobackup/2011_08_02/o1_mf_s_758109276_73j3xfom_.bkp
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/autobackup/2011_08_02/o1_mf_s_758129928_73jr2s7p_.bkp
File Name: /opt/oracle/flash_recovery_area/LCRSDEV/autobackup/2011_07_22/o1_mf_s_757164997_72m9rqw3_.bkp
using channel ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 08/03/2011 12:53:19
RMAN-20208: UNTIL CHANGE is before RESETLOGS change
Edited by: K Doyle on Aug 3, 2011 10:22 AM -
Problem in performing multiple Point-In-Time Database Recovery using RMAN
Hello Experts,
I am getting an error while performing database point in time recovery multiple times using RMAN. Details are as follows :-
Environment:
Oracle 11g, ASM,
Database DiskGroups : DG_DATA (Data files), DG_ARCH(Archive logs), DG_REDO(Redo logs Control file).
Snapshot DiskGroups :
Snapshot1 (taken at 9 am): SNAP1_DATA, SNAP1_ARCH, +SNAP1_REDO
Snapshot2 (taken at 10 am): SNAP2_DATA, SNAP2_ARCH, +SNAP2_REDO
Steps performed for point in time recovery:
1. Restore control file from snapshot 2.
RMAN> RESTORE CONTROLFILE from '+SNAP2_REDO/orcl/CONTROLFILE/Current.256.777398261';
2. For 2nd recovery, reset incarnation of database to snapshot 2 incarnation (Say 2).
3. Catalog data files from snapshot 1.
4. Catalog archive logs from snapshot 2.
5. Perform point in time recovery till given time.
STARTUP MOUNT;
RUN {
SQL "ALTER SESSION SET NLS_DATE_FORMAT = ''dd-mon-yyyy hh24:mi:ss''";
SET UNTIL TIME "06-mar-2013 09:30:00";
RESTORE DATABASE;
RECOVER DATABASE;
ALTER DATABASE OPEN RESETLOGS;
Results:
Recovery 1: At 10.30 am, I performed first point in time recovery till 9:30 am, it was successful. Database incarnation was raised from *2* to *3*.
Recovery 2: At 11:10 am, I performed another point in time recovery till 9:45 am, while doing it I reset the incarnation of DB to *2*, it failed with following error :-
Starting recover at 28-FEB-13
using channel ORA_DISK_1
starting media recovery
media recovery failed
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 03/06/2013 11:10:57
ORA-00283: recovery session canceled due to errors
RMAN-11003: failure during parse/execution of SQL statement: alter database recover if needed
start until time 'MAR 06 2013 09:45:00'
ORA-00283: recovery session canceled due to errors
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: '+DG_REDO/orcl/onlinelog/group_1.257.807150859'
ORA-17503: ksfdopn:2 Failed to open file +DG_REDO/orcl/onlinelog/group_1.257.807150859
ORA-15012: ASM file '+DG_REDO/orcl/onlinelog/group_1.257.807150859' does not exist
Doubts:
1. Why did recovery failed 2nd time, but not 1st time and why is RMAN looking for online redo log group_1.257.807150859 in 2nd recovery ?
3. I tried restoring control file from AutoBackup, in that case both 1st and 2nd recovery succeeded.
However for this to work, I always need to keep the AutoBackup feature enabled.
How reliable is control file AutoBackup ? Is there any alternative to using AutoBackup, can I restore control file from snapshot backup only ?
4. If I restore control file from AutoBackup, then from what point of time/SCN does RMAN restores the control file ?
Please help me out in this issue.
Thanks.992748 wrote:
Hello experts,
I'm little newbie to RMAN recovery. Please help me in these doubts:
1. If I have datafiles, archive logs & control files backup, but current online REDO logs are lost, then can I perform incomplete database recovery ?yes, if you have backups of everything else
2. Till what maximum time/scn can incomplete database recovery be performed ??Assuming the only thing lost is the redo logs, you can recover to the last scn in the last archivelog.
3. What is role of online REDO logs in incomplete database recovery ? They provide the final redo changes - the ones that have not been written to archivelogs
Are they required for incomplete recovery ?It depends on how much incomplete recovery you need to do.
Think of all of your changes as a constant stream of redo information. As a redolog fills, it is copied to archive, then (eventually) reused. over time, your redo stream is in archivelog_1, continuing into archvivelog_2, then to 3, and eventually, when you get to the last archivelog, into the online redo. A recovery will start with the oldest necessary point in the redo stream and continue forward. Whether or not you need the online redo for a PIT recovery depends on how far forward you need to recover.
But you should take every precaution to prevent loss of online redo logs .. starting with having multiple members in each redo group ... and keeping those multiple members on physically separate disks. -
One database with multiple instance names
Dear all,
We would be very happy if anyone can provide me with some information of how RMAN operates.
Current situation: we have 2 machines running Oracle9i with just one database. The production database is "replicated" using EMC's TimeFinder/Snap. The differences are:
1. production database directory structure is slightly different than the replicated one: /usr/oraprod and /usr/orasnap respectively.
2. their pfiles are different: besides the differences in files location (controlfile, dumps,...), the instance_name are different (oraprod and orasnap respectively), but their db_name must be equal, which is oraprod.
3. at startup of the orasnap instance, all datafiles and redolog files must be adjusted/renamed to the orasnap directory structure (using a number of: alter database rename file) and the temporary tablespace needs to be recreated.
The orasnap instance is now ready for use... but problems arises within the RMAN repository. The oracat DB is the rman catalog. Connection to rman is done in this way:
$ORACLE_HOME/bin/rman target "sys/<password>@oraprod" CATALOG "catuser/<password>@oracat"
But "report schema;", whether the target is oraprod or orasnap, lists files which has the orasnap directory structure.
If the target is oraprod, then I expect to see the directory structure of oraprod and NOT the that of orasnap.
Did I overlooked something in here?
All help would be appreciated...
ps: see also my previous thread: "RMAN stops registering backups"Hi Ebrian,
Another funny thing of RMAN's incarnations: rman seems not to be able to give a detailed backup listing (or restore some files) of the incarnation datafiles like:
RMAN> list backup;
BS Key Type LV Size Device Type Elapsed Time Completion Time
9266 Full 55G SBT_TAPE 00:41:37 19-NOV-07
BP Key: 9267 Status: AVAILABLE Tag: TAG20071119T021235
Piece Name: db_ORAPROD11771177639022355639022355
Controlfile Included: Ckp SCN: 4023549447 Ckp time: 19-NOV-07
List of Datafiles in backup set 9266
File LV Type Ckp SCN Ckp Time Name
1 Full 4023549460 19-NOV-07 /usr/oradata/oraprod/oradata2/system01.dbf
44 Full 4023549460 19-NOV-07 /usr/oradata/oraprod/oradata2/JAFFA_TSB_2.dbf
49 Full 4023549460 19-NOV-07 /usr/oradata/oraprod/oradata2/JAFFA_TSB_1.dbf
50 Full 4023549460 19-NOV-07 /usr/oradata/oraprod/oradata2/JAFFA_TSB.dbf
51 Full 4023549460 19-NOV-07 /usr/oradata/oraprod/oradata2/BLOB_TSP.dbf
Instead, we have only:
RMAN> list incarnation;
List of Database Incarnations
DB Key Inc Key DB Name DB ID CUR Reset SCN Reset Time
8357 8408 ORASNAP 2706083210 NO 1 06-MAR-06
8357 8358 ORASNAP 2706083210 YES 4014480736 15-NOV-07
8569 8620 ORASNAP 2706169607 NO 1 06-MAR-06
8569 8570 ORASNAP 2706169607 YES 4016907657 16-NOV-07
8990 9041 ORASNAP 2706322688 NO 1 06-MAR-06
8990 8991 ORASNAP 2706322688 YES 4020564274 17-NOV-07
3336 3337 ORAPROD 4063199190 YES 1 06-MAR-06
To know what is in (8990, 8991), we need to request:
SQL> select dbinc_key, fname from dfatt where dbinc_key = 8991
So, how can we treat incarnations? List, restore, ... -
Dear gurus,
Situation: we have one oraprod production DB. Daily a snapshot is made from this instance with the name orasnap. This orasnap has only 1 day life time. For this orasnap, a new DBID is generated daily using the nid utility. After this, the orasnap is registered in the rman catalog (oracat) and backuped successfully. Please refer to my previous thread: One database with multiple instance names
RMAN> connect target /
RMAN> list incarnation;
List of Database Incarnations
DB Key Inc Key DB Name DB ID CUR Reset SCN Reset Time
8357 8408 ORASNAP 2706083210 NO 1 06-MAR-06
8357 8358 ORASNAP 2706083210 YES 4014480736 15-NOV-07
8569 8620 ORASNAP 2706169607 NO 1 06-MAR-06
8569 8570 ORASNAP 2706169607 YES 4016907657 16-NOV-07
8990 9041 ORASNAP 2706322688 NO 1 06-MAR-06
8990 8991 ORASNAP 2706322688 YES 4020564274 17-NOV-07
3336 3337 ORAPROD 4063199190 YES 1 06-MAR-06
RMAN> set dbid=2706083210;
executing command: SET DBID
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of CSET command at 11/21/2007 14:58:24
RMAN-06188: cannot use command when connected to a mounted target database
Is there a way to produce a backup list of these orasnap incarnations (and hence to restore it), a kind of "list backup database orasnap" or "reset database to incarnation 8358"?
Why are the lines displayed in which the Current incarnation column is set to NO?
We also tried these:
$ rman catalog catuser/catpassw@oracat
RMAN> set dbid=2706083210;
executing command: SET DBID
RMAN> list backup;
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of list command at 11/21/2007 15:02:32
RMAN-06171: not connected to target database
So connect to oraprod first:
RMAN> connect target sys/syspassw@oraprod;
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-06189: current DBID 2706083210 does not match target mounted database (4063199190)
In the oracat DB we found these tables (in the catalog tablespace) containing:
AL ==> archivelogs
DB ==> DBIDs
DFATT ==> list of incarnations datafiles
ORL ==> redologs
TS ==> tablespaces
Please help...Is it possible to restore the database to the previous incarnation?Yes, Why not?
And does the SCN numbers continue from the older incarnation to the new incarnation of the database?What do you mean by saying this ?
hare krishna
Alok -
Un register and register database again in the same catalog
Dear All,
I've a requirement to Un-register the existing database from the catalog by removing all its information, and immediately registering the same database in the same catalog.
Please advice How to unregister and register again by retaining the backup files that are on tape.
Immeidate reply is highly appreciated.
Thankshttp://download-west.oracle.com/docs/cd/B10501_01/server.920/a96566/rcmrepos.htm#442604
Unregistering a Target Database from the Recovery Catalog
RMAN can unregister a database as well as register it. Make sure this procedure is what you intend, because if you make a mistake, then must reregister the database. In this case, you lose any metadata that is older than the CONTROLFILE_RECORD_KEEP_TIME setting in the target database control file.
To unregister a database:
1. Start RMAN and connect to the target database. Note down the DBID value that is displayed when you use RMAN to connect to the target database. For example, enter:
% rman TARGET / CATALOG rman/cat@catdb
connected to target database: RDBMS (DBID=1237603294)
connected to recovery catalog database
2. List the copies and backup sets recorded in the repository (refer to "Listing RMAN Backups, Copies, and Database Incarnations"). For example, enter:
LIST BACKUP SUMMARY;
List of Backups
===============
Key TY LV S Device Type Completion Time #Pieces #Copies Tag
19 B A A DISK 08-FEB-02 1 1 TAG20020208T155239
20 B F A DISK 08-FEB-02 1 1 TAG20020208T155242
21 B A A DISK 08-FEB-02 1 1 TAG20020208T155331
22 B A A DISK 08-FEB-02 1 1 TAG20020208T155604
3. Run DELETE statements to delete all existing physical backups (refer to "Deleting Backups and Copies"). For example:
DELETE BACKUP DEVICE TYPE sbt;
DELETE BACKUP DEVICE TYPE DISK;
RMAN will list the backups that it intends to delete and prompt for confirmation before deleting them.
4. Use SQL*Plus to connect to the recovery catalog database as the catalog owner, then execute the following query in the recovery catalog to find the correct row of the DB table, setting DB_ID equal to the value you obtained from step 1. For example, enter:
% sqlplus rman/cat@catdb
SQL> SELECT DB_KEY, DB_ID FROM DB WHERE DB_ID = 1237603294;
This query should return exactly one row.
DB_KEY DB_ID
1 1237603294
1 row selected.
5. While still connected to the recovery catalog, enter the following, where DB_KEY and DB_ID are the corresponding columns from the row you got from the query in step 4:
SQL> EXECUTE dbms_rcvcat.unregisterdatabase(db_key, db_id)
For example, enter:
SQL> EXECUTE dbms_rcvcat.unregisterdatabase(1, 1237603294)Aron -
RMAN catalog fails to show target database information when in nomount mode
Hello everyone, I am trying to restore a dev. database from its own backup taken a week back. The DB is in noarchivelog mode and recently 2 of the datafiles were removed from the files system and thus the need to restore the DB from its backup. However rest of the files and control files are intact.
Now, when I put the database in mount mode and connect to the catalog then I can see the DB's incarnation;
:->rman catalog cde01_rman4/xxxxxxx@prman10g target /
Recovery Manager: Release 10.2.0.3.0 - Production on Thu Jun 11 13:54:40 2009
Copyright (c) 1982, 2005, Oracle. All rights reserved.
connected to target database: EGVBFI2 (DBID=4238332493, not open)
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
84789 84883 EGVBFI2 4238332493 PARENT 2478183021921 17-JAN-04
84789 84790 EGVBFI2 4238332493 CURRENT 2498633332010 10-OCT-07
RMAN>
However I am not able to see DB incarnation in the RMAN catalog if I put the DB in nomount mode (which is required to recover DB);
:->rman catalog cde01_rman4/xxxxxx@prman10g target /
Recovery Manager: Release 10.2.0.3.0 - Production on Thu Jun 11 13:58:29 2009
Copyright (c) 1982, 2005, Oracle. All rights reserved.
connected to target database: egvbfi2 (not mounted)
connected to recovery catalog database
RMAN> list incarnation;
RMAN>
Please advice?
Thanks,
JairajHi,
You won't be able to see incarnation information when the DB is in "nomount" since the incarnation is written in the control file. I don't think the catalog has this information.
Anyway, in order to restore datafiles, the instance must be mounted, so you should be OK.
Mount the instance and just restore the datafiles.
Liron Amitzi
Senior DBA consultant
link: [www.dbsnaps.com]
link: [www.obriumsoftware.com] -
Checkpoint SCN in backupset belongs to different incarnation
Reallly stuck with this one :( We are on Oracle 10.2.0.4, Solaris 5.3). Took full backup + archivelogs on Server A. Copied backup to server B, where trying to restore via the following method:
1. Restore controlfile:
Rman target /
Startup nomount;
Restore controlfile from ‘/directory_name/c-control_file’2. Catalog backuppieces:
RMAN> alter database mount;
RMAN> catalog backuppiece ‘/new_directory/backup_piece';3.Crosschecking backup:
RMAN> crosscheck backup;
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=656 devtype=DISK
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=/data/scratch/KRONOS/backup/anya/datafiles.rman recid=74 stamp=745857935
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=/data/scratch/KRONOS/backup/anya/arch_KDEV_g8m78jfk_1544_20110315 recid=71 stamp=745857003
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=/data/scratch/KRONOS/backup/anya/arch_KDEV_g9m78jfs_1545_20110315 recid=72 stamp=745857053
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=/data/scratch/KRONOS/backup/anya/arch_KDEV_gam78jg5_1546_20110315 recid=73 stamp=745857069
Crosschecked 4 objects4. Backup is AVAILABLE
RMAN> list backup of database;
using target database control file instead of recovery catalog
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
61 Full 21.00G DISK 00:05:43 15-MAR-11
BP Key: 74 Status: AVAILABLE Compressed: NO Tag: TAG20110315T040105
Piece Name: /data/scratch/KRONOS/backup/anya/datafiles.rman
List of Datafiles in backup set 61
File LV Type Ckp SCN Ckp Time Name
1 Full 29951409518 15-MAR-11 /data/dbf/kdev/system01.dbf
2 Full 29951409518 15-MAR-11 /data/dbf/kdev/tkcs1.dbf
3 Full 29951409518 15-MAR-11 /data/dbf/kdev/tkcs2.dbf
4 Full 29951409518 15-MAR-11 /data/dbf/kdev/tkcs3.dbf
5 Full 29951409518 15-MAR-11 /data/dbf/kdev/tkcs4.dbf
6 Full 29951409518 15-MAR-11 /data/dbf/kdev/tkcs5.dbf
7 Full 29951409518 15-MAR-11 /data/dbf/kdev/tkcs6.dbf
8 Full 29951409518 15-MAR-11 /data/dbf/kdev/tkcs7.dbf
9 Full 29951409518 15-MAR-11 /data/dbf/kdev/tkcs9.dbf
10 Full 29951409518 15-MAR-11 /data/dbf/kdev/tkcs8.dbf
72 Full 29951409518 15-MAR-11 /data/dbf/kdev/sysaux01.dbf
81 Full 29951409518 15-MAR-11 /data/dbf/kdev/undo01.dbf
82 Full 29951409518 15-MAR-11 /data/dbf/kdev/undo02.dbf
83 Full 29951409518 15-MAR-11 /data/dbf/kdev/undo03.dbf
84 Full 29951409518 15-MAR-11 /data/dbf/kdev/undo04.dbf
85 Full 29951409518 15-MAR-11 /data/dbf/kdev/undo05.dbfWe can see that backup SCN is *29951409518*
4. Listing incarnation of database:
RMAN> list incarnation of database;
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
1 1 KDEV 763526018 PARENT 29215810456 15-DEC-10
2 2 KDEV 763526018 CURRENT 29215838581 15-DEC-10Notice how this incarnation is different *29215838581* from backup SCN of *29951409518*. So when I run restore/recover, it fails:
set until sequence 3289;
set newname for datafile 2 to '/data/scratch/KRONOS/backup/anya/tkcs1.dbf';
set newname for datafile 3 to '/data/scratch/KRONOS/backup/anya/tkcs2.dbf';
set newname for datafile 4 to '/data/scratch/KRONOS/backup/anya/tkcs3.dbf';
set newname for datafile 5 to '/data/scratch/KRONOS/backup/anya/tkcs4.dbf';
set newname for datafile 6 to '/data/scratch/KRONOS/backup/anya/tkcs5.dbf';
set newname for datafile 7 to '/data/scratch/KRONOS/backup/anya/tkcs6.2> dbf';
set newname for datafile 8 to '/data/scratch/KRONOS/backup/anya/tkcs7.dbf';
set newname for datafile 9 to '/data/scratch/KRONOS/backup/anya/tkcs9.dbf';
set newname for datafile 10 to '/data/scratch/KRONOS/backup/anya/tkcs8.dbf';
set newname for datafile 1 to '/data/scratch/KRONOS/backup/anya/system01.dbf';
set newname for datafile 1 to '/data/scratch/KRONOS/backup/anya/undo01.dbf';
set newname for datafile 82 to '/data/scratch/KRONOS/backup/anya/undo02.dbf';
set newname for datafile 83 to '/data/scrat3> ch/KRONOS/backup/anya/undo03';
set newname for datafile 84 to '/data/scratch/KRONOS/backup/anya/undo04';
set newname for datafile 85 to '/data/scratch/KRONOS/backup/anya/undo05.dbf';
set newname for datafile 72 to '/data/scratch/KRONOS/backup/anya/sysaux01.dbf';
restore database;
switch datafile all;
recover database;
alter database open resetlogs;
release channel c1;
}Error:
Starting restore at 15-MAR-11
released channel: c1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 03/15/2011 15:27:02
RMAN-06026: some targets not found - aborting restore
RMAN-06023: no backup or copy of datafile 85 found to restore
RMAN-06023: no backup or copy of datafile 84 found to restore
RMAN-06023: no backup or copy of datafile 83 found to restore
RMAN-06023: no backup or copy of datafile 82 found to restore
RMAN-06023: no backup or copy of datafile 81 found to restore
RMAN-06023: no backup or copy of datafile 72 found to restore
RMAN-06023: no backup or copy of datafile 10 found to restore
RMAN-06023: no backup or copy of datafile 9 found to restore
RMAN-06023: no backup or copy of datafile 8 found to 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 restoreHow do I fix this? Thank you!!!!Got 3289 from disk, registered via RMAN as follows:
RMAN> catalog start with '/data/scratch/KRONOS/backup/anya/arch/KRNTSTORA1';
searching for all files that match the pattern /data/scratch/KRONOS/backup/anya/arch/KRNTSTORA1
List of Files Unknown to the Database
=====================================
File Name: /data/scratch/KRONOS/backup/anya/arch/KRNTSTORA1/o1_mf_1_3289_6qyhlwx0_.arc
Do you really want to catalog the above files (enter YES or NO)? yes
cataloging files...
cataloging done
List of Cataloged Files
=======================
File Name: /data/scratch/KRONOS/backup/anya/arch/KRNTSTORA1/o1_mf_1_3289_6qyhlwx0_.arcRan restore/recovery script:
RMAN> run {
2> allocate channel c1 type disk;
3> set until sequence 3290;
4> set newname for datafile 00002 to '/data/scratch/KRONOS/backup/anya/tkcs1.dbf';
set newname for datafile 00003 to '/data/scratch/KRONOS/backup/anya/tkcs2.dbf';
set newname for datafile 00004 to '/data/scratch/KRONOS/backup/anya/tkcs3.dbf';
set newname for datafile 00005 to '/data/scratch/KRONOS/backup/anya/tkcs4.dbf';
set newname for datafile 00006 to '/data/scratch/KRONOS/backup/anya/tkcs5.dbf';
set newname for datafile 00007 to '/data/scratch/KRONOS/backup/anya/tkcs6.dbf';
set newname for datafile 00008 to '/data/scratch/KRONOS/backup/anya/tkcs7.dbf';
set newname for datafile 00009 to '/data/scratch/KRONOS/backup/anya/tkcs9.dbf';
set newname for datafile 00010 to '/data/scratch/KRONOS/backup/anya/tkcs8.dbf';
set newname for datafile 00001 to '/data/scratch/KRONOS/backup/anya/system.dbf';
set newname for datafile 00081 to '/data/scratch/KRONOS/backup/anya/undo01.dbf';
set newname for datafile 00082 to '/data/scratch/KRONOS/backup/anya/undo02.dbf';
set newname for datafile 00083 to '/data/scratch/KRONOS/backu5> p/anya/undo03';
set newname for datafile 00084 to '/data/scratch/KRONOS/backup/anya/undo04';
set newname for datafile 00085 to '/data/scratch/KRONOS/backup/anya/undo05.dbf';
set newname for datafile 00072 to '/data/scratch/KRONOS/backup/anya/sysaux01.dbf
6> 7> 8> 9> 10> 11> 12> 13> 14> 15> 16> 17> 18> 19> 20> 21>
22> restore database;
23> switch datafile all;
24> recover database;
25> alter database open resetlogs;
26> release channel c1;
27> }
using target database control file instead of recovery catalog
allocated channel: c1
channel c1: sid=656 devtype=DISK
executing command: SET until clause
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
Starting restore at 16-MAR-11
channel c1: starting datafile backupset restore
channel c1: specifying datafile(s) to restore from backup set
restoring datafile 00001 to /data/scratch/KRONOS/backup/anya/system.dbf
restoring datafile 00002 to /data/scratch/KRONOS/backup/anya/tkcs1.dbf
restoring datafile 00003 to /data/scratch/KRONOS/backup/anya/tkcs2.dbf
restoring datafile 00004 to /data/scratch/KRONOS/backup/anya/tkcs3.dbf
restoring datafile 00005 to /data/scratch/KRONOS/backup/anya/tkcs4.dbf
restoring datafile 00006 to /data/scratch/KRONOS/backup/anya/tkcs5.dbf
restoring datafile 00007 to /data/scratch/KRONOS/backup/anya/tkcs6.dbf
restoring datafile 00008 to /data/scratch/KRONOS/backup/anya/tkcs7.dbf
restoring datafile 00009 to /data/scratch/KRONOS/backup/anya/tkcs9.dbf
restoring datafile 00010 to /data/scratch/KRONOS/backup/anya/tkcs8.dbf
restoring datafile 00072 to /data/scratch/KRONOS/backup/anya/sysaux01.dbf
restoring datafile 00081 to /data/scratch/KRONOS/backup/anya/undo01.dbf
restoring datafile 00082 to /data/scratch/KRONOS/backup/anya/undo02.dbf
restoring datafile 00083 to /data/scratch/KRONOS/backup/anya/undo03
restoring datafile 00084 to /data/scratch/KRONOS/backup/anya/undo04
restoring datafile 00085 to /data/scratch/KRONOS/backup/anya/undo05.dbf
channel c1: reading from backup piece /data/scratch/KRONOS/backup/anya/datafiles.rmanOracle restored/recovered without errors :) Thank you! However, I dont understand why 3289 was not included in the backup when it is needed for recovery. Database and archvielog backup takes place in the same script as follows:
run
allocate channel c1 type disk;
crosscheck archivelog like '/data/flash_recovery_area/KRNTSTORA1%';
sql 'alter system archive log current';
backup database format '${BACKUP_DIR}/datafiles__${BACKUP_TYPE}_${TIMESTAMP}%p_%s.rman';
backup archivelog like '/data/flash_recovery_area/KRNTSTORA1%' format '${BACKUP_DIR}/arch_%d_%u_%s_%T';
backup current controlfile format '${BACKUP_DIR}/${ORACLE_SID}_${TIMESTAMP}_CTL';
delete noprompt archivelog like '/data/flash_recovery_area/KRNTSTORA1%' completed before 'sysdate-4' backed up 1 times to device type disk
}confusing :( -
When to restore controlfile, rman is complaining database not mounted?
to restore controlfile, shouldn`t the database be in NOMOUNT status?
if yes, then why rman is complaining ORA-01507?
where I went wrong? Please advise.
C:\Documents and Settings\PhoenixBai>rman target / nocatalog
Recovery Manager: Release 10.2.0.1.0 - Production on Tue Dec 14 10:35:51 2010
Copyright (c) 1982, 2005, Oracle. All rights reserved.
connected to target database (not started)
RMAN> startup nomount;
Oracle instance started
Total System Global Area 612368384 bytes
Fixed Size 1250428 bytes
Variable Size 234883972 bytes
Database Buffers 369098752 bytes
Redo Buffers 7135232 bytes
RMAN> restore controlfile until time 'sysdate-1.5/24';
Starting restore at 14-DEC-10
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=157 devtype=DISK
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 12/14/2010 10:36:12
ORA-01507: database not mounted
RMAN>it doesn`t. I tried long before this one.
the dilemma i am facing is that I need to recover to the time which was included in incarnation 2.
And to be able to reset database to incarnation 2, i need to startup MOUNT the database.
And once you startup mount the database RESTORE CONTROLFILE won`t work any more.
below is the standard procedure, documented on 10gR2 doc, but still, i am getting errors:
Why it is throwing errors? HOw can I fix?
RMAN> alter database mount;
database mounted
RMAN> list incarnation of database orcl;
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
1 1 ORCL 1264908153 PARENT 1 30-AUG-05
2 2 ORCL 1264908153 PARENT 534907 07-DEC-10
3 3 ORCL 1264908153 CURRENT 56335397 14-DEC-10
RMAN> reset database to incarnation 2;
database reset to incarnation 2
RMAN> restore database until scn 56335390;
Starting restore at 14-DEC-10
using channel ORA_DISK_1
creating datafile fno=6 name=E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\ETLTBS01.ORA
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00001 to E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSTEM01.DBF
restoring datafile 00002 to E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\UNDOTBS01.DBF
restoring datafile 00003 to E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSAUX01.DBF
restoring datafile 00004 to E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\USERS01.DBF
restoring datafile 00005 to E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\EXAMPLE01.DBF
channel ORA_DISK_1: reading from backup piece E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORCL\BACKUPSET\2
MF_NNND1_TAG20101213T132300_6JCCFO2X_.BKP
channel ORA_DISK_1: restored backup piece 1
piece handle=E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORCL\BACKUPSET\2010_12_13\O1_MF_NNND1_TAG20101213
O2X_.BKP tag=TAG20101213T132300
channel ORA_DISK_1: restore complete, elapsed time: 00:00:55
Finished restore at 14-DEC-10
RMAN> recover database until scn 56335390;
Starting recover at 14-DEC-10
using channel ORA_DISK_1
starting media recovery
media recovery failed
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 12/14/2010 11:36:14
ORA-00283: recovery session canceled due to errors
RMAN-11003: failure during parse/execution of SQL statement: alter database recover if needed
start until change 56335390
ORA-00283: recovery session canceled due to errors
ORA-38727: FLASHBACK DATABASE requires a current control file.Edited by: PhoenixBai on Dec 14, 2010 11:37 AM -
OPEN RESETLOGS and incarnation....
Hi ,
I try to understand the use/function of OPEN RESETLOGS but the extensive use of the word 'incarnation' sets obstacles....
The following lines are from :
Oracle® Database Backup and Recovery Advanced User's Guide
10g Release 2 (10.2)
Part Number B14191-02
Paragraph:
Resetting the Database Incarnation in the Recovery Catalog
When you run either the RMAN command or the SQL statement ALTER
DATABASE OPEN RESETLOGS, you create a new incarnation of the database.
You can access a record of the new incarnation in the
V$DATABASE_INCARNATION view of the target database.
If you run the RMAN command or the SQL statement ALTER DATABASE OPEN
RESETLOGS, then a new database incarnation record is automatically created in
the recovery catalog. The database also implicitly and automatically issues a
RESET DATABASE command, which specifies that this new incarnation of the
database is the current incarnation. All subsequent backups and log archiving
done by the target database is associated with the new database incarnation.Can anybody explain ....????
Thanks....a lot
SimIncarnation here has the same meaning here that you would find in dictionary.
What it means is that now after "incarnation" this database is as good as a new database since all the redolog sequence, archive log sequence etc will be reset to start which they were during the time of creation (or last incarnation) of the database.
Lets assume u create a database. Lets call this as Life1 of the database.
Now a year later because of some reason you have to do an incomplete recovery and you open you database using resetlogs. Lets say this is Life2 of the database
Now after some time you do that again. This is Life3 of the database.
But there are times when you might want to bring the database back to Life1 and Life2. It is possible but because Oracle maintains all the Lives i.e INCARNATION of the database.
The concept of incarnation is important due to many reasons but for you understanding you can take it as life cycle of a database.
Thanks,
Ankit.
Maybe you are looking for
-
Animated Gif/movie not following build order
Animated Gif/movies do not build in proper order. For example, I have an animated clock that is suppose to come in as Build No 29 and run. However, it loads as though it is Build item No 1. It does run at the proper time in the build. Must I hide it
-
RAW - Manufacturers should know you want to use Aperture.
It seems to me that we should also be telling our cameras manufacturers to quickly release whatever proprietary RAW information Apple needs in order to support a particular camera. Here's something I posted earlier this morning. "In very simple terms
-
Pages created by other applications
I have some applications which create html from within them to post on the web. I have my own domain, and have had no issues creating pages with links to these pages. With iWeb, how do I create a dead link, so I can add the pages to the site folder?
-
Need to know how to create 'contours' around artwork for printing?
Hello Friends, First, let it be known that I am new to InDesign. Actually, this will be the first time I will be using it! I created a logo in Photoshop, for a friend to take to the printers which would be transferred to a plastic sticker. The person
-
I Am having a problem with my storage on my iphone 5 i am trying to update my Tom Tom app and its telling me I haven't got enough storage although when I go into manage storage I I have Total storage 25.oo GB. and available 15.8 Gb ??????