Skip Headers
Oracle® Database Backup and Recovery Advanced User's Guide
10g Release 2 (10.2)

Part Number B14191-03
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

14 Creating Transportable Tablespace Sets from Backup with RMAN

This chapter discusses the use of RMAN to create transportable tablespace sets from backup.

It contains the following sections:

Note:

This discussion assumes that you are familiar with transportable tablespaces, as described in Oracle Database Administrator's Guide. The procedure described in this chapter is an alternative method of generating a transportable tablespace set, as described in the step-by-step procedure provided for transporting tablespaces.

About Creating Transportable Tablespace Sets from Backup with RMAN

The method of creating transportable tablespace sets described in Oracle Database Administrator's Guide requires that the tablespaces to be transported are opened read-only for the duration of the tablespace transport process.

By contrast, when RMAN creates transportable tablespace sets from backup, it does not need access to the live datafiles from the tablespaces to be transported. This eliminates the need to put the tablespace in read-only mode. As a result, database availability is improved, especially for large tablespaces, because the tablespaces to be transported can remain open for writes during the process, and because putting a tablespace into read-only mode can take a long time, depending upon current database activity.

Using RMAN for creating a transportable tablespace set also enables you to specify a target point in time, SCN or restore point during your recovery window and transport the data as it stood at that time rather than as it stands at the time of the TRANSPORT TABLESPACE. If, for example, your backup retention policy guarantees a one week recovery window, and you want to create transportable tablespaces for reporting based upon the contents of your database on the last day of the month, you can use RMAN to do so at any time during the first week of the next month.

The RMAN TRANSPORT TABLESPACE command is used to create transportable tablespace sets from RMAN backups.

Note:

Even if RMAN is not used for backups of the database, the RMAN TRANSPORT TABLESPACE command can still be used to create transportable tablespace sets. However, you must have datafile copies from before the desired SCN for the transportable tablespace set, and you must prepare for TRANSPORT TABLESPACE by using the RMAN CATALOG command to record the datafile copies and archived log files needed for the operation in the RMAN repository. Once RMAN has a record of all needed backups and logs, it can perform TRANSPORT TABLESPACE. See Oracle Database Backup and Recovery Basics for details on using CATALOG.

See also:

Oracle Database Backup and Recovery Reference. for reference information on the TRANSPORT TABLESPACE command

Transportable Tablespace Sets from Backup: Concepts

This section contains the following topics:

When to Use RMAN to Create Transportable Tablespace Sets

In any situation where you need transportable tablespaces, you can use the RMAN TRANSPORT TABLESPACE command to create them, as long as you have RMAN backups of your database that can be recovered to the SCN at which you need the tablespaces. Scenarios for using transportable tablespaces are described in Oracle Database Administrator's Guide.

However, there are two specific scenarios in which this feature is particularly useful:

  • Creating transportable tablespace sets for use with a tablespace repository. For example, you have a database with some tablespaces used for quarterly reporting. You use TRANSPORT TABLESPACE to create transportable tablespace sets for those tablespaces quarterly for storage in a tablespace repository. Subsequently, versions of the tablespace can be requested from the repository and attached to some other database for use in the reporting process.

    See also:

    Oracle Streams Replication Administrator's Guide for more details on RMAN and tablespace repositories
  • When preparing to use Streams to keep a destination database synchronized with a source database, you must perform Streams instantiation, to bring the destination database up to a given SCN at which the two databases were known to be synchronized, before you can actually use Streams to move subsequent updates from the source to the target. Creating the transportable tablespace set from backup can be used as part of the process of Streams instantiation.

    See also:

    Oracle Streams Replication Administrator's Guide for more details on RMAN and Streams instantiation

How RMAN Creates Transportable Tablespace Sets from Backup

The following diagram illustrates the process of creating transportable tablespace sets from backup using RMAN.

Figure 14-1 RMAN Transportable Tablespace From Backup: Architecture

Description of Figure 14-1 follows
Description of "Figure 14-1 RMAN Transportable Tablespace From Backup: Architecture"

The elements in the diagram and the process RMAN performs are described in the discussion which follows.

Note:

The process by which transportable tablespace sets are created with RMAN is closely related to the process for performing TSPITR, as discussed in Chapter 8, "RMAN Tablespace Point-in-Time Recovery (TSPITR)". If you are familiar with that process, you will find this one similar.

