RMAN re-creates datafiles for temporary tablespaces as part of the process of duplicating a database. For example, assume that the backups of the source database are stored in /dsk1/bkp. Do not set this parameter if you want the duplicate database control files in an Oracle Managed Files format. The logs can be available either as backups (for instance, on a media manager) or as image copies (or the actual archived redo log files). Do not set this parameter. A duplicate database can include the same contents as the source database or contain only a subset of the tablespaces in the source database. The database on srchost is srcdb.

Makes the duplicate filenames the same as the filenames from the source database. You do not have to set additional parameters for specifying duplicate database filenames or transfer backups to the destination host. Any database files for which no other location is specified are created in DB_CREATE_FILE_DEST by DUPLICATE. You can use either of the following techniques: Use an operating system utility to transfer the backups to the new location. Specifically, decide how to name the control files, datafiles, online redo log files, and tempfiles. If the backups reside on disk, then the more channels you allocate, the faster the duplication will be.

The simplest technique is to use active database duplication and to use the SPFILE clause to rename files as explained in "Choosing a Strategy for Naming Duplicate Files". The block size for the duplicate database.

You do not need to set parameters such as DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT in the initialization parameter file because you can set these and all other parameters in the DUPLICATE command itself. For details on the use of LOG_FILE_NAME_CONVERT with Oracle-managed files, see "Setting Initialization Parameters for Oracle Managed Files". This block size must match the block size of the source database. Start the instance in NOMOUNT mode, specifying the PFILE parameter if necessary: RMAN shuts down and restarts the auxiliary instance as part of the duplication. The farthest that RMAN can go in recovery of the duplicate database is the most recent redo log archived by the source database. Start RMAN, connect as TARGET to the source database, as AUXILIARY to the instance of the duplicate database, and optionally as CATALOG to the recovery catalog database. The DUPLICATE command does not restore the original control file, but instead creates a new control file. When the DUPLICATE command completes, the duplicate database is created, with datafiles, online redo logs, and control files in ASM disk group +DISK1. The directory /dsk1/bkp is already in use on the destination host, but the directory /dsk2/dup is not in use in either host. RMAN uses all incremental backups, archived redo log backups, and archived redo logs to perform incomplete recovery and then opens the database with the RESETLOGS option to create the online redo logs. For example, you can duplicate the production database on host1 to host2, and then use the duplicate database on host2 to practice restoring and recovering this database while the production database on host1 operates as usual. Create a text-based initialization parameter file for the auxiliary instance. The source database instance, to which RMAN is connected as TARGET, uses this net service name to connect directly to the auxiliary database instance. You create a duplicate database by using the RMAN DUPLICATE command. Thus, you do not need to specify special syntax to exclude these tablespaces. The auxiliary instance uses a server-side initialization parameter file in the default location so the PFILE parameter is not necessary on the DUPLICATE command. You want to duplicate the source database to database dupdb on remote host host2. When you execute DUPLICATE SPFILE, RMAN either restores the server parameter file from a backup or copies it from an active database. If the source database uses a server parameter file (or a backup is available), then you can create a temporary initialization parameter file on the destination host and set only the DB_NAME parameter. Afterward, connect RMAN to the source database as TARGET and use the CATALOG command to update the source database control file with the location of the manually transferred backups. Also, you have taken a level 0 and level 1 backup of datafiles 4, 5, 6. For example, if you created /dsk2/dup on the destination host, then use NFS to mount this directory as /dsk2/dup on the source host. In this case, RMAN copies the source database password file to the destination host and overwrites any existing password file for the auxiliary instance. For example, you may plan to generate reports at the duplicate that require only a subset of tablespaces from your source database. If no DB_BLOCK_SIZE is specified in the source database initialization parameter file, however, then do not specify DB_BLOCK_SIZE in the auxiliary instance. Use the RMAN command CONFIGURE AUXNAME to specify new names for existing datafiles. You can perform the following tasks in a duplicate database: Test an upgrade to a new release of Oracle Database, Test the effect of applications on database performance, Export data such as a table that was inadvertently dropped from the production database, and then import it back into the production database. In this example, you use active database duplication. RMAN uses the REUSE parameter when creating the online redo logs. Example 23-1 Using the SPFILE Clause to Name Duplicate Files. Finally, RMAN opens the database with the RESETLOGS option to create the online redo logs. Specify the LOGFILE clause of DUPLICATE command. The difference is that you must set the initialization parameters in the auxiliary instance that control the location where files are created at the duplicate to the ASM disk group. Use an operating system utility to copy the backups in /dsk1/bkp on the source host to /dsk2/dup on the source host. The instance associated with the duplicate database is called the auxiliary instance. This section describes the SPFILE strategy only. RMAN must perform incomplete recovery because the online redo log files in the source database are not backed up and cannot be applied to the duplicate database. The principal work of the duplication is performed by an auxiliary channel.

