RMAN Duplicate Changes db_name
NOTE: This only applies to version 11.2.0.1. According to Note
11063122, it is fixed in 11.2.0.2.
I was cloning a database last Friday, and I had a very serious
issue with errors as weird as:
ORA-00322: log name of thread num is not
current copy.
After a clone from PROD to TEST, PROD crashed. I am not a
virtualization fanatic, so both databases are located on the same
server. I was not concerned because successful clones
from PROD to TEST have been done by most of my dba readers.
So, what changed in 11gR1 to cause this problem?
Incredibly, in 11gR1, RMAN issues the following statement before
restore:
sql clone "alter system
set db_name = ''PROD'' ...
restore clone primary controlfile...
This is likely related to the capability of cloning a database
without connecting to the target database. At the end of the clone,
RMAN is setting the db_name back to TEST and recreating 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 is wrong with this? How is it possible for a clone from
PROD to TEST screw up the production database???
Simple, the RMAN job did not complete:
- set new name, restore PROD controlfile to TEST
- restore issue, for instance:
ORA-19870: error while restoring backup piece archive1234
- RMAN-03002: failure of Duplicate Db command
At this point, the complete restore was finished. We
restored the missing archivelog, recovered and opened resetlog.
What happened then???
At this point, remember you still have the PROD controlfile and
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
to check db_name and also v$logfile before doing an ALTER
database resetlogs!!!