The figure contains the following entities:

  • The Recovery Manager client

  • The source database, containing the tablespaces to be transported

  • Archived redo logs and backups from the source database, used in restore and recovery of the tablespaces being transported

  • The auxiliary instance, an Oracle database instance which is created by RMAN on the same host as the source database, to perform the restore and recovery of the tablespaces, and, if the process succeeds, cleaned up afterwards.

  • The auxiliary set, which includes datafiles and other files required for the tablespace transport process but which are not themselves part of the recovery set. The auxiliary set typically includes:

    • A copy of the SYSTEM and SYSAUX tablespaces

    • Undo tablespaces and datafiles containing rollback or undo segments from the source database

    The auxiliary instance has other files associated with it, such as its own control file, parameter file, and online logs, but they are not part of the auxiliary set.

  • The auxiliary destination, a location on disk where auxiliary set files, such as the parameter file, datafiles (other than those of the tablespaces being transported), control files and online logs of the auxiliary instance can be stored while the RMAN TRANSPORT TABLESPACE process is running. If the transport process succeeds, these files are deleted.

    Note:

    Specifying an auxiliary destination is optional; however, if you do not use one, you must ensure that locations are specified for all auxiliary instance files, including all datafiles and online log files, using the initialization parameters of the auxiliary instance.

    Oracle recommends the use of an auxiliary destination to simplify the use of TRANSPORT TABLESPACE. See the rules described in "Customize Other Auxiliary File Locations in TRANSPORT TABLESPACE" for details on the extra steps required if you do not use an auxiliary destination.

  • The tablespace destination, a location on disk which (by default) contains the datafile copies and other output files when the tablespace transport command completes

  • The transportable set, which consists of the datafiles from the tablespaces to be transported and an export dump file (generated using Data Pump Export) for use when plugging in the tablespaces at a destination database

  • The sample import script (generated by RMAN) for use in plugging the tablespaces in at a target database, and an export log containing the output from Data Pump Export

All of these terms will be referenced throughout the remainder of this discussion.

Steps RMAN Performs in Transporting Tablespaces from Backup

RMAN creates transportable tablespaces from backup using a three-phase process:

In the startup phase, RMAN constructs an auxiliary database instance. First, an initialization parameter file is automatically created for the instance by RMAN, and used to start the auxiliary instance in NOMOUNT mode. Then, RMAN restores a backup of the source database control file to serve as the auxiliary instance control file, and mounts that control file.

Once the auxiliary instance control file is mounted, RMAN restores auxiliary and transportable set datafiles from the backups of the source database, storing the auxiliary datafiles in the selected auxiliary destination and the transportable set files in the tablespace destination. RMAN then performs a SWITCH operation at the auxiliary instance, so that the auxiliary instance uses the restored datafiles as the datafiles for the auxiliary instance.

RMAN then performs database point-in-time recovery at the auxiliary instance. This updates auxiliary and transportable set datafiles to their contents as of the target time specified for the TRANSPORT DATABASE command. (If no target time is specified, complete recovery is performed.) Archived redo logs are restored from backup as necessary at the auxiliary destination (or other location), and are deleted after they are applied.

Once the recovery is complete, RMAN performs an OPEN RESETLOGS operation on the auxiliary database. The datafiles now reflect the tablespace contents as of the target SCN for the tablespace transport operation.

Recovery set tablespaces of the auxiliary instance are put into read-only mode, and Data Pump Export is invoked in transportable tablespace mode to generate the export dump file for the recovery set tablespaces.

The dump file is located in the tablespace destination location by default. To specify the location of the dump files, see "RMAN TRANSPORT TABLESPACE: Specifying Locations for Data Pump Files".

At this time RMAN also generates the sample Data Pump import script for use when plugging in the transported tablespaces at a target database. The contents of this script are written to a file named impscript.sql in the tablespace destination. The commands for the script are also included in the RMAN output for the TRANSPORT TABLESPACE command.

If all of these operations are completed successfully, RMAN shuts down the auxiliary instance and deletes all files created during TRANSPORT TABLESPACE except for the transportable set files, the Data Pump Export log, and the sample import script.