You must ensure that the auxiliary channels can access all datafile backups and archived redo logs required to restore and recover the duplicate database. The auxiliary channel can then search for backups in /dsk2/dup on the destination host and restore them. This channel corresponds to a server session on the auxiliary instance on the destination host. If you create the duplicate database on a host with a different directory structure, then you must use some technique to generate filenames for the duplicate database datafiles. This task is described in "Making Backups and Archived Logs Accessible to the Duplicate Instance". Use one of the alternative techniques described in "Naming Duplicate Files with Alternative Techniques".

A more complicated scenario occurs when you cannot use the same directory name on the destination host as you use on the source host. For example, if you intend to store the RMAN backups in /dsk2/dup on the destination host, then create /dsk2/dup on the source host.

This parameter creates the duplicate log file names by using string substitution in the names of the source database files. Example 23-9 is a variation of Example 23-3 except with the tools tablespace excluded. If multiple parameters are set, then one control file and one online redo log is created in each location. Example 23-11 makes an archival backup on a temporary disk with the tag TESTDB. If the hosts use different directory structures, or if they use the same structure but you want to name the duplicate files differently, then decide how to generate the names for the duplicate database files. Create an initialization parameter file for use by the auxiliary instance on the destination host, and then start the auxiliary instance. You can also use the TABLESPACE clause to specify which tablespaces to include in the duplicate database. If duplicating a database on the same host as the source database, then make sure that NOFILENAMECHECK is not set. Example 23-8 is a variation of Example 23-3 except with read-only tablespace excluded. Run the LIST RESTORE POINT to display the available restore points (see "Listing Restore Points" for instructions). You can use the TABLESPACE parameter to specify which tablespaces should be included in the specified database. If the destination host uses the same directory structure as the source host, then you can use the same names for the duplicate database files that you used for the source database files.

RMAN can apply the incremental level 1 incremental backup to 4, 5, and 6 and apply archived redo logs to all six datafiles. Note that the text-based initialization parameter file for the auxiliary instance must reside on the same host as the RMAN client used to perform the duplication. You want to store the duplicate database files in ASM disk group +DISK1. If you use the SPFILE clause of DUPLICATE to name the files, then you can set initialization parameters in the SPFILE clause. After connecting to the target, duplicate, and catalog databases, run the RMAN script shown in Example 23-7 to duplicate the database. To direct duplicate database online redo log files to Oracle-managed storage, you can use the DB_CREATE_FILE_DEST, DB_RECOVERY_FILE_DEST or DB_CREATE_ONLINE_LOG_DEST_n initialization parameters to identify an Oracle-managed location for the online logs. See Also: "Naming Duplicate Datafiles" and "Naming Duplicate Tempfiles". When the DUPLICATE command completes, the duplicate database is created, with datafiles, online redo logs, and control files in ASM disk group +DISK2. Example 23-1 shows a DUPLICATE command that uses the SPFILE clause to name duplicate files.

You decide to use SET NEWNAME commands to specify the filenames because the duplicate datafiles will be spread out across several directories. Connect RMAN to the source database as TARGET, the duplicate database instance as AUXILIARY, and recovery catalog. If the auxiliary instance requires a text-based initialization parameter file, then this file must exist on the same host that runs the RMAN client application. You can combine any of these options to produce the desired effect. Although eight datafile exist in the source database, you only need to specify seven locations for the target datafiles because you are excluding the tools tablespace. Example 23-2 Sample Initialization Parameter File for the Auxiliary Instance. This section assumes the same circumstances described in "Using SET NEWNAME to Name Duplicate Files". When using backup-based duplication, decide how to make database backups available to the auxiliary instance. This example requires the NOFILENAMECHECK option because the source database files have the same names as the duplicate database files. If you are using the SPFILE technique for naming duplicate files described in "Choosing a Strategy for Naming Duplicate Files", then the only necessary parameter is DB_NAME, which you can set to an arbitrary value. The recommended technique for restoring an archival backup for testing is to create a temporary instance and use the DUPLICATE command. Example 23-11 Creating a Temporary Archival Backup. To register the copy database in the same recovery catalog with the original, you must change the DBID with the DBNEWID utility (refer to Oracle Database Utilities). This chapter contains these topics: Making Backups and Archived Logs Accessible to the Duplicate Instance, Choosing a Strategy for Naming Duplicate Files, Starting and Configuring RMAN Before Duplication, Naming Duplicate Files with Alternative Techniques. When duplicating a database, RMAN generates names for the duplicate database files. Set the DB_CREATE_FILE_DEST initialization parameter to create Oracle Managed Files datafiles at the specified location. Set the DB_CREATE_FILE_DEST initialization parameter to create Oracle Managed Files tempfiles.