RMAN DUPLICATE - Not everything is made using the CATALOG alone?

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.

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.

RMAN debug

RMAN automates Oracle database's backup and recovery processes. If you would like to know what happens inside an RMAN command,(RMAN Internals), then try the debug option. Also, when you have a case opened on any RMAN issue, the debug logfile can help a support analyst quickly locate the source of your RMAN problem.

Its very easy to turn on the debug feature.

/home/oracle/backup_testing> rman log=output.log trace=debug_info.log
RMAN> debug on
RMAN> RMAN Command 1;
RMAN> RMAN Command 2;
....
....
....RMAN> exit

The debug_info.log contains all the internal details. BTW, you will not find information about this feature in the Oracle Documentation.

central tnsnames.ora

Introduction

For hassle-free management of enterprise wide databases connection information, the connect descriptors can be stored in a centralized repository. There are several solutions to implement a centralized repository ranging from the basic tnsnames.ora that is stored on a NFS to the advanced LDAP complaint directory services implementation through OID (Oracle Internet Directory).

Problem

Several of our Oracle developers and end users rely on 3rd party tools like TOAD, SQL*Navigator to communicate with Oracle databases. We have put the tnsnames.ora containing all the oracle databases connection information for these utilities on a shared network drive in windows. This solves the problem for clients using Windows. However our system administrators do not allow NFS access on Unix servers. Due to this restriction, it has become a hassle to maintain a separate tnsnames.ora in every Unix server that hosts oracle installations(client or server). If we create a new database or change an existing database's connection settings, we have to update the tnsnames.ora on all other Unix servers with this new connection information.

Solution

While discussing in Oracle forums, i stumbled upon a specialized tool tnsManager built by Andrew Barry that acts as a simple LDAP compliant server to serve just TNS information. It is the kind of solution that i was looking for solving the problem. It is quite easy to use and has a very small footprint. The 'HOW TO' guide is here.

Conclusion

We will be implementing Oracle Identity Management (that will contain OID) by the end of the year that provides a much more sophisticated mechanism for organizing and managing centralized directory services like applications login accounts, centrally managing database connection information etc. The tnsManager utility can be a good alternative which will satisfy our basic needs for storing just the database connection information in a central tnsnames.ora until the full blown Identify Management project is implemented. Best of all its just one executable that Andrew supplies and it takes 5 minutes to install and get it going ! As far as a DBA is concerned, all he or she has to do is edit the central tnsnames.ora that is read by the tnsManager utility whenever an existing database connection settings are changed or a new database is added in the enterprise. No extra configuration necessary.