8i | 9i | 10g | 11g | 12c | 13c | 18c | 19c | 21c | 23c | Misc | PL/SQL | SQL | RAC | WebLogic | Linux

Duplicate a Database Using RMAN in Oracle Database 11g Release 2

This article is an update of a previous Oracle 9i article.

Introduction
Backup-Based Duplication
Active Database Duplication
RMAN-06054 : Unknown Archived Log

Introduction

RMAN has the ability to duplicate, or clone, a database from a backup or from an active database. It is possible to create a duplicate database on a remote server with the same file structure, a remote server will a different file structure or the local server with a different file structure.

The article assumes the duplicate database is being created on a separate server, using the same SID (DB11G) and the same file structure as the source database. Explanations of several other scenarios are available here.

If you are duplicating to the same machine you need to make sure the SID and DB_NAME of the duplicate does not match the source database, and you need to make sure the DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT parameters are set correctly, so the duplicate doesn't attempt to use the same directory structure as source database. There may be other parameters to consider including the location of the fast recovery area and admin directories. Check the contents of your SPFILE and read the documentation appropriate for your scenario.

Backup-Based Duplication

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

All subsequent actions occur on the server running the duplicate database.

Create a password file for the duplicate instance.

$ orapwd file=/u01/app/oracle/product/11.2.0/db_1/dbs/orapwDB11G password=password entries=10

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.

# Added to the tnsnames.ora
DB11G-SOURCE =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = ol5-112-dup1)(PORT = 1521))
    )
    (CONNECT_DATA =
      (ORACLE_SID = DB11G)
    )
  )

Create a PFILE for the duplicate database. Since we are duplicating the database onto a separate server with the same filesystem as the original, we don't need to convert the file names. In this case, the PFILE is called "/tmp/initDB11G.ora".

# Minimum Requirement.
DB_NAME='DB11G'

# Convert file names to allow for different directory structure if necessary.
# Include Block Change Tracking file if used.
#DB_FILE_NAME_CONVERT='/u01/app/oracle/oradata/DB11G/','/u01/app/oracle/oradata/NEWSID/'
#LOG_FILE_NAME_CONVERT='/u01/app/oracle/oradata/DB11G/','/u02/app/oracle/oradata/NEWSID/'

We don't need all the other parameters as the clone will copy the SPFILE from the primary database. If you are duplicating a database on the same machine you will probably need to create a PFFILE/SPFILE manually from the primary database SPFILE, manually change the values and avoid the SPFILE clause in the duplicate command.

Create any directories necessary for start the duplicate database.

$ mkdir -p /u01/app/oracle/oradata/DB11G
$ mkdir -p /u01/app/oracle/fast_recovery_area/DB11G
$ mkdir -p /u01/app/oracle/admin/DB11G/adump

Make the backup files from the source database available to the destination server. That can be done by either copying them to the matching location on the destination server, or placing them on a shared drive. If you are copying the files, you may want to use the following type of commands. Notice this include the Block Change Tracking files and Flashback Logs if used.

$ scp -r oracle@ol5-112-dup1:/u01/app/oracle/fast_recovery_area/DB11G/archivelog /u01/app/oracle/fast_recovery_area/DB11G
$ scp -r oracle@ol5-112-dup1:/u01/app/oracle/fast_recovery_area/DB11G/backupset /u01/app/oracle/fast_recovery_area/DB11G
$ scp -r oracle@ol5-112-dup1:/u01/app/oracle/fast_recovery_area/DB11G/autobackup /u01/app/oracle/fast_recovery_area/DB11G

$ # If you are using Flashback Database.
$ scp -r oracle@ol5-112-dup1:/u01/app/oracle/fast_recovery_area/DB11G/flashback /u01/app/oracle/oradata/DB11G

$ # If you are using Block Change Tracking.
$ scp -r oracle@ol5-112-dup1:/u01/app/oracle/oradata/DB11G/rman_change_track.bct /u01/app/oracle/oradata/DB11G

Connect to the duplicate instance.

$ ORACLE_SID=DB11G; export ORACLE_SID
$ sqlplus / as sysdba

Start the database in NOMOUNT mode.

SQL> STARTUP NOMOUNT PFILE='/tmp/initDB11G.ora';

With the duplicate database started we can now connect to it from RMAN. For the duplication to work we must connect to the duplicate database (AUXILIARY), but depending on the type of duplication we are doing we may optionally connect to the original database (TARGET) and/or the recovery catalog (CATALOG).

$ ORACLE_SID=DB11G; export ORACLE_SID

# No target or catalog. Metadata comes from backups. Need BACKUP LOCATION in DUPLICATE command.
$ rman AUXILIARY /