Note:

  • The recovery set datafiles are not automatically converted to the endian format of the destination database by the TRANSPORT TABLESPACE process. If necessary, use the RMAN CONVERT command, described in Chapter 15, "RMAN Cross-Platform Transportable Databases and Tablespaces", to convert the datafiles to the endian format of the destination database after creating the transportable set.

  • The sample import script assumes that the files used in plugging the transportable tablespaces at the destination database are stored in the same locations where they were created by the TRANSPORT TABLESPACE operation. If files have been moved to new disk locations before being plugged in, you must update the sample script with the new locations of the files before using the script to plug in the transported tablespaces.

Limitations of RMAN TRANSPORT TABLESPACE Command

The limitations on creating transportable tablespace sets described in Oracle Database Administrator's Guide apply to transporting tablespaces from backup, with the exception of the requirement to make the tablespaces read-only.

There are also limitations specific to creating a transportable tablespace set using RMAN:

  • You must have a backup of all needed tablespaces (including those in the auxiliary set) and archived redo log files available for use by RMAN that can be recovered to the target point in time for the TRANSPORT TABLESPACE operation.

    Note:

    If RMAN is not part of the backup strategy for your database, you can still use RMAN TRANSPORT TABLESPACE, as long as the needed datafile copies and archived redo logs are available on disk. Use the RMAN CATALOG command to record the datafile copies and archived logs in the RMAN repository. You can then use TRANSPORT TABLESPACE. See Oracle Database Backup and Recovery Basics for details on using CATALOG.

    You also have the option of using RMAN to back up your database specifically to create backups for use in creating a transportable tablespace set from backup.

  • Because the RMAN process for creating transportable tablespaces from backup uses the Data Pump Export and Import utilities, you cannot use this process if the tablespaces to be transported use XMLTypes. In such a case, you must use the process documented in Oracle Database Administrator's Guide.

  • Because RMAN creates the automatic auxiliary instance used for restore and recovery on the same host as the source instance, there is some performance overhead during the operation of the TRANSPORT TABLESPACE command.

  • If you drop a tablespace, then you cannot later use TRANSPORT TABLESPACE to include that tablespace in a transportable tablespace set, even if the SCN for TRANSPORT TABLESPACE is earlier than the SCN at which the table was dropped.

  • If you rename a tablespace, you cannot use TRANSPORT TABLESPACE to create a transportable tablespace set as of a point in time before the tablespace was renamed. (RMAN has no information about the previous name of the tablespace.)

  • You cannot TRANSPORT tables without their associated constraints, or constraints without their associated tables.

  • Neither the transportable set nor the auxiliary set datafiles can contain any of the following:

    • Replicated master tables

    • Partial tables

    • Tables with VARRAY columns, nested tables, or external files

    • Snapshot logs and snapshot tables

    • Tablespaces containing undo or rollback segments

    • Tablespaces that contain objects owned by SYS, including rollback segments

If you are performing TRANSPORT TABLESPACE without a recovery catalog, the following additional restrictions apply:

  • If creating a transportable set with tablespace contents as of a point in time in the past, then the set of tablespaces with undo segments at the time TRANSPORT TABLESPACE is executed must be the same as the set of tablespaces with undo segments at the time selected for transport.

    Tablespaces including undo segments as of the target SCN for TRASNPORT TABLESPACE must be part of the auxiliary set. Unlike the recovery catalog, the RMAN repository in the control file only contains a record of tablespaces that include undo segments at the current time. If the set of tablespaces with undo segments was different at the target time, then TRANSPORT TABLESPACE fails.

  • If the database has re-used the control file records for the RMAN repository that contained information about backups required for the TRANSPORT TABLESPACE process, then the process fails because RMAN cannot locate the required backups. You may be able to use CATALOG to add the needed backups to the RMAN repository if they are still available, but if the database is already overwriting control file records you may lose records of other needed backups.

Creating a Transportable Tablespace Set with RMAN: Procedure

The focus in this discussion is on presenting the basics of planning for and performing TRANSPORT TABLESPACE operations with RMAN in the most automated case, where RMAN manages the auxiliary instance for you, and then how to customize various aspects of the process. This discussion contains the following sections:

Using RMAN TRANSPORT TABLESPACE: Basic Scenario

This section describes the use of TRANSPORT TABLESPACE in the most automated case.

Note:

The process described here is only one part of the process of transporting tablespaces. Before you use TRANSPORT TABLESPACE, you must meet the requirements described in Oracle Database Administrator's Guide:
  • Confirm that tablespace transport is supported between your source and destination platforms

  • Identify a self-contained set of tablespaces to include in the transportable set

