RMAN Preparing The Auxiliary Instance
Preparing the Auxiliary Instance
RMAN uses an auxiliary instance to create the duplicate database. You must prepare the auxiliary instance before you begin the duplication.
Depending on your duplication scenario, you need to perform either some or the tasks that are described in this section. Preparing the auxiliary instance includes the following tasks:
1. Creating Directories for the Duplicate Database
On the destination host, you must create the directories that are used to store the duplicate database files on the destination host. This includes the directories that store the data files, control files, online redo log files, and temp files.
2. Creating an Initialization Parameter File for the Auxiliary Instance
Multiple methods are available to create the initialization parameter file that is required to start the auxiliary instance.
Use one of the following methods to create the initialization parameter file:
Create an initialization parameter file manually.
If the source database does not use a server parameter file,
you must set all the necessary parameters for the auxiliary instance in a text-based initialization parameter file
Direct RMAN to use the initialization parameter file of the source database for the auxiliary instance.
This technique is applicable only if the source database uses a server parameter file. Copying the initialization parameter file from the source database is useful when the duplicate database must use the same parameter settings as the source.
It is recommended to use a server parameter file instead of a text-based initialization parameter file for duplication.
The client-side parameter file for the auxiliary instance must reside on the same host as the RMAN client that performs the duplication.
It is recommended that you create the initialization parameter file in the default location on
On Windows, the default initialization parameter file is
On Linux the file name is
Steps to Create an Initialization Parameter File for the Auxiliary Instance
a. The initialization parameter file for the auxiliary instance must contain at least the DB_NAME and DB_DOMAIN initialization parameters.
b. Additional parameters may be specified, if required.
Ensure that the initialization parameter file is on the same host as the RMAN client that performs the duplication.
To create the initialization parameter file for the auxiliary instance:
Do one of the following:
a. Copy the initialization parameter file from the source host to the destination host, placing it in the operating system-specific default location, and then modify the DB_NAME and DB_DOMAIN initialization parameters.
If duplicating a CDB
ensure that the ENABLE_PLUGGABLE_DATABASE parameter is present and set to TRUE.
Complete these steps:
Using a text editor, create an empty file for use as a text-based initialization parameter file, and save it in the operating system-specific default location.
In the parameter file, set the DB_NAME and DB_DOMAIN initialization parameters. These are the only required parameters.
Setting the DB_DOMAIN parameter enables you to connect to the default database service when you connect with a net service name.
If the auxiliary instance is to be a CDB,
set the following parameter:
Set the various location parameters such as CONTROL_FILES and DB_RECOVERY_FILE_DEST.
If necessary, set other initialization parameters
needed for Oracle Real Application Clusters.
Profile Environment Impacting Variables:
Set the required environment variables, such as ORACLE_HOME and ORACLE_SID.
Set initialization parameters that specify the location of the duplicate database files if one of the following conditions is satisfied:
The source host and the destination host are the same (duplication to the local host).
The duplicate database uses a directory structure that is different from that of the source host to store database files.
Depending on the technique used to specify alternate names for duplicate database files, include one or more of the following parameters in the initialization parameter file:
It is recommended that you verify that all paths specified are accessible to the destination host and to the server session of the auxiliary instance.
Start SQL*Plus and connect to the auxiliary instance as a user with SYSDBA or SYSBACKUP privileges.
Start the auxiliary instance in NOMOUNT mode. If the file is in the default location, no PFILE parameter is required on SQL> STARTUP NOMOUNT; -- read only initialization parameter file
Sample Initialization Parameter File for the Auxiliary Instance
Methods of Generating Database File Names for the Duplicate Database
3. Copying the Server Parameter File from the Source Database
If the source database uses a server parameter file,
including the SPFILE option in the DUPLICATE command directs RMAN to use the server parameter file from the source database for the auxiliary instance.
For backup-based duplication
the server parameter file is restored from backups.
For active database duplication
the server parameter file is copied from the source database to the auxiliary instance.
When the source database uses a text-based initialization parameter file
use the PFILE clause in the DUPLICATE command to copy the source database's initialization parameter file to the auxiliary instance.
Server parameter file can be modified with the values that were copied or restored from the server parameter file of the source database by using the
PARAMETER_VALUE_CONVERT option of SPFILE or
SET clause of the DUPLICATE.
SET clause to change the value of the DB_FILE_NAME_CONVERT parameter in the auxiliary instance's server parameter file.
If the source database does not use a server parameter file
RMAN cannot restore a backup of the server parameter file,
you must manually create a text-based initialization parameter file, as described in Steps to Create an Initialization Parameter File for the Auxiliary Instance.
4. Creating a Password File for the Auxiliary Instance
Connections to the auxiliary instance can be established by using operating system authentication or password file authentication. For backup-based duplication, you can either create a password file or use operating system authentication to connect to the auxiliary instance. For active database duplication, you must use password file authentication.
To connect to a database by using password file authentication, you must create a password file for the database. When duplicating to a remote host, setting up a password file is mandatory. The default location for the password file is
ORACLE_HOME\database on Windows and
ORACLE_HOME/dbs on Linux and UNIX.
When you create a standby database by using RMAN duplication, password files are always copied.
In all other cases,
password files are copied only if you specify the PASSWORD FILE option in the DUPLICATE command.
Use one of the following options to create a password file for the auxiliary instance on the destination host:
1. Use operating system-specific utilities to copy the source database password file to the destination host and then rename it to match the auxiliary instance name.
This is applicable only if the source and destination hosts are on the same platform.
2. Create the password file manually. Ensure that the password for the SYSDBA and SYSBACKUP users are the same in the source database and auxiliary instance.
3. Create the password file with the orapwd utility. The SYSBACKUP option creates a SYSBACKUP entry in the new password file.
The following example creates a password file in the 12.2 format names orapworcl that is located in the default location in an operating system file:
Specify the PASSWORD FILE option on the DUPLICATE... FROM ACTIVE DATABASE command.
RMAN copies the source database password file to the destination host and overwrites any existing password file for the auxiliary instance. This technique is useful if the source database password file has multiple passwords to make available on the duplicate database.
When you use active database duplication, the password file must contain at least two passwords, for the SYS user and the SYSBACKUP user. These passwords must match the passwords in the source database.
If you create a standby database with the FROM ACTIVE DATABASE option, then RMAN always copies the password file to the standby host.
5. Establishing Oracle Net Connectivity Between the Source Database and Auxiliary Instance
Establish a connection between the source database and auxiliary instance for certain forms of duplication.
If any of the following conditions is true,
the auxiliary instance must be available through Oracle Net Services
The RMAN client is run from a host other than the destination host
If the duplication technique chosen is active database duplication
if The destination host is different from the source host
To perform active database duplication,
a. connect to the auxiliary instance with SYSDBA or SYSBACKUP privilege and by using a net service name.
b. The source database to which RMAN is connected as TARGET uses this net service name to connect directly to the auxiliary database instance.
6. To establish Oracle Net connectivity and set up a static listener
Establishing Oracle Net Connectivity Between the Source Database and Auxiliary Instance
Assume that the DB_NAME of the source database is src and the source host is src.example.com.
The DB_NAME of the auxiliary instance is dup and the auxiliary instance is created on the host dup.example.com.
Use the following steps to establish Oracle Net connectivity between the source database and the auxiliary instance:
In the tnanames.ora file of the source database, add the following entry that corresponds to the duplicate database:
dupdb = (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=dup.example.com)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=dup)))
On the destination host, create the tnsnames.ora file in the $ORACLE_HOME/admin/network folder. Add the following entry that corresponds to the source database.
srcdb = (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=src.example.com)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=src)))
7. Starting the Auxiliary Instance
The initialization parameter file that you create is used to start the auxiliary instance.
RMAN shuts down and restarts the auxiliary instance as part of the duplication.
Hence, it is a good idea to create a server-side initialization parameter file for the auxiliary instance in the default location.
If no server-side initialization parameter file in the default location
you must specify the client-side initialization parameter file with the PFILE parameter on the DUPLICATE command.
Because the auxiliary instance does not yet have a control file, so start the instance in NOMOUNT mode.
Do not create a control file or try to mount or open the auxiliary instance.
To start the auxiliary instance:
Connect to the auxiliary instance as a user with the SYSDBA or SYSBACKUP privilege.
The following example uses password file authentication to connect to the auxiliary instance.
CONNECT SYS@dupdb AS SYSDBA;
The following example uses operating system authentication to connect to the auxiliary instance by using the SYSBACKUP privilege.
CONNECT / AS SYSBACKUP;
Start the auxiliary instance in NOMOUNT mode.
STARTUP FORCE NOMOUNT;
8. Making the Oracle Keystore Available to the Destination Host
If transparent encryption is configured on the source database, then you must ensure that the Oracle software keystore from the source database is available to the auxiliary instance. Manually copy the keystore from the source database to the destination host.
The Oracle software keystore contains the TDE master key that is used to:
decrypt encrypted backups when performing backup-based duplication.
decrypt database or tablespace data when performing active database duplication of TDE-encrypted databases or tablespaces.
The following are the requirements for the keystore at the duplicate database:
a. The keystore must be in the default location, or in the location indicated by the sqlnet.ora file.
b. Permissions on the Oracle keystore file must be set so that the database can access the file.
c. During duplication, the auxiliary instance is restarted thereby causing the Oracle software keystore to become unavailable.
d. To ensure that the auxiliary instance has access to the keystore, set the ENCRYPTION_WALLET_LOCATION parameter in the sqlnet.ora file such that it points to the keystore location.
e. The ENCRYPTION_WALLET_LOCATION sqlnet.ora parameter is deprecated in Oracle Database Release 19c.
f. Use the WALLET_ROOT initialization parameter with the TDE_CONFIGURATION initialization parameter to configure the software keystore location.
With Oracle Real Application Clusters (Oracle RAC)
g. register the auxiliary instance statically with an Oracle Grid Infrastructure listener and use the ENVS parameter in the sqlnet.ora file of the Oracle Grid home to specify environment variables that set the keystore location and the unique name of the database.
The following example sets the ENVS parameter in sqlnet.ora to specify the keystore location and unique database name:
(ENVS="ORACLE_UNQNAME=cdbrptl, ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA= (DIRECTORY=/etc/ORACLE/WALLETS/cdbrpt1)))")
If the source database uses a password-based software keystore (not an auto-login software keystore),
you must provide the keystore password before you begin the duplication.
Use the SET command with the DECRYPTION WALLET OPEN IDENTIFIED BY clause to specify the password that must be used to open the keystore.
The following command specifies the password used to open the keystore (where password is a placeholder for the actual password that you enter):
SET DECRYPTION WALLET OPEN IDENTIFIED BY password;
In an Oracle Grid Infrastructure environment, add the TNS_ADMIN and ORACLE_UNQNAME initialization parameters to both the listener.ora file and the static listener for Data Guard Broker.
The listener must be stopped and restarted after these changes are made.
The following is an example of setting the TNS_ADMIN and ORACLE_UNQNAME parameters: