Introduction
We just wrapped up our 10g RMAN testing. To test recovery using our RMAN backup, we have used the RMAN DUPLICATE command to create a duplicate database using this backup. I have noticed something about the DUPLICATE command that i have missed so far: The DUPLICATE command creates the duplicate database's controlfile using information from BOTH the existing target database's controlfile and the backup controlfile, not just the latter alone.
Test Case
1) dev10g is an existing development database that has got upgraded to 10g version
2) dev10g is in noarchivelog mode (like most development databases do)
3) dev10g is converted to archivelog mode to take a RMAN backup including full database and archivelogs backup
4) dev10g archiving is disabled (noarchivelog mode again)
5) dup10g is the proposed new database that will be created using the RMAN backup of dev10g.
6) DUPLICATE command is run on the dup10g database's host.
7) DUPLICATE command fails after restoring the datafiles.
We just wrapped up our 10g RMAN testing. To test recovery using our RMAN backup, we have used the RMAN DUPLICATE command to create a duplicate database using this backup. I have noticed something about the DUPLICATE command that i have missed so far: The DUPLICATE command creates the duplicate database's controlfile using information from BOTH the existing target database's controlfile and the backup controlfile, not just the latter alone.
Test Case
1) dev10g is an existing development database that has got upgraded to 10g version
2) dev10g is in noarchivelog mode (like most development databases do)
3) dev10g is converted to archivelog mode to take a RMAN backup including full database and archivelogs backup
4) dev10g archiving is disabled (noarchivelog mode again)
5) dup10g is the proposed new database that will be created using the RMAN backup of dev10g.
6) DUPLICATE command is run on the dup10g database's host.
7) DUPLICATE command fails after restoring the datafiles.
From the logfile.....
contents of Memory Script:
{
set until scn 8321617961105;
recover
clone database
noredo
,
delete archivelog
;
}
..
..
..
RMAN-00571: =======================================
RMAN-00569: ===== ERROR MESSAGE STACK FOLLOWS =====
RMAN-00571: =======================================
RMAN-03002: failure of Duplicate Db command at 06/09/2008 23:41:15
RMAN-03015: error occurred in stored script Memory Script
RMAN-06136: ORACLE error from auxiliary database:
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/dbfs/oracle/oradata/dev10g_sys01.dbf'
Problem
The target database dev10g was converted to noarchivelog mode in the 4th step above after the RMAN backup was taken. However, the DUPLICATE command *considers* there are no archivelog files to be applied to dup10g because the target database's controlfile shows the database is in noarchivelog mode. Though dev10g's archivelog files were backed up when the backup commands were run in the 3rd step above, DUPLICATE generates an internal script that forbids the archivelog apply because the target database's current controlfile shows its in noarchivelog mode.
Solution
Enable archiving in the target database when DUPLICATE is running, even though its a development database that does not require archiving. It can be disabled once the duplicate database is created successfully.
One may not encounter this problem when the target database is a production one, because production databases are usually in archivelog mode; however, one may encounter this problem when the target database is a development one when its archiving is disabled after an RMAN backup.
The target database dev10g was converted to noarchivelog mode in the 4th step above after the RMAN backup was taken. However, the DUPLICATE command *considers* there are no archivelog files to be applied to dup10g because the target database's controlfile shows the database is in noarchivelog mode. Though dev10g's archivelog files were backed up when the backup commands were run in the 3rd step above, DUPLICATE generates an internal script that forbids the archivelog apply because the target database's current controlfile shows its in noarchivelog mode.
Solution
Enable archiving in the target database when DUPLICATE is running, even though its a development database that does not require archiving. It can be disabled once the duplicate database is created successfully.
One may not encounter this problem when the target database is a production one, because production databases are usually in archivelog mode; however, one may encounter this problem when the target database is a development one when its archiving is disabled after an RMAN backup.
No comments:
Post a Comment