# Target, but no catalog. Metadata comes from target database controlfile.
$ rman TARGET sys/password@DB11G-SOURCE AUXILIARY /

# Catalog, but no target. Metadata comes from the RMAN catalog.
$ rman CATALOG rman/password@rman-catalog AUXILIARY /

# Target and catalog. Metadata can come from the target controlfile or the catalog.
$ rman TARGET sys/password@DB11G-SOURCE CATALOG rman/password@rman-catalog AUXILIARY /

We can then duplicate the database using one of the following commands. Remember, remove the SPFILE clause if you have manually created a full PFILE or SPFILE.

# Backup files are in matching location to that on the source server.
# Duplicate database to TARGET's current state using TARGET, CATALOG or both.
DUPLICATE TARGET DATABASE TO DB11G
SPFILE
NOFILENAMECHECK;

# Backup files are in matching location to that on the source server.
# Backup state (no TARGET or CATALOG)
DUPLICATE TARGET DATABASE TO DB11G
SPFILE
BACKUP LOCATION '/source/app/oracle/fast_recovery_area/DB11G'
NOFILENAMECHECK;

# Duplicate database to TARGET's state 4 days ago.
DUPLICATE TARGET DATABASE TO DB11G
UNTIL TIME 'SYSDATE-4'
SPFILE
NOFILENAMECHECK;

# Backup files are in a different location to that on the source server.
# Duplicate database to the most recent state possible using the provided backups.
# Works with just an AUXILIARY connection only.
DUPLICATE DATABASE TO DB11G
SPFILE
BACKUP LOCATION '/source/app/oracle/fast_recovery_area/DB11G'
NOFILENAMECHECK;

# Do a point-in-time clone.
DUPLICATE DATABASE TO DB11G
SPFILE
BACKUP LOCATION '/source/app/oracle/fast_recovery_area/DB11G'
NOFILENAMECHECK
UNTIL TIME "TO_DATE('2014-11-17 07:00:00', 'YYYY-MM-DD HH24:MI:SS')";

# Alter some SPFILE parameters during the clone.
DUPLICATE DATABASE TO MYCLONE
SPFILE
parameter_value_convert ('DB11G','MYCLONE')
set db_file_name_convert='/u01/oradata/db11g/','/u01/oradata/myclone/'
set log_file_name_convert='/u01/oradata/db11g/','/u01/oradata/myclone/'
set control_files='/u01/oradata/myclone/control01.ctl','/u01/oradata/myclone//control02.ctl','/u01/oradata/myclone/control03.ctl'
set db_name='MYCLONE'
set log_archive_dest_1='location=/u01/oradata/myclone/arch'
BACKUP LOCATION '/source/app/oracle/fast_recovery_area/DB11G'
NOFILENAMECHECK;

The time it takes to complete varies depending on the size of the database and the specification of the server. Once the process is finished RMAN produces a completion message and you have your duplicate instance.

Active Database Duplication

Oracle 11g introduced the ability to create duplicate databases directly without the need for a backup. This is known as active database duplication. The process is similar to the backup-based duplication, with a few exceptions.

First, and most obviously, you don't need a backup of the source system, but it does have to be in ARCHIVELOG mode.

The passwords in the password files must match for both servers, so remember to set the correct password when creating the password file on the destination server.

Both the source and destination database servers require a "tnsnames.ora" entry for the destination database. In this case I added the following to each server. The destination server still requires the source entry shown in the previous section.

# Added to the tnsnames.ora on source and destination server.
DB11G-DESTINATION =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = ol5-112-dup2)(PORT = 1521))
    )
    (CONNECT_DATA =
      (ORACLE_SID = DB11G)
    )
  )

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.

SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (GLOBAL_DBNAME = DB11G.WORLD)
      (ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1)
      (SID_NAME = DB11G)
    )
  )

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = ol5-112-dup2.localdomain)(PORT = 1521))
    )
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
    )
  )

ADR_BASE_LISTENER = /u01/app/oracle

When connecting to RMAN, you must use a connect string for both the target and auxiliary connections.

$ ORACLE_SID=DB11G; export ORACLE_SID

$ rman TARGET sys/password@DB11G-SOURCE AUXILIARY sys/password@DB11G-DESTINATION

Include the FROM ACTIVE DATABASE clause in the DUPLICATE command.

DUPLICATE DATABASE TO DB11G
  FROM ACTIVE DATABASE
  SPFILE
  NOFILENAMECHECK;

RMAN-06054 : Unknown Archived Log

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 ????

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.

For more information see:

Hope this helps. Regards Tim...

Back to the Top.