In this scenario, the AUXILIARY DESTINATION clause is specified, which causes RMAN to use default values that work for most cases in managing the auxiliary instance. Only required options are specified. Oracle recommends that you use an auxiliary destination with TRANSPORT TABLESPACE to simplify management of auxiliary instance files.

To use RMAN TRANSPORT TABLESPACE:

Start the RMAN client, connecting to the source database and, if used, the recovery catalog. Then enter the TRANSPORT TABLESPACE command, specifying the required arguments. For example, to transport the tablespaces tbs_2 and tbs_3, use the TRANSPORT TABLESPACE command as follows:

transport tablespace tbs_2, tbs_3
   tablespace destination '/disk1/transportdest'
   auxiliary destination '/disk1/auxdest'
   ;
 

When the TRANSPORT TABLESPACE command completes, the following outputs result:

  • The transportable set datafiles are left in the location /disk1/transportdest with their original names.

  • The Data Pump Export dump file for the transportable set is named dmpfile.dmp, the export log is named explog.log and the sample import script is named impscrpt.sql. All are created in the tablespace destination /disk1/transportdest.

    Note:

    If there is already a file under the name of the export dump file in the tablespace destination, then TRANSPORT TABLESPACE fails when it calls Data Pump Export. If repeating a previous TRANSPORT TABLESPACE operation, make sure you delete the previous output files, including the export dump file.
  • The auxiliary set files are removed from /disk1/auxdest.

You can now return to the process for transporting tablespaces described in Oracle Database Administrator's Guide.

RMAN TRANSPORT TABLESPACE with UNTIL Time or SCN

If you specify a target time with the TRANSPORT TABLESPACE command, then during the tablespace transport operation, RMAN will restore the tablespace at the auxiliary instance using backups from prior to the target time and perform point-in-time recovery on the auxiliary database to the specified target time. (Backups and redo logs needed for this point-in-time recovery must be available.)

The target time can be specified using an SCN (in the current incarnation or its ancestors), log sequence number, restore point or time expression. For example:

TRANSPORT TABLESPACE tbs_2 
   TABLESPACE DESTINATION '/disk1/transportdest' 
   AUXILIARY DESTINATION '/disk1/auxdest'
   UNTIL SCN 11379;
TRANSPORT TABLESPACE tbs_2 
   TABLESPACE DESTINATION '/disk1/transportdest' 
   AUXILIARY DESTINATION '/disk1/auxdest'
   UNTIL RESTORE POINT 'before_upgrade';
TRANSPORT TABLESPACE tbs_2 
   TABLESPACE DESTINATION '/disk1/transportdest' 
   AUXILIARY DESTINATION '/disk1/auxdest'
   UNTIL TIME 'SYSDATE-1';

RMAN TRANSPORT TABLESPACE: Specifying Locations for Data Pump Files

You can change the names of the Data Pump Export dump file for the transportable set, the sample import script for use at the target database, and the log file generated by Data Pump Export, and the directory to which they are written.

By default, these files are stored in the tablespace destination and named as follows:

  • The Data Pump Export dump file is named dmpfile.dmp

  • The export log file is named explog.log

  • The sample import script is called impscrpt.sql

You can place the dump file and the export log in a different directory by using the DATAPUMP DIRECTORY clause, passing in the name of a database directory object.

Note:

The database directory object used by DATAPUMP DIRECTORY is not the directory path of an actual file system directory. The value passed corresponds to the DIRECTORY command line argument of Data Pump Export. See Oracle Database Utilities for more details on the use of directory objects with Data Pump Export.

These files can be renamed using the DUMP FILE, EXPORT LOG and IMPORT SCRIPT clauses of TRANSPORT TABLESPACE.

Note:

  • The filenames cannot contain full file paths with directory names. If the DUMP FILE or EXPORT LOG filenames specify file paths, then TRANSPORT TABLESPACE fails when it attempts to generate the export dump. Use the DATAPUMP DIRECTORY clause to specify a database directory object that identifies a location for the outputs of Data Pump Export.

The following example illustrates the use of TRANSPORT TABLESPACE with the DATAPUMP DIRECTORY, DUMP FILE, EXPORT LOG and IMPORT SCRIPT filenames specified.

Assume that a database directory object has been created as follows, for use with Data Pump Export:

SQL>  CREATE OR REPLACE DIRECTORY mypumpdir as '/datapumpdest';

The following TRANSPORT TABLESPACE command illustrates the use of the optional arguments that control file output locations:

