Duplicating the Whole Database
1. Use the DUPLICATE command to duplicate databases.
To duplicate a database:
a. Ensure that the prerequisites for the selected duplication technique are met.
b. Complete the required planning tasks before we begin database duplication.
c. Prepare the auxiliary instance that is used when creating the duplicate database.
d. Start RMAN and connect to required databases.
e. Depending on wer duplication technique, we may need to connect to one or more of the following:
1. target database,
2. auxiliary instance, or
3. recovery catalog.
f. Place the source database in a proper state (if necessary).
g. (Optional) Configure RMAN channels to improve duplication performance. Channels perform the primary task of duplicating the database. .
2. Use the DUPLICATE command to duplicate the active source database.
When we perform active database duplication, the backup can be
a. encrypted or
b. compress the backup sets that are used to transfer files from the source database to the duplicate database. Additionally, we can create backup sets on the source database in parallel by using multisection backups.
3. Duplicating a Subset of the Source Database Tablespaces
we can duplicate specified tablespaces within a source database.
To duplicate some tablespaces in a database ensure that the prerequisites for the selected duplication technique are met.
Complete the required planning tasks before we begin database duplication.
Prepare the auxiliary instance that is used when creating the duplicate database.
Start RMAN and connect to required databases.
Depending on the duplication technique, we may need to connect to one or more of the following:
a. target database,
b. auxiliary instance, or
c. recovery catalog.
Place the source database in a proper state (if necessary).
(Optional) Configure RMAN channels to improve duplication performance.
Channels perform the primary task of duplicating the database.
Run the DUPLICATE command with one or more of the options
Other factors that influence what tablespaces are copied include the OFFLINE NORMAL option.
When tablespaces are taken offline with the OFFLINE NORMAL option before duplication,
RMAN does not duplicate the associated data files, and issues DROP TABLESPACE statement for these tablespaces on the duplicate database.
Therefore, we do not have to specify options to exclude these tablespaces.
Note:
RMAN does duplicate tablespaces that are taken offline with any other option besides NORMAL
(unless they are named in a SKIP TABLESPACE option).
Only OFFLINE NORMAL tablespaces are skipped automatically.
As with online tablespaces, RMAN requires a valid backup for these tablespaces when we use backup-based duplication.
Example
Excluding Read-Only Tablespaces
This example shows how to skip read-only tablespaces during database duplication
DUPLICATE TARGET DATABASE TO dupdb
FROM ACTIVE DATABASE
SKIP READONLY;
Excluding Specified Tablespaces
DUPLICATE TARGET DATABASE TO dupdb
FROM ACTIVE DATABASE
SKIP TABLESPACE tools;
Including Specified Tablespaces
we can use the TABLESPACE option to specify which tablespaces to include in the specified database. The remaining tablespaces are skipped. The duplicated subset of tablespaces must be self-contained. The resulting set of skipped tablespaces must not have undo segments or materialized views.
This example includes the users tablespace, which is assumed to be self-contained, and all other tablespaces are excluded, except for SYSTEM and SYSAUX tablespaces and tablespaces with undo segments.
DUPLICATE TARGET DATABASE TO dupdb
FROM ACTIVE DATABASE TABLESPACE users;
Including Specified Tablespaces with Undo Segments
This example performs backup-based duplication with a target connection, but without a recovery catalog connection. we want to specify a subset of tablespaces for duplication. If the target database is not open in this scenario, then RMAN has no way to obtain the names of the tablespaces with undo segments. Thus, we must specify the UNDO TABLESPACE option for these tablespaces. The users tablespace must be self-contained. The resulting set of skipped tablespaces must not have undo segments or materialized views.
DUPLICATE TARGET DATABASE TO dupdb TABLESPACE users UNDO TABLESPACE undotbs;
4. Duplicating an Oracle RAC Database
The steps to duplicate an Oracle Real Application Clusters (Oracle RAC) database contain minor variations from the ones used to duplicate databases.
Ensure that the prerequisites for the selected duplication technique are met.
Prerequisites for Duplicating a Database.
Complete the required planning tasks before we begin database duplication.
Prepare the auxiliary instance that is used when creating the duplicate database.
While duplicating an Oracle Real Application Clusters (Oracle RAC) database,
set the CLUSTER_DATABASE initialization parameter on the auxiliary database to FALSE.
This parameter can be reset to TRUE after the duplication completes.
Start RMAN and connect to required databases. Depending on wer duplication technique, we may need to connect to one or more of the following:
1. target database,
2. auxiliary instance, or
3. recovery catalog.
Place the source database in a proper state (if necessary).
(Optional) Configure RMAN channels to improve duplication performance.
Channels perform the primary task of duplicating the database.
Use the DUPLICATE command to duplicate the source database.
Note:
For more information about duplicating an Oracle RAC database, refer to My Oracle Support Note 1617946.1 at https://support.oracle.com/rs?type=doc&id=1617946.1
5. Duplicating Sparse Databases
The duplication process for a sparse database begins with an implicit restore and then completes duplicating the database containing sparse data files.
Ensure that the backing file of the sparse data file is available for duplication.
Note:
Active database duplication is not allowed for sparse databases.
To duplicate a sparse database:
Ensure that the prerequisites for the selected duplication technique are met.
Complete the required planning tasks before we begin database duplication.
Prepare the auxiliary instance that is used when creating the duplicate database.
While duplicating an Oracle Real Application Clusters (Oracle RAC) database, set the CLUSTER_DATABASE initialization parameter on the auxiliary database to FALSE. This parameter can be reset to TRUE after the duplication completes.
Start RMAN and connect to required databases. Depending on wer duplication technique, we may need to connect to one or more of the following:
1. target database,
2. auxiliary instance, or
3. recovery catalog.
Place the source database in a proper state (if necessary).
(Optional) Configure RMAN channels to improve duplication performance. Channels perform the primary task of duplicating the database.
Run the DUPLICATE command for the sparse database.
The following command duplicates the sparse database db1 :
DUPLICATE FROM SPARSE DATABASE ‘DB1’ TO ‘DUP1’;
Note:
The base (read-only) data files in a sparse database are not encrypted.
Ensure that the base data files are stored in a protected storage and accessed using secured communications.
6. Configuring RMAN Channels for Use in Duplication
The primary job of database duplication is performed by RMAN channels. Each channel corresponds to an Oracle Database server session that performs the duplication tasks. Depending on the duplication technique, RMAN uses either auxiliary channels or target channels.
Use one of the following methods to configure channels:
Automatically allocate channels by using the CONFIGURE command
Manually allocate channels by using the ALLOCATE command
If no automatic channels are configured,
then
we can manually ALLOCATE at least one channel before we being the duplication.
end
The ALLOCATE command that allocates channels must be in the same RUN block as the DUPLICATE command.
RMAN can use the same channel configurations on the source database for duplication on the destination host even if the source database channels do not specify the AUXILIARY option.
7. Configuring Channels for Backup-based Duplication
For backup-based duplication, the principal work of the duplication is performed by the auxiliary channels.
An auxiliary channel corresponds to a server session on the auxiliary instance on the destination host.
RMAN uses the channels to restore backups in the auxiliary instance.
Configure additional auxiliary channels to improve the performance of the duplicate operation.
If we do not explicitly configure auxiliary channels,
then
RMAN uses the same channel configurations on the source database for duplication on the destination host.
end
RMAN can use these configurations even if the source database channels do not specify the AUXILIARY option.
Note the following additional considerations:
a. With disk-based backups, we can increase the speed of the duplication operation by allocating additional channels.
b. With tape-based duplication, we can allocate only as many channels as the number of tape devices that are available.
The channel type (DISK or sbt) of the auxiliary channel must match the backup media. In general, the more channels we allocate for disk backups, the faster the duplication.
Important
We cannot increase the speed of duplication after the disks reach their maximum read/write rate.
For tape backups, limit the number of channels to the number of devices that are available.
If the auxiliary channels need special parameters (for example, to point to a different media manager)
then
we can configure an automatic channel with the AUXILIARY option of the CONFIGURE command.
end
Limitation
a. When we perform duplication without a target connection and without a recovery catalog, only disk channels can be used.
If no user-allocated channels are used,
then only one channel initially restores the control file.
end
After the control file is mounted, the number of allocated channels depends on the configuration in the restored control file.
If (
we omit the USING BACKUPSET clause from the DUPLICATE command
and
the number of allocated auxiliary channels >= to the number of target channels,
then
RMAN still uses active database duplication with backup sets.
end
If the auxiliary channels cannot access backups of the required data files and archived redo log files,
then
the duplication fails.
end
Example Configuring Auxiliary Channels for Disk-based Backups
The following example allocates three auxiliary channels to duplicate a database to disk.
run
{
ALLOCATE AUXILIARY CHANNEL c1 DEVICE TYPE disk;
ALLOCATE AUXILIARY CHANNEL c2 DEVICE TYPE disk;
ALLOCATE AUXILIARY CHANNEL c3 DEVICE TYPE disk;
. . .
DUPLICATE DATABASE . . . ;
}
Configuring Channels for Active Database Duplication
With active database duplication, we need not change the source database channel configuration or configure auxiliary channels.
However, we may want to increase the PARALLELISM setting of the source database disk channels so that RMAN copies files over the network in parallel.
The type of active database duplication technique used determines which channels perform the principal work of duplication.
When image copies are used to perform active database duplication, the primary work is performed by the target channels.
Configure multiple target channels on the source database to improve the duplication performance. When active database duplication is performed by using backup sets, the principal work of duplication is performed by the auxiliary channels. Therefore, it is recommended that we allocate additional auxiliary channels. The number of auxiliary channels must be greater than or equal to the number of target channels. Using backup sets for active duplication also enables parallelism, which can improve the speed of the duplication process.
8. Placing the Source Database in a Proper State
If RMAN is connected to the source database as TARGET,
then
the source database must be in a proper state for duplication.
end
Note:
If we are performing backup-based duplication without a target connection,
then
skip to Starting RMAN and Connecting to Databases.
end
To ensure that the source database is in a proper state:
If the source database instance is not mounted or open,
then
mount or open it.
end
If we are performing active database duplication,
then ensure that the following additional requirements are met:
If the source database is open,
then
archiving must be enabled.
end
If the source database is not open,
then
the database does not require instance recovery.
end
9. Starting RMAN and Connecting to Databases
we must start the RMAN client and connect to the database instances as required by the chosen duplication technique. The RMAN client can be located on any host so long as it can connect to the necessary databases over the network.
To start RMAN and connect to the target and auxiliary instances:
Start the RMAN client on any host that can connect to the necessary database instances.
For example, enter the following command at the operating system prompt on the destination host:
rman
At the RMAN prompt, run CONNECT commands for the database instances that are required for wer duplication technique.
Note:When we duplicate a whole CDB or one or more PDBs, connect to the root of both instances.
For active database duplication using image copies, we must connect to the source database as TARGET and to the auxiliary instance as AUXILIARY. we must supply the net service name to connect to the AUXILIARY instance. A recovery catalog connection is optional. On both instances, the password for the user performing the duplication must be the same. Any user with a SYSDBA or SYSBACKUP privilege can perform duplication.
For active database duplication using backup sets, we must connect to the source database as TARGET by using a net service name. The auxiliary instance uses this net service name to connect to the source database and retrieve the backup sets that are required for the duplication. Connect to the auxiliary instance as AUXILIARY. If we are connecting to the auxiliary instance remotely or intend to use the PASSWORD FILE option of the DUPLICATE command, then connect to the auxiliary instance with a net service name. On both instances, the password for the user performing the duplication must be the same. Any user with a SYSDBA or SYSBACKUP privilege can perform duplication. A recovery catalog connection is optional.
For backup-based duplication without a target connection, we must connect to the auxiliary instance as AUXILIARY and the recovery catalog as CATALOG.
For backup-based duplication with a target connection, we must connect to the source database as TARGET and the auxiliary instance as AUXILIARY. A recovery catalog is optional.
For backup-based duplication without target and recovery catalog connections, we must connect to the auxiliary instance as AUXILIARY.
Note:we cannot connect as TARGET to a standby database.
Example: Connecting to the Required Databases When Performing Active Database Duplication
In this example, a connection is established to the source database and the auxiliary instance using net service names. The Net Service name of the source database is srcdb and that of the auxiliary instance is dupdb.
To connect to required databases from the destination host:
Start the RMAN client on the destination host.
rman
Connect to the source database as TARGET.
RMAN> CONNECT TARGET sys@srcdb;
RMAN> CONNECT AUXILIARY sys@dupdb;
Enter the password for the SYS user on the auxiliary instance when prompted.
10. Using the DUPLICATE Command to Duplicate Databases
RMAN provides multiple options for duplicating databases by using the DUPLICATE command.
Use one of the following options of the DUPLICATE command:
DUPLICATE DATABASE or DUPLICATE…ACTIVE DATABASE
Use these for duplicating non-CDBs and CDBs.
DUPLICATE DATABASE … FOR STANDBY
Use this to create a standby database by duplicating the source database.
Use the DUPLICATE DATABASE … FOR FARSYNC command to create an Oracle Data Guard far sync instance using duplication.
DUPLICATE PLUGGABLE DATABASE
Use this to duplicate one or more PDBs while connected to the root.
When we use the SET NEWNAME command to specify alternate names for duplicate database files, ensure that we enclose the DUPLICATE command and the SET NEWNAME commands within a RUN block.
The DUPLICATE command in Oracle Database Backup and Recovery Reference for additional examples on duplication