Oracle® Database Backup and Recovery Advanced User's Guide 10g Release 2 (10.2) Part Number B14191-03 |
|
|
PDF · Mobi · ePub |
Oracle supports transportable tablespaces, which are used to move the contents of individual tablespaces between databases. It also supports a transportable database feature, which can be used to recreate an entire database from one platform on another platform as long as the platforms have the same endian order.
This chapter discusses the use of RMAN in transporting tablespaces and entire databases between disparate platforms.This chapter contains the following sections:
Cross-Platform Tranportable Tablespace: CONVERT DATAFILE or TABLESPACE
A description of how to use RMAN's CONVERT
DATAFILE
and CONVERT
TABLESPACE
commands when moving transportable tablespaces across platforms with different endian formats
Cross-Platform Transportable Database: RMAN CONVERT DATABASE
A description of how to use RMAN's CONVERT
DATABASE
command to simplify transporting an entire database to a different platform, which must have the same endian format
Transportable tablespaces allow you to copy an entire tablespace between Oracle databases. A full discussion of transportable tablespaces, their uses, and the different techniques for creating and using them can be found in the Oracle Database Administrator's Guide.
Cross-platform transportable tablespaces are transportable tablespaces in which the destination hosts are of a different platform from the source host. Typical uses of cross-platform transportable tablespaces include:
Publishing structured data as transportable tablespaces for distribution to customers, who can convert the tablespaces for integration into their existing databases regardless of platform
Moving data from a large data warehouse server to data marts on smaller computers such as Linux-based workstations or servers
Sharing read-only tablespaces across a heterogeneous cluster where all hosts share the same endian format
When transporting tablespaces between databases where the endian format of the source platform is different from that of the destination platform, the endian format of the datafiles in the transportable tablespace set must be converted to match the destination platform. This conversion can be performed using the RMAN CONVERT
TABLESPACE
command (when converting on the source host) or CONVERT
DATAFILE
command (when converting on the destination host).
Note:
Using the RMANCONVERT
command to convert the datafiles of a transportable tablespace set for use on platforms with different endian formats is only one step in using cross-platform transportable tablespaces. Read the discussion of transportable tablespaces in Oracle Database Administrator's Guide in its entirety before attempting to use transportable tablespaces or the procedures in this section.CONVERT
does not perform in-place conversion of datafiles. It produces output files in the correct format for use on the destination platform, but does not alter the contents of the source datafiles.
Differences between the conversion process on the source and destination platforms are described in the following discussion. The CONVERT
TABLESPACE
command must be used on the source platform, while the CONVERT
DATAFILE
command is used on the destination platform.
This discussion contains the following sections:
Using CONVERT TABLESPACE... TO PLATFORM on the Source Platform
Using CONVERT DATAFILE... FROM PLATFORM on the Destination Host
The CONVERT
TABLESPACE
... TO
PLATFORM
command is used to convert tablespaces on the source platform to the format of a destination platform. Invoke CONVERT
TABLESPACE
, specifying the names of one or more tablespaces in the target database to convert and the destination platform for the conversion, as shown in this example:
RMAN> CONVERT TABLESPACE ts_1, ts_2... TO PLATFORM 'platform_name';
The TO
PLATFORM
clause is mandatory with CONVERT
TABLESPACE
. Supported values for platform_name
can be found in V$TRANSPORTABLE_PLATFORM
. Note that you can only convert entire tablespaces, on the source platform, not individual datafiles.
Optional parameters for CONVERT
TABLESPACE
... TO
PLATFORM
include:
PARALLELISM
n
Used to specify that n
server sessions should perform the work of conversion in parallel to improve performance. Each datafile is assigned to a single server session for conversion, that is, you cannot improve performance on converting a single datafile by assigning a greater degree of parallelism.
Note:
The optimal degree of parallelism to use is a function of the number of effective disk heads available for reading and writing. Setting the degree of parallelism too high for a given number of spindles can actually increase the time required for conversion. It is never useful to specify a degree of parallelism greater than the number of datafiles to be processed.A series of patterns, specified using the DB_FILE_NAME_CONVERT
argument, used to generate new file names for the converted datafiles, based on the input datafile names.
FORMAT
formatSpec
Provides a format used as a template to generate new, unique filenames for the converted datafiles. If no FORMAT
is specified, then RMAN uses a platform-dependent destination and format.
The full semantics of these parameters are described in the reference entry for the CONVERT
command in the Oracle Database Backup and Recovery Reference.
You can use the FORMAT
and fileNameConversionSpec
arguments to control the names of the files generated by the CONVERT
command, or leave the renaming of converted files to default rules provided by RMAN. The following list describes the order of precedence among these rules:
Files that match any patterns provided in a fileNameConversionSpec
clause are renamed based upon that pattern.
If you specify a FORMAT
clause, then any file not renamed based upon a fileNameConversionSpec
pattern are renamed according to the specified formatSpec
.
Any file not renamed by fileNameConversionSpec
or FORMAT
is assigned a default location based upon the following rules:
If the channel used for output has a default CONFIGURE
... FORMAT
setting, that setting is used to generate output file names
If a flash recovery area is configured, the converted datafiles are placed in the flash recovery area (though they are not usable backups).
Otherwise a platform-specific default FORMAT
(which includes a %U
for generating a unique filename) is used.
Note:
These rules are the same as the rules that determine default locations for BACKUP
AS
COPY
backups.
The fileNameConversionSpec
method cannot be used to generate output filenames for CONVERT
when the source files have Oracle Managed Files (OMF) file names (such as /private/boston/datafile/o1_mf_system_ab12554_.dbf
for a file system using OMF or +DISK/boston/datafile/system.256.4543080
for ASM) and the destination is an OMF destination.
For complete details on rules governing file naming, see the reference entry for BACKUP
AS
COPY
in Oracle Database Backup and Recovery Reference.
Suppose you need to transport tablespaces finance
and hr
from a source database running on a Sun Solaris host to a destination database running on a Linux PC. You plan to store the converted datafiles in the temporary directory /tmp/transport_linux/
on the source host.
The example assumes that you have carried out the following steps in preparation for the tablespace transport:
You have set the tablespaces to be transported to be read-only.
You have looked up the name for the destination platform in V$TRANSPORTABLE_PLATFORM
.
The database has a list of its own internal names for each platform supporting cross-platform data transport. You may need the exact name of the source or target platform as a parameter to the CONVERT
command. Query V$TRANSPORTABLE_PLATFORM
to get the platform name from SQL*Plus as follows:
SQL> SELECT PLATFORM_ID, PLATFORM_NAME, ENDIAN_FORMAT FROM V$TRANSPORTABLE_PLATFORM WHERE UPPER(PLATFORM_NAME) LIKE 'LINUX';
The PLATFORM_NAME
for Linux on a PC is 'Linux IA (32-bit)
'.
Now use RMAN to convert the datafiles into the endian format of the destination host. In this example, the FORMAT
argument controls the name and location of the converted datafiles.
% rman TARGET / RMAN> CONVERT TABLESPACE finance,hr TO PLATFORM 'Linux IA (32-bit)' FORMAT='/tmp/transport_linux/%U';
The result is a set of converted datafiles in the /tmp/transport_linux/
directory, with data in the correct endian format for the Linux IA (32-bit) platform.
From this point, follow the rest of the general outline for creating a transportable tablespace set:
Use the export utility to create the export dump file
Move the converted datafiles from /tmp/transport_linux/
and the export dump file from the source host to the desired directories on the destination host
Plug the tablespace into the new database with the Import utility.
The CONVERT
DATAFILE
... FROM
PLATFORM
command is used on the destination platform to convert tablespaces from the format of a source platform into a format that can be plugged into a database on the destination platform.
Note:
You cannot useCONVERT
TABLESPACE
on the destination platform. Until the datafiles are transported into the destination database, the datafiles are not associated with a tablespace name in the database, so RMAN cannot translate the tablespace name into a list of datafiles. Therefore, you must use CONVERT
DATAFILE
and identify the datafiles by filename.CONVERT
DATAFILE
takes as arguments the names of one or more datafiles to convert, and the name of the source platform for the datafiles, as shown in this example:
RMAN> CONVERT DATAFILE datafile_1, datafile_2... FROM PLATFORM 'platform_name';
The destination platform is the platform on which the destination database is running.
The value provided for FROM
PLATFORM
must match the actual format of the datafiles to be converted, or RMAN returns an error. Supported values for platform_name
can be found in V$TRANSPORTABLE_PLATFORM
.
Note:
TheFROM
PLATFORM
clause is optional with CONVERT
DATAFILE
. If omitted, however, it is assumed that the datafiles to be converted are already in the format of the destination platform. The effect of CONVERT
DATAFILE
without FROM
PLATFORM
is to copy datafiles from one location to another without changing their format, and without recording the copies created in the RMAN repository as backups of the copied datafiles.
The primary use of CONVERT
DATAFILE
without FROM
PLATFORM
is in copying datafiles into and out of Automated Storage Management (ASM) disk groups. Operating system-level tools cannot be used to read or write files into ASM, but RMAN provides the required functionality. See "Using RMAN CONVERT to Copy Files Between ASM and Non-ASM Storage" for more details on this procedure.
The PARALLELISM
, FORMAT
, and fileNameConversionSpec
arguments, described in "Using CONVERT TABLESPACE... TO PLATFORM on the Source Platform", behave the same on the source and destination platforms.
Suppose you need to transport tablespaces finance
(datafiles 'fin/fin01.dbf
' and 'fin/fin02.dbf
') and hr
(datafiles 'hr/hr01.dbf
' and 'hr/hr02.dbf
') from a source database running on a Sun Solaris host to a destination database running on a Linux PC host. You plan to perform conversion on the destination host.
When the datafiles are plugged into the destination database, you plan to store them in /orahome/dbs
and preserve the current directory structure (that is, datafiles for the hr
tablespace go in the /orahome/dbs/hr
subdirectory, and datafiles for the finance
tablespace go in the /orahome/dbs/fin
directory).
The example assumes that you have carried out the following steps in preparation for converting the tablespaces and plugging them in at the destination:
You have set the source tablespaces to be transported to be read-only, used the Original Export utility to create the export dump file (named, in our example, expdat.dmp
), and copied expdat.dmp
and the unconverted datafiles of the transportable tablespace set to the destination host, in the /tmp/transport_solaris/'
directory. You have preserved the subdirectory structure from the files' original location, that is, the datafiles are stored as:
/tmp/transport_solaris/fin/fin01.dbf
/tmp/transport_solaris/fin/fin02.dbf
/tmp/transport_solaris/hr/hr01.dbf
/tmp/transport_solaris/hr/hr02.dbf
Now use RMAN's CONVERT
command to convert the datafiles to be transported to the destination host's format and store the converted datafiles in /orahome/dbs
.
% rman TARGET / RMAN> CONVERT DATAFILE '/tmp/transport_solaris/fin/fin01.dbf', '/tmp/transport_solaris/fin/fin02.dbf', '/tmp/transport_solaris/hr/hr01.dbf', '/tmp/transport_solaris/hr/hr02.dbf' DB_FILE_NAME_CONVERT '/tmp/transport_solaris/fin','/orahome/dbs/fin', '/tmp/transport_solaris/hr','/orahome/dbs/hr'
Note the following:
The FORMAT
argument controls the name and location of the converted datafiles.
When converting on the destination platform, you must specify the source platform using the FROM
PLATFORM
argument. Otherwise, RMAN will assume that the source platform is the same as the platform of the host performing the conversion.
The result is a set of converted datafiles in the /orahome/dbs/
directory, named thus:
/orahome/dbs/fin/fin01.dbf
/orahome/dbs/fin/fin02.dbf
/orahome/dbs/hr/hr01.dbf
/orahome/dbs/hr/hr02.dbf
From this point, follow the rest of the general outline for tablespace transport. Plug the converted tablespaces into the new database with the import utility, and make the tablespaces read-write if applicable.
Note the following restrictions on CONVERT
TABLESPACE
and CONVERT
DATAFILE
:
Both source and destination databases must be running with the COMPATIBLE
initialization parameter set to 10.0 or higher.
Not all combinations of source and destination platforms are supported. To determine whether your source and destination platforms are supported, query V$TRANSPORTABLE_PLATFORM
. If both the source and destination platforms are listed in this view, then CONVERT
can be used to prepare datafiles from one platform for use on the other.
A tablespace must be made read-write at least once in release 10g before it can be transported to another platform using CONVERT
. Hence, any read-only tablespaces (or previously transported tablespaces) from a previous release must first be made read-write before they can be transported to another platform.
RMAN does not process user datatypes that require endian conversions.
Prior to release 10g, CLOBs were created with a variable-width character set and stored in an endian-dependent format. The CONVERT
command does not perform conversions on these CLOBs. Instead, RMAN captures the endian format of each LOB column and propagates it to the target database. Subsequent reads of this data by the SQL layer interpret the data correctly based upon either endian format, and write the data out in an endian-independent format if the tablespace is writeable.
CLOBs created in Oracle Database Release 10g are stored in character set AL16UTF16
, which is platform-independent.
The RMAN CONVERT
DATABASE
command is used to automate the movement of an entire database from one platform (the source platform) to another (the destination platform). Provided that the source and destination platforms are of the same endian format, RMAN automates most of the steps of creating a new database on the destination platform, which contains the same data as the source database, and which has, with a few exceptions, the same settings as the source database.
The CONVERT
DATABASE
command is one step in a longer process for transporting databases across platforms, which is described in the following sections. As with transporting tablespaces, the RMAN CONVERT
DATABASE
step in the process can be performed either on the source platform or the destination platform. The overall transport process changes depending upon whether you perform the CONVERT
DATABASE
step on the source or destination platform.
Files automatically transported to the destination platform during cross-platform database transport include:
Datafiles that belong to permanent tablespaces.
Note:
In spite of the fact that the endian formats for the source and destination platform are the same, the datafiles for a transportable database must undergo a conversion process and cannot simply be copied directly from one platform to another, as is possible with transporting tablespaces.Unlike transporting tablespaces across platforms, transporting entire databases requires that certain types of blocks, such as blocks in undo segments, be reformatted to ensure compatibility with the destination platform.
If a PFILE is used, it is transported. If an SPFILE is used, a PFILE is generated based on the SPFILE and transported, and a new SPFILE is created at the destination based on the settings in the PFILE.
Note:
In most cases, some parameters in the PFILE require manual updating for the new database. For example, you may change theDB_NAME
, as well as parameters such as CONTROL_FILES
that indicate the locations of files on the destination host.This section contains the following topics:
CONVERT DATABASE, Converting Datafiles on the Source Platform
CONVERT DATABASE. Converting Datafiles on the Destination Host
The principal restriction on cross-platform transportable database is that the source and destination platform must share the same endian format. For example, while you can transport a database from Microsoft Windows to Linux for x86 (both little-endian), or from HP-UX to AIX (both big-endian), you cannot transport a whole database from HP_UX to Linux for x86 using this feature. You can, however, create a new database on a destination platform manually, and transport needed tablespaces from the source database using cross-platform transportable tablespace as described in "Cross-Platform Tranportable Tablespace: CONVERT DATAFILE or TABLESPACE".
Also note that some parts of the database cannot be transported directly:
Redo log files and control files from the source database are not transported. New control files and redo log files are created for the new database during the transport process, and an OPEN RESETLOGS is performed once the new database is created.
Note:
The control file for the converted database does not contain a copy of the RMAN repository information from the source database. Backups from the source database cannot be used with the converted database.BFILEs are not transported. RMAN provides a list of objects using the BFILE datatype in the output for the CONVERT
DATABASE
command, but users must copy the BFILEs themselves and fix their locations on the destination database.
Tempfiles belonging to locally managed temporary tablespaces are not transported. The temporary tablespace will be re-created on the target platform when the transport script is run.
External tables and directories are not transported. RMAN provides a list of affected objects as part of the output of the CONVERT
DATABASE
command, but users must redefine these on the destination platform. See Oracle Database Administrator's Guide for more information on managing external tables and directories.
Password files are not transported. If a password file was used with the source database, the output of CONVERT
DATABASE
includes a list of all usernames and their associated privileges. Create a new password file on the destination database using this information. See Oracle Database Security Guide for more information on managing password files.
The process for using cross-platform transportable database differs depending upon whether you choose to perform the conversion of database files on the source or destination system. This section contains the following topics:
The DMBS_TDB
PL/SQL package defines two functions used in preparing for a CONVERT
DATABASE
operation. Their use is described in the following sections:
See also:
PL/SQL Packages and Types Reference for more details about the DBMS_TDB packageNote:
Each of these subprograms is best run withSERVEROUTPUT
set to ON
, so that the descriptive output of the subprogram is visible.DBMS_TDB.CHECK_DB
checks whether a database can be transported to a desired destination platform, and whether the current state of the database permits transport. It can be called without arguments to see if any condition at the source database prevents transport. It can also be called with one or both of the following arguments:
Table 15-1 CHECK_DB Procedure Parameters
Parameter | Description |
---|---|
|
The name of the destination platform, as it appears in This parameter is optional, but is required when the |
|
Specifies which, if any, parts of the database to skip when checking whether the database can be transported. Supported values (of type
|
DBMS_TDB.CHECK_DB
returns TRUE
if the source database can be transported using CONVERT
DATABASE
, and FALSE
otherwise.
Make sure your database is open in read-only mode, then call DBMS_TDB.CHECK_DB
with appropriate parameters.
If SERVEROUTPUT
is ON
, and DBMS_TDB.CHECK_DB
returns FALSE
, then the output includes the reason why the database cannot be transported. Possible conditions preventing the use of CONVERT
DATABASE
and their resolution are listed in the following table:
Table 15-2 Condtitions Tested by CHECK_DB Preventing Use of CONVERT DATABASE
Condition | Action |
---|---|
Unrecognized target platform name. |
Check |
Target platform has a different endian format. |
Conversion is not supported. |
Database is not open read-only. |
Open database read-only and retry. |
There are active or in-doubt transactions in the database. |
Open the database read-write. After the active transactions are rolled back and the in-doubt transactions are resolved, open the database read-only and retry. This can happen if users flashback the database and open it read only. The active transactions will be rolled back when the database is opened read-write. |
Deferred transaction rollback needs to be done. |
Open the database read-write and bring online the necessary tablespaces. Once the deferred transaction rollback is complete, open the database read-only and retry. |
Database compatibility version is below 10. |
Change the init.ora |
Some tablespaces have not been open read-write with compatibility version is 10 or higher. |
Change the init.ora |
This example illustrates the use of CHECK_DB
on a 32-bit Linux platform for transporting a database to 32-bit Windows, skipping read-only tablespaces, with a database that is currently open read-write.
SQL> set serveroutput on SQL> declare db_ready boolean; begin db_ready := dbms_tdb.check_db('Microsoft Windows IA (32-bit)',dbms_tdb.skip_readonly); end; / Database is not open READ ONLY. Please open database READ ONLY and retry. PL/SQL procedure successfully completed.
If you call DBMS_TDB.CHECK_DB
and no messages are displayed indicating conditions preventing transport before the PL/SQL procedure successfully completed
message, then your database is ready for transport.
DBMS_TDB.CHECK_EXTERNAL
must be used to identify any external tables, directories or BFILEs. RMAN cannot automate the transport of such files.
DBMS_TDB.CHECK_EXTERNAL
takes no parameters. With SERVEROUTPUT
set to ON
, the output of DBMS_TDB.CHECK_EXTERNAL
lists the external tables, directories and BFILEs of your database.
The following example shows how to call DBMS_TDB.CHECK_EXTERNAL
:
SQL> set serveroutput on SQL> declare external boolean; begin /* value of external is ignored, but with SERVEROUTPUT set to ON * dbms_tdb.check_external displays report of external objects * on console */ external := dbms_tdb.check_external; end;
If there are no external objects, then this procedure completes with no output. If there are external objects, however, the output will be similar to the following example:
The following external tables exist in the database: SH.SALES_TRANSACTIONS_EXT The following directories exist in the database: SYS.DATA_PUMP_DIR, SYS.MEDIA_DIR, SYS.DATA_FILE_DIR, SYS.LOG_FILE_DIR The following BFILEs exist in the database: PM.PRINT_MEDIA PL/SQL procedure successfully completed.
The process for using CONVERT
DATABASE
is different depending upon whether the conversion is performed on the source platform or the destination platform. This section includes the following topics:
CONVERT DATABASE, Converting Datafiles on the Source Platform
CONVERT DATABASE. Converting Datafiles on the Destination Host
When the RMAN CONVERT
DATABASE
step is to be performed on the source platform, the process for transporting databases across platforms works as follows:
In preparation for transporting the database, the source database must be opened read-only.
SQL> STARTUP MOUNT; SQL> ALTER DATABASE OPEN READ ONLY;
Use the CHECK_DB
function in the DBMS_TDB
package as described in "Preparing for CONVERT DATABASE: Using the DBMS_TDB Package" to ensure that no conditions exist that would prevent the transport of the database, such as incorrect compatibility settings, in-doubt or active transactions, or incompatible endian formats between the source platform and the desired destination platform.
set serveroutput on declare db_ready boolean; begin /* db_ready is ignored, but with SERVEROUTPUT set to ON any * conditions preventing transport will be output to console */ db_ready := dbms_tdb.check_db('Microsoft Windows IA (32-bit)', dbms_tdb.skip_none); end;
DBMS_TDB.CHECK_EXTERNAL
must be used to identify any external objects:
SQL> set serveroutput on SQL> declare external boolean; begin /* value of external is ignored, but with SERVEROUTPUT set to ON * dbms_tdb.check_external displays report of external objects * on console */ external := dbms_tdb.check_external; end;
Typical output of DBMS_TDB.CHECK_EXTERNAL
is shown in this example:
The following external tables exist in the database: SH.SALES_TRANSACTIONS_EXT The following directories exist in the database: SYS.DATA_PUMP_DIR, SYS.MEDIA_DIR, SYS.DATA_FILE_DIR, SYS.LOG_FILE_DIR The following BFILEs exist in the database: PM.PRINT_MEDIA PL/SQL procedure successfully completed.
When the database is ready for transport, the RMAN CONVERT
DATABASE
command is run, specifying a destination platform and how to name the output files. RMAN produces the files needed to move the database to the destination system, including the following:
A complete copy of the datafiles of the database, ready to be transported
A PFILE for use with the new database on the destination platform, containing settings used in the PFILE or SPFILE from the source database. Several entries at the top of the PFILE should be edited when the database is moved to the destination platform:
# Please change the values of the following parameters: control_files = "/tmp/convertdb/cf_D-NEWDBT_id-1778429277_00gb9u2s" db_recovery_file_dest = "/tmp/convertdb/orcva" db_recovery_file_dest_size= 10737418240 instance_name = "NEWDBT" service_names = "NEWDBT.regress.rdbms.dev.us.oracle.com" plsql_native_library_dir = "/tmp/convertdb/plsqlnld1" db_name = "NEWDBT"
A transport script, which contains SQL statements used to create the new database on the destination platform
The following example demonstrates the use of CONVERT
DATABASE
on the source platform, along with its outputs. Output related to the transport script and the parameter file for the new database is highlighted.
RMAN> CONVERT DATABASE NEW DATABASE 'newdb' transport script '/tmp/convertdb/transportscript' to platform 'Microsoft Windows IA (32-bit)' db_file_name_convert '/disk1/oracle/dbs' '/tmp/convertdb' ; Starting convert at 25-JAN-05 using channel ORA_DISK_1 External table SH.SALES_TRANSACTIONS_EXT found in the database Directory SYS.DATA_PUMP_DIR found in the database Directory SYS.MEDIA_DIR found in the database Directory SYS.DATA_FILE_DIR found in the database Directory SYS.LOG_FILE_DIR found in the database BFILE PM.PRINT_MEDIA found in the database User SYS with SYSDBA and SYSOPER privilege found in password file User OPER with SYSDBA privilege found in password file channel ORA_DISK_1: starting datafile conversion input datafile fno=00001 name=/disk1/oracle/dbs/tbs_01.f converted datafile=/tmp/convertdb/tbs_01.f channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:15 channel ORA_DISK_1: starting datafile conversion input datafile fno=00002 name=/disk1/oracle/dbs/tbs_ax1.f converted datafile=/tmp/convertdb/tbs_ax1.f channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:03 . . . channel ORA_DISK_1: starting datafile conversion input datafile fno=00016 name=/disk1/oracle/dbs/tbs_52.f converted datafile=/tmp/convertdb/tbs_52.f channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:01 Run SQL script /tmp/convertdb/transportscript on the target platform to create database Edit init.ora file init_00gb3vfv_1_0.ora.This PFILE will be used to create the database on the target platform To recompile all PL/SQL modules, run utlirp.sql and utlrp.sql on the target platform To change the internal database identifier, use DBNEWID Utility Finished backup at 25-JAN-05 RMAN>
When CONVERT
DATABASE
completes, the source database may be opened read-write again. Then, all of the files produced must then be copied to the destination host.
Place the datafiles in the desired locations on the destination host. If the path to the datafiles is different on the destination, then edit the transport script to refer to the new datafile locations. Also edit the PFILE to change any settings for the destination database.
Then execute the transport script in SQL*Plus to create the new database on the destination host.
SQL> @transportscript
When the transport script finishes, the creation of the new database is complete.
You may choose to convert the datafiles of the database being transported on the destination platform instead of the source platform. Reasons for doing this include:
Avoiding any performance overhead on the source host due to the conversion process.
Distributing a database from one source system to multiple recipients on several different platforms.
In such a case, the preparations for the transport process are the same as in "CONVERT DATABASE, Converting Datafiles on the Source Platform". You must still open the database read-only, use DBMS_TDB.CHECK_DB
to identify any conditions that prevent transport, and use DBMS_TDB.CHECK_EXTERNAL
to identify external objects.
The remaining steps are:
Run the RMAN CONVERT DATABASE
command on the source platform specifying the ON TARGET PLATFORM
argument. When used in this manner, the command syntax is as follows:
CONVERT DATABASE ON TARGET PLATFORM CONVERT SCRIPT '/tmp/convertdb/convertscript.rman' TRANSPORT SCRIPT '/tmp/convertdb/transportscript.sql' new database 'newdb' FORMAT '/tmp/convertdb/%U'
As with CONVERT
DATABASE
on the source platform, CONVERT
DATABASE
ON
TARGET
PLATFORM
produces a transport script containing SQL*Plus commands to create a new database on the destination platform, and a PFILE for the new database containing the same settings as the source database.
CONVERT
DATABASE
ON
TARGET
PLATFORM
also generates a convert script containing RMAN CONVERT DATAFILE
commands for each of the datafiles of the database being transported. The source datafiles must be copied unconverted to some temporary location at the destination, and then the convert script must be run at the destination to actually convert the datafiles to a format usable by the destination host. A typical convert script contains commands like the following:
RUN { CONVERT DATAFILE '/disk1/oracle/dbs/tbs_01.f' FROM PLATFORM 'Linux IA (32-bit)' FORMAT '/tmp/convertdb/data_D-TV_I-1778429277_TS-SYSTEM_FNO-1_7qgb9u2s'; CONVERT DATAFILE '/disk1/oracle/dbs/tbs_ax1.f' FROM PLATFORM 'Linux IA (32-bit)' FORMAT '/tmp/convertdb/data_D-TV_I-1778429277_TS-SYSAUX_FNO-2_7rgb9u2s'; CONVERT DATAFILE '/disk1/oracle/dbs/tbs_03.f' FROM PLATFORM 'Linux IA (32-bit)' FORMAT '/tmp/convertdb/data_D-TV_I-1778429277_TS-SYSTEM_FNO-17_7sgb9u2s'; . . . CONVERT DATAFILE '/disk1/oracle/dbs/tbs_51.f' FROM PLATFORM 'Linux IA (32-bit)' FORMAT '/tmp/convertdb/data_D-TV_I-1778429277_TS-TBS_5_FNO-15_8egb9u2u'; CONVERT DATAFILE '/disk1/oracle/dbs/tbs_52.f' FROM PLATFORM 'Linux IA (32-bit)' FORMAT '/tmp/convertdb/data_D-TV_I-1778429277_TS-TBS_5_FNO-16_8fgb9u2u'; }
One CONVERT
DATAFILE
command is generated for each datafile to be converted.
Note that CONVERT
DATABASE
ON
TARGET
PLATFORM
does not produce converted datafile copies.
If the filesystem containing the datafiles of the source database is accessible from the destination system using the same path names, then you can use the convert script on the destination host without any changes. The CONVERT
DATAFILE
commands in the script produce datafile copies in the locations specified by FORMAT
, converted for use with the new database. (Once the convert script has been run, the source database can be opened for read-write access again.)
Otherwise, while the datafiles are still read-only, copy them to a temporary location. (As soon as copies of the datafiles are made, the source database can be opened read-write again.) If necessary, move the copies of the datafiles to a temporary location on the destination host, and then update each CONVERT
DATAFILE
command in the convert script to use the temporary location of each datafile as input and the FORMAT
parameter of each CONVERT
command to specify the desired final location of the datafiles of the transported database.
This example shows the use of CONVERT DATABASE ON TARGET PLATFORM
on the source host, with typical output:
RMAN> convert database on target platform convert script '/tmp/convertdb/convertscript-target' transport script '/tmp/convertdb/transportscript-target' new database 'newdbt' format '/tmp/convertdb/%U' ; Starting convert at 28-JAN-05 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=39 devtype=DISK External table SH.SALES_TRANSACTIONS_EXT found in the database Directory SYS.DATA_PUMP_DIR found in the database Directory SYS.MEDIA_DIR found in the database Directory SYS.DATA_FILE_DIR found in the database Directory SYS.LOG_FILE_DIR found in the database BFILE PM.PRINT_MEDIA found in the database User SYS with SYSDBA and SYSOPER privilege found in password file User OPER with SYSDBA privilege found in password file channel ORA_DISK_1: starting to check datafiles input datafile fno=00001 name=/disk1/oracle/dbs/tbs_01.f channel ORA_DISK_1: datafile checking complete, elapsed time: 00:00:00 channel ORA_DISK_1: starting to check datafiles input datafile fno=00002 name=/disk1/oracle/dbs/tbs_ax1.f channel ORA_DISK_1: datafile checking complete, elapsed time: 00:00:00 channel ORA_DISK_1: starting to check datafiles input datafile fno=00017 name=/disk1/oracle/dbs/tbs_03.f channel ORA_DISK_1: datafile checking complete, elapsed time: 00:00:00 . . . channel ORA_DISK_1: starting to check datafiles input datafile fno=00015 name=/disk1/oracle/dbs/tbs_51.f channel ORA_DISK_1: datafile checking complete, elapsed time: 00:00:00 channel ORA_DISK_1: starting to check datafiles input datafile fno=00016 name=/disk1/oracle/dbs/tbs_52.f channel ORA_DISK_1: datafile checking complete, elapsed time: 00:00:00 Run SQL script /tmp/convertdb/transportscript-target on the target platform to create database Edit init.ora file /tmp/convertdb/init_00gb9u2s_1_0.ora. This PFILE will be used to create the database on the target platform Run RMAN script /tmp/convertdb/convertscript-target on target platform to convert datafiles To recompile all PL/SQL modules, run utlirp.sql and utlrp.sql on the target platform To change the internal database identifier, use DBNEWID Utility Finished backup at 28-JAN-05
Run the convert script on the target platform to prepare the datafiles, and make any desired changes to the parameter file. Then run the transport script to create the new database, as described in "CONVERT DATABASE, Converting Datafiles on the Source Platform".
When the transport script completes, the new database is created.
Native operating system commands such as Linux cp
or Windows COPY
cannot write or read files in Automated Storage Management (ASM) storage. Because RMAN can read and write ASM files, it can be used to copy datafiles into and out of ASM storage, or between ASM disk groups.
If your goal is to migrate parts or all of your database or flash recovery area into ASM storage, see Chapter 16, "Migrating Databases To and From ASM with Recovery Manager". If, however, you just to create copies of some datafiles from non-ASM to ASM storage on the same platform, you can use the CONVERT
command, without specifying a source or destination platform.
The methods available for specifying the output filenames for CONVERT
described in "Rules for Renaming Files with CONVERT TABLESPACE" apply to this use of CONVERT
as well.
Note:
UsingCONVERT
, without specifying a source or destination platform, produces image copies of the datafiles passed to CONVERT
in the locations you specify.
The files produced by using CONVERT
in this manner are identical to the files that would be produced by aBACKUP
AS
COPY
of the same datafiles to the same destination.However, CONVERT
does not record the datafile copies produced in the RMAN repository. The assumption is that these copies are not being created as part of a backup strategy.
Because these copies are not recorded in the repository, RMAN does not try to use them in future restore and recovery operations, or consider them when determining whether the retention policy is satisfied.
Use BACKUP
AS
COPY
to create image copy backups that RMAN can use in future restore and recovery operations.
In this example, two datafiles are copied from the non-ASM storage location /disk1/dbs
to the ASM disk group diskgroup using the CONVERT
DATAFILE
command:
RMAN> convert datafile '/disk1/dbs/my_tbs_f1.df', '/disk1/dbs/my_tbs_f2.df' format '+diskgroup';
CONVERT
DATAFILE
can be used in this manner to copy datafiles even if they are not part of the connected target database.
This example illustrates copying a single datafile out of ASM storage using CONVERT
DATAFILE
:
RMAN> convert datafile "+DATAFILE/tbs_21.f" format "/tmp/conv_df_%U"; Starting backup at 03-JUN-05 using channel ORA_DISK_1 channel ORA_DISK_1: starting datafile conversion input filename=+DATAFILE/tbs_21.f converted datafile=/tmp/conv_df_data_D-L2_I-2786301554_TS-TBS_2_FNO-6_18gm2hft channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:02 Finished backup at 03-JUN-05
In this example, the datafiles of tablespace tbs_2
(stored in ASM) are copied from an ASM storage location to non-ASM storage using the CONVERT
TABLESPACE
command:
RMAN> convert tablespace tbs_2 format '/tmp/tbs_2_%U.df'; Starting backup at 03-JUN-05 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=20 devtype=DISK channel ORA_DISK_1: starting datafile conversion input datafile fno=00006 name=+DATAFILE/tbs_21.f converted datafile=/tmp/tbs_2_data_D-L2_I-2786301554_TS-TBS_2_FNO-6_11gm2fq9.df channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:01 channel ORA_DISK_1: starting datafile conversion input datafile fno=00007 name=+DATAFILE/tbs_22.f converted datafile=/tmp/tbs_2_data_D-L2_I-2786301554_TS-TBS_2_FNO-7_12gm2fqa.df channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:01 channel ORA_DISK_1: starting datafile conversion input datafile fno=00019 name=+DATAFILE/tbs_25.f converted datafile=/tmp/tbs_2_data_D-L2_I-2786301554_TS-TBS_2_FNO-19_13gm2fqb.df channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:01 channel ORA_DISK_1: starting datafile conversion input datafile fno=00009 name=+DATAFILE/tbs_23.f converted datafile=/tmp/tbs_2_data_D-L2_I-2786301554_TS-TBS_2_FNO-9_14gm2fqc.df channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:01 channel ORA_DISK_1: starting datafile conversion input datafile fno=00010 name=+DATAFILE/tbs_24.f converted datafile=/tmp/tbs_2_data_D-L2_I-2786301554_TS-TBS_2_FNO-10_15gm2fqd.df channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:01 Finished backup at 03-JUN-05