Step 1: Create a backup of the source database, if a suitable one doesn’t already exist.
$ rman target=/
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;
RMAN> BACKUP DATABASE PLUS ARCHIVELOG;
Step 2: Create a password file for the duplicate instance.
$ orapwd file=password file location. password=password entries=10
Step 3: Add the appropriate entries into the “tnsnames.ora” file in the “$ORACLE_HOME/network/admin” directory to allow connections to the target database from the duplicate server.
Step 4: The destination server requires static listener configuration in a “listener.ora” file. In this case I used the following configuration. Remember to restart or reload the listener.
Step 5: When connecting to RMAN, you must use a connect string for both the target and auxiliary connections .
$ ORACLE_SID=database_name ; export ORACLE_SID
$ rman target username/password@source auxiliary username/password@destination
Step 6: Include the FROM ACTIVE DATABASE clause in the DUPLICATE command.
DUPLICATE DATABASE TO SOURCEDBNAME FROM ACTIVE DATABASE SPFILE NOFILENAMECHECK;
Step 7: During the duplicate operation you may encounter the following error.
RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence ???? and starting SCN of ????
Step 8: Here are some things to think about when trying to resolve this.
- If this is a backup-based duplicate, it is possible you have not copied all the archived redo logs from the target to the auxiliary backup location. If you can, copy the missing logs across and try again.
- If this is a backup-based duplicate and you can’t copy across the missing archived redo logs, you may need to do a point in time duplicate, described above, to leave you in a consistent state prior to the transactions contained in the first missing log.
- If this is an active duplicate, all necessary logs should be shipped automatically from the target to the auxiliary instance. This can only fail if the archived redo logs on the target system have been removed during the clone operation. This could happen if an archived redo log backup has taken place on the target server during the clone operation and deleted the backed-up logs. If this is the case, either disable the backup of the target system during the clone operation, or stop using active duplicates.
Step 9: To open the database in the same consistent
Sql> alter database open resetlogs;
Sql> alter database open;
Step 10: Now database is ready.