TRANSPORT TABLESPACE tbs_2
   TABLESPACE DESTINATION '/transportdest'
   AUXILIARY DESTINATION '/auxdest'
   DATAPUMP DIRECTORY  mypumpdir
   DUMP FILE 'mydumpfile.dmp'
   IMPORT SCRIPT 'myimportscript.sql'
   EXPORT LOG 'myexportlog.log';
   

After a successful run, the auxiliary destination is cleaned up, the Data Pump Export Dump file and the export log are located in the directory referenced by DATAPUMP DIRECTORY (/datapumpdest/mydumpfile.dmp and /datapumpdest/myexportlog.log) and the transportable set datafiles are stored in /transportdest.

RMAN TRANSPORT TABLESPACE with Customized Initialization Parameters

When RMAN creates the auxiliary instance, it creates an initialization parameter file with default parameters that should work for nearly all TRANSPORT TABLESPACE cases, especially if you provide an AUXILIARY DESTINATION argument to TRANSPORT TABLESPACE.

RMAN TRANSPORT TABLESPACE can also use an auxiliary instance parameter file, which can contain values for additional initialization parameters, and values that override the values of those parameters defined in the default initialization parameter file.

Note:

The auxiliary instance parameter file is not expected to be a complete initialization parameter file for the auxiliary instance. Any parameters specified are added to or override the default parameters for the auxiliary instance. It is not necessary to specify parameters in the initialization file that you do not intend to override.

Reasons for using an auxiliary instance parameter file include:

  • To manage locations for auxiliary instance datafiles (if, for instance, you do not want all auxiliary instance datafiles stored in the same location on disk, but you do not want to specify the location of every file individually).

  • To specify control naming for online redo logs using LOG_FILE_NAME_CONVERT

  • To increase SHARED_POOL_SIZE if needed for Data Pump Export.

RMAN TRANSPORT TABLESPACE Default Auxiliary Instance Parameters

RMAN defines the following basic initialization parameters for the automatic auxiliary instance:

  • DB_NAME - Same as DB_NAME of the source database

  • COMPATIBLE - Same as the compatible setting of the source database

  • DB_UNIQUE_NAME - Generated, based on the DB_NAME, to be unique

  • DB_BLOCK_SIZE - Same as the DB_BLOCK_SIZE of the source database

  • DB_FILES - Set to same value as DB_FILES for the source database

  • SHARED_POOL_SIZE - Set to 110MB, because Data Pump Export can require this much space or more.

  • LARGE_POOL_SIZE - Set to 1MB

If the AUXILIARY DESTINATION argument to TRANSPORT TABLESPACE is used, RMAN also defines:

  • DB_CREATE_FILE_DEST - Set to the auxiliary destination

  • CONTROL_FILES - A generated filename in the auxiliary destination

When an auxiliary destination is specified, RMAN uses these two parameters in creating the auxiliary instance online logs and control files in the auxiliary destination.

Note:

Overriding one of these basic initialization parameters with an inappropriate value in the auxiliary instance parameter file can cause TRANSPORT TABLESPACE to fail. If you encounter a problem, try returning to the default value.

Location of the Auxiliary Instance Parameter File

By default, RMAN looks for the auxiliary instance parameter file at an operating system-dependent location on the host running the RMAN client (which may not be the host running the auxiliary instance). For Unix, the location is: ?/rdbms/admin/params_auxint.ora, where '?' stands for ORACLE_HOME on the host running RMAN. (If no file is found in the default location, RMAN does not generate an error.)

Note:

If you want to use the default initialization parameters for the auxiliary instance, check whether an auxiliary instance parameter file exists before running TRANSPORT TABLESPACE. The same location is used for an auxiliary instance parameter file in TSPITR, so it is possible that a file remains from a previous TSPITR or TRANSPORT TABLESPACE operation. In such a case, you may see unexpected behavior, depending upon the parameters specified.

You can use the RMAN SET AUXILIARY INSTANCE PARAMETER FILE command in a RUN block before TRANSPORT TABLESPACE to specify a different location for the auxiliary instance parameter file. (Note that, as with the default location of the auxiliary instance parameter file, the path specified when using SET AUXILIARY INSTANCE PARAMETER FILE is a client-side path.)

Using an Auxiliary Instance Parameter File: Example

For example, you can create a file /tmp/auxinstparams.ora on the host running the RMAN client, containing the following initialization parameters:

