RMAN duplicate does change your DB_NAME !

I had a very serious issue last Friday with errors as weird as ORA-00322: log name of thread num is not current copy. After a clone from Prod to Test, the prod crashed. Both databases are located on the same server (I am not a virtualization fanatic) and clone from prod to test have been done by most of my dba readers.

What did change in 11g ?

Incredibly, in 11g, rman issues the following statement before restore

sql clone "alter system set  db_name = ''PROD'' ...
restore clone primary controlfile...

This is probably related to the capability of cloning a database without connecting to the target database.

At the end of the clone, rman is setting back the db_name to TEST and recreate the TEST controlfile

sql statement: alter system set  db_name = ''TEST'' ...
sql statement: CREATE CONTROLFILE REUSE SET DATABASE "TEST" ...
...
LOGFILE
GROUP 1 ('/.../TEST/redo1.dbf')...

So what’s wrong with this? Howcome could a clone from prod to test screw up the prod db???

Simple, the RMAN job did not complete

1) set new name, restore prod controlfile to test
2) restore issue, for instance ORA-19870: error while restoring backup piece archive1234
3) RMAN-03002: failure of Duplicate Db command

At this point, the complete restore was finished, we restored the missing archivelog, recover and open resetlog.
What happened then???
At this point, remember you still have the prod controlfile (and the prod db_name), so by doing an alter resetlogs, the production redologs will get overwritten without notice !

This is a fairly important change that could really hurt if you are cloning two databases on the same server.

In case you are trying to save a failed database clone, make sure you check db_name and also v$logfile before doing an alter database resetlogs!!!

4 thoughts on “RMAN duplicate does change your DB_NAME !”

  1. We observed RMAN doing this as well. For us, the issue is that the dbname is just not correct when the clone fails to apply the additional archive logs. We are not on the same server as we still like physical servers that are separate for PROD and DEV.

    But I am a bit confused as to how the open reset logs impacted production. You should have been connected to the clone under the SID specified and only that SID’s controlfile should have been impacted—regardless of what the dbname was internally. As long as the PROD and TEST control files were in different locations. Until we began using RMAN a lot of the dbnames and dbids for copied databases were the same in our shop. And I do not remember having an issue. RMAN certainly cares when it goes to back them up, though.

  2. Remember for duplicate there is no need for an auxiliary controlfile as the auxiliary db is in nomount status. So in 10g and before, the controlfile was created according to your *CONVERT parameters.

    In 11gR2, the controlfile of the PROD db is restored to the auxiliary, that is it is still refering PROD db file and redolog files.

    In 11.2.0.1, if you CTRL-C, loose connection (putty dies), miss one archive backup or whatever, the controlfile would still be the one restored from PROD. So any attempt to open resetlogs would overwrite the redologs.

    In 11.2.0.2, any open resetlogs will fail with an ORA error telling that the current controlfile is not usable for this DB.

    In 11.2 anyway, there is no need to manually recover and open resetlogs, as RMAN DUPLICATE is able to resume a failed duplicate operation

Leave a Reply

Your email address will not be published.


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>