SHARED_POOL_SIZE=150M;

You can then use the parameter file with TRANSPORT TABLESPACE as in this example:

RUN {
SET AUXILIARY INSTANCE PARAMETER FILE TO '/tmp/auxinstparams.ora';
TRANSPORT TABLESPACE tbs_2 
   TABLESPACE DESTINATION '/disk1/transportdest' 
   AUXILIARY DESTINATION '/disk1/auxdest';
} 

The SHARED_POOL_SIZE parameter specified in /tmp/auxinstparams.ora overrides the default value used for SHARED_POOL_SIZE in TRANSPORT TABLESPACE when RMAN sets up the auxiliary instance.

Customize Shared Pool Size in RMAN TRANSPORT TABLESPACE

If the default shared pool size of 100MB is not sufficient for Data Pump Export to run successfully, then specify a larger value. Use an auxiliary instance parameter file as described in "RMAN TRANSPORT TABLESPACE with Customized Initialization Parameters". Include the SHARED_POOL_SIZE initialization parameter in your auxiliary instance parameter file, listing the control file locations desired.

For more on the use of the SHARED_POOL_SIZE initialization parameter, see Oracle Database Reference.

Customize Auxiliary Control File Location in TRANSPORT TABLESPACE

By default, one control file is created for the auxiliary instance, in an operating system dependent location. (In Unix, the default location is ?/dbs/cntrl_@.dbf, where '?' stands for ORACLE_HOME and '@' stands for ORACLE_SID. For an automatic auxiliary instance, ORACLE_SID is randomly generated by RMAN).

To change the location of the auxiliary instance control file, use an auxiliary instance parameter file as described in "RMAN TRANSPORT TABLESPACE with Customized Initialization Parameters". Include the CONTROL_FILES initialization parameter in your auxiliary instance parameter file, listing the control file locations desired.

For more on the use of the CONTROL_FILES initialization parameter, see Oracle Database Reference.

Customize Other Auxiliary File Locations in TRANSPORT TABLESPACE

Several different rules affect the location of auxiliary instance files such as datafiles and online logs, created during TRANSPORT TABLESPACE. The simplest method is to use AUXILIARY DESTINATION and let RMAN manage all file locations automatically. However, if you need to relocate some or all auxiliary instance files, the options for specifying locations for these files are described here in order of precedence, so that, if several are used, then for each file, the first rule in the list that applies determines the filename.

Note:

If you do not use AUXILIARY DESTINATION, then you must use LOG_FILE_NAME_CONVERT to specify the location of the online redo log files for the auxiliary instance.

Neither SET NEWNAME nor CONFIGURE AUXNAME can affect the location of the auxiliary instance online logs, so if you do not use AUXILIARY DESTINATION or LOG_FILE_NAME_CONVERT RMAN has no information about where to create the online logs.

Transport Tablespace with SET NEWNAME for Auxiliary Datafiles

You can use the SET NEWNAME command in a RUN block to specify filenames for use in TRANSPORT TABLESPACE, as in this example:

RUN {
   SET NEWNAME FOR DATAFILE '/oracle/dbs/tbs_12.f' 
      TO '/bigdrive/auxdest/tbs_12.f';
   SET NEWNAME FOR DATAFILE '/oracle/dbs/tbs_11.f'
      TO '/bigdrive/auxdest/tbs_11.f';
   TRANSPORT TABLESPACE tbs_2 
         TABLESPACE DESTINATION '/disk1/transportdest' 
         AUXILIARY DESTINATION '/disk1/auxdest';
   }

The SET NEWNAME commands cause these auxiliary instance datafiles to be restored to the locations named instead of /disk1/auxdest.

Note:

SET NEWNAME is best used with one-time operations. If you expect to create transportable tablespaces from backup regularly for a particular set of tablespaces, consider using CONFIGURE AUXNAME instead of SET NEWNAME in order to make persistent settings for the location of the auxiliary instance datafiles.

Transport Tablespace with CONFIGURE AUXNAME for Auxiliary Datafiles

You can use the CONFIGURE AUXNAME command to specify persistent locations for recovery set or auxiliary set datafiles. Each datafile for which a CONFIGURE AUXNAME command has been used is restored from backup to the specified location prior to recovery. Recovery set datafiles are left at the specified location after TRANSPORT TABLESPACE is complete, instead of being stored in the tablespace destination. Auxiliary set datafiles are deleted when the operation is complete, unless the operation failed.

For example, consider a database where tablespace tbs_12, containing datafile tbs_12.f, is part of the auxiliary set required when creating a transportable set for a tablespace tbs_11. This CONFIGURE AUXNAME statement sets a persistent non-default location for the auxiliary set datafile '/oracle/dbs/tbs_12.f' during TRANSPORT TABLESPACE:

CONFIGURE AUXNAME FOR '/oracle/dbs/tbs_12.f' TO '/disk1/auxdest/tbs_12.f';
 

In the future, you execute the following TRANSPORT TABLESPACE command:

TRANSPORT TABLESPACE tbs_1 AUXILIARY DESTINATION '/myauxdest';

In such a case, the auxuiliary set copy of datafile '/oracle/dbs/tbs_12.f' is restored at the location /disk1/auxdest/tbs_12.f instead of being stored in the location specified by AUXILIARY DESTINATION.

Note:

You can view any current CONFIGURE AUXNAME settings using the SHOW AUXNAME command, described in Oracle Database Backup and Recovery Reference.

Transport Tablespace with AUXILIARY DESTINATION Parameter

If you use an AUXILIARY DESTINATION argument with TRANSPORT TABLESPACE, as in the example in "Using RMAN TRANSPORT TABLESPACE: Basic Scenario", then any auxiliary set file which is not moved to another location using SET NEWNAME or CONFIGURE AUXNAME commands is stored in the auxiliary destination during the TRANSPORT TABLESPACE operation.

Transport Tablespace and Naming Auxiliary Files with Initialization Parameters

You can use the LOG_FILE_NAME_CONVERT and DB_FILE_NAME_CONVERT initialization parameters in an auxiliary instance parameter file to control the naming for online logs and other database files at the auxiliary instance. To do so, use an auxiliary instance parameter file, and specify the initialization parameters LOG_FILE_NAME_CONVERT, which controls naming for online log files, and DB_FILE_NAME_CONVERT, which controls naming for other database files at the auxiliary instance.

If no AUXILIARY DESTINATION clause is provided to the TRANSPORT TABLESPACE command, then these parameters determine the location of any files for which no CONFIGURE AUXNAME or SET NEWNAME value was provided.

Note:

  • If you do not use an AUXILIARY DESTINATION clause, then you must use an auxiliary instance parameter file and specify LOG_FILE_NAME_CONVERT to generate names for the online logs of the auxiliary instance. Otherwise, RMAN cannot determine a location for the online logs for the automatic auxiliary instance.

  • Neither LOG_FILE_NAME_CONVERT nor DB_FILE_NAME_CONVERT can be used to generate new Oracle Managed Files (OMF) filenames for files at the auxiliary instance when the original files are stored in Oracle Managed Files. The database must be allowed to manage the generation of unique filenames in each OMF destination. Therefore, you must use an AUXILIARY DESTINATION clause to control the location of the online logs, and you must either use AUXILIARY DESTINATION clause, SET NEWNAME or CONFIGURE AUXNAME to specify the location for datafiles.

See "RMAN TRANSPORT TABLESPACE with Customized Initialization Parameters" for details on using SET AUXILIARY INSTANCE PARAMETER FILE with TRANSPORT TABLESPACE, and Oracle Database Reference for more details on the LOG_FILE_NAME_CONVERT and DB_FILE_NAME_CONVERT initialization parameters.

Troubleshooting RMAN TRANSPORT TABLESPACE

When the RMAN TRANSPORT TABLESPACE command fails, the failed auxiliary instance files are left intact in the auxiliary instance destination for troubleshooting.

Common causes for problems during TRANSPORT TABLESPACE include the following:

Troubleshooting RMAN TRANSPORT TABLESPACE: Insufficient Shared Pool

If you see an error related to shared pool size, create an auxiliary instance parameter file with a larger value for SHARED_POOL_SIZE, as described in "Customize Shared Pool Size in RMAN TRANSPORT TABLESPACE" .

Troubleshooting RMAN TRANSPORT TABLESPACE: Filename Conflicts

If your SET NEWNAME, CONFIGURE AUXNAME and DB_FILE_NAME_CONVERT cause multiple files in the auxiliary or recovery sets to have the same name, RMAN will report an error during the TRANSPORT TABLESPACE command. To correct the problem, use different values for these parameters to ensure that duplicate file names are not created.