You can use RMAN to transport tablespaces across platforms with different endian formats. You can also use RMAN to transport an entire database to a different platform so long as the two platforms have the same endian format.
This chapter contains the following topics:
Overview of Cross-Platform Data Transport Using Image Copies
Performing Cross-Platform Tablespace Conversion with Image Copies
Performing Cross-Platform Data File Conversion with Image Copies
Performing Cross-Platform Database Conversion with Image Copies
Performing Cross-Platform Database Transport with Backup Sets
Performing Cross-Platform Transport of Read-Only Tablespaces Using Backup Sets
Overview of Cross-Platform Transport of Tablespaces Using Inconsistent Backups
Performing Cross-Platform Transport of Tablespaces Using Inconsistent Backups
Cross-platform transportable tablespace is a variation of ordinary transportable tablespace. All of the restrictions that apply to transportable tablespaces apply here also, such as the need to ensure that all of the objects being transported are completely contained within the set of tablespaces being transported. Cross-platform transportable tablespace can be performed between platforms that have the same, or different, endian format.
Cross-platform transportable database is not the same thing as transportable tablespace. In this case you are copying an entire database, including the SYSTEM
tablespace from one platform to another. Containment checks are irrelevant, and because the SYSTEM
tablespace is being copied, no export/import step is required. Cross-platform transportable database can only be performed between platforms that have the same endian format.
You can transport tablespaces in a database that runs on one platform into a database that runs on a different platform. Typical uses of cross-platform transportable tablespaces include the following:
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 in which all hosts share the same endian format
Migrating tablespaces across platforms with minimal application downtime
A full discussion of transportable tablespaces, their uses, and the different techniques for creating and using them is found in Oracle Database Administrator's Guide.
You can also use RMAN to transport an entire database from one platform to another. For example, business requirements demand that you run your databases on less expensive servers that use a different platform. In this case, you can use RMAN to transport the entire database rather than re-create it and use import utilities or transportable tablespaces to repopulate the data.
You can convert a database on the destination host or source host. Reasons for converting on the destination host include:
Avoiding 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
Evaluating a migration path for a new platform
RMAN enables you to transport data files, tablespaces, or an entire database from one platform to another. When you transport an entire database to a different platform, the destination platform must have the same endian format as the source platform.
Use one of the following methods to transport data across platforms:
Transport data using image copies
Transport data using backup sets
The Oracle Database maintains a list of internal names for each platform that supports cross-platform data transport. These names are stored in the V$TRANSPORTABLE_PLATFORM
view. Use this view to determine the internal name of the source platform or destination platform. While transporting data across platforms, you may need to specify the exact name of the source or destination platform. Any platform names specified as a parameter of the CONVERT
or BACKUP
command must be entered exactly as shown in the V$TRANSPORTABLE_PLATFORM
view.
Use the following query to obtain the platform name of the connected database:
SELECT PLATFORM_NAME FROM V$TRANSPORTABLE_PLATFORM WHERE PLATFORM_ID = ( SELECT PLATFORM_ID FROM V$DATABASE );
Use the following query to obtain the name of the Linux platform:
SELECT PLATFORM_ID, PLATFORM_NAME, ENDIAN_FORMAT FROM V$TRANSPORTABLE_PLATFORM WHERE UPPER(PLATFORM_NAME) LIKE '%LINUX%';
RMAN enables you to use image copies to transport tablespaces, data files, or an entire database. You use the RMAN CONVERT
command to perform cross-platform transport with image copies. Tablespace transport is sometimes performed by individually transporting the data files that store the tablespace data. However, it is not possible to transport a single data file that is part of a tablespace that consists of multiple data files.
You must use the RMAN CONVERT
command in a transportable tablespace operation when the source platform is different from the destination platform and the endian formats are different. If you are converting part of the database between platforms that have the same endian format, you can use operating system methods to copy the files from the source to the destination. If you are converting an entire, same endian database, any data files with undo information must be converted. You cannot copy these files directly from the source to the destination platform.
You can perform tablespace conversion with the RMAN CONVERT
TABLESPACE
command on the source host, but not on the destination host. The CONVERT TABLESPACE
command does not perform in-place conversion of data files. Rather, the command produces output files in the correct format for use on the destination platform. The command does not alter the contents of data files in the source database.
You can use the CONVERT
DATAFILE
command to convert files. Typically, the CONVERT DATAFILE
command is used on the destination host and the CONVERT TABLESPACE
command is used on the source host. When you use the CONVERT DATAFILE
command on the source host, ensure that data files are cleanly offline or the tablespaces containing those data files are read-only. The Data Pump Export utility generates an export dump file that, with data files manually copied to the destination host, can be imported into the destination database. Until the Data Pump export dump file is imported into the destination database, the data files are not associated with a tablespace name in the database. In this case, RMAN cannot translate the tablespace name into a list of data files. Therefore, you must use CONVERT
DATAFILE
and identify the data files by file name.
Note:
UsingCONVERT TABLESPACE
or CONVERT DATAFILE
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 follow the procedures in this chapter.To convert a whole database to a different platform, both platforms must use the same endian format. The RMAN CONVERT
DATABASE
command automates the movement of an entire database from a source platform to a destination platform. The transported database contains the same data as the source database and also has, with a few exceptions, the same settings as the source database.
Files automatically transported to the destination platform include:
Data files that belong to permanent 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. Even though the endian formats for the source and destination platforms are the same, certain types of files must undergo a conversion process. See "Checking the Database Before Cross-Platform Database Conversion" for details about the types of files that need conversion.
Initialization parameter file or server parameter file
If the database uses a text-based initialization parameter file, then RMAN transports it. If the database uses a server parameter file, then RMAN generates an initialization parameter file based on the server parameter file, transports it and creates a new server parameter file at the destination based on the settings in the initialization parameter file.
Usually, some parameters in the initialization parameter file require manual updating for the new database. For example, you may change the DB_NAME
and parameters such as CONTROL_FILES
that indicate the locations of files on the destination host.
You can convert the format of the data files either on the source platform or on the destination platform. The CONVERT DATABASE ON DESTINATION PLATFORM
command does not convert the format of data files. Rather, it generates scripts that you can run manually to perform the conversion. The CONVERT SCRIPT
parameter creates a convert script that you can manually execute at the destination host to convert data file copies in batch mode. The TRANSPORT SCRIPT
parameter generates a transport script that contains SQL statements to create the new database on the destination platform.
See Also:
My Oracle Support Note 1079563.1, "RMAN DUPLICATE/RESTORE/RECOVER Mixed Platform Support" for the following information:List of platform combinations that do not require the CONVERT DATABASE
command
Prerequisites for the source database and destination databases
See Also:
http://www.oracle.com/goto/maa
for best practices on using cross-platform transportable tablespace and database procedures as part of data migration tasksSee Also:
The following sections describe how to perform cross-platform data transport using image copies:"Performing Cross-Platform Tablespace Conversion with Image Copies"
"Performing Cross-Platform Data File Conversion with Image Copies"
"Checking the Database Before Cross-Platform Database Conversion"
"Converting Data Files on the Source Host When Transporting a Database"
"Converting Data Files on the Destination Host When Transporting a Database"
See the list of CONVERT
command prerequisites described in Oracle Database Backup and Recovery Reference. Meet all these prerequisites before doing the steps in this section.
For purposes of illustration, assume that you must transport tablespaces finance
and hr
from source database prod_source
, which runs on a Sun Solaris host. You plan to transport them to destination database prod_dest
running on a Linux PC. You plan to store the converted data files in the temporary directory /tmp/transport_linux/
on the source host.
To perform cross-platform tablespace conversion with image copies:
Start SQL*Plus and connect to the source database prod_source
with administrator privileges.
Query the name for the destination platform in the V$TRANSPORTABLE_PLATFORM
view.
The PLATFORM_NAME
for Linux on a PC is Linux IA (64-bit)
.
See Also:
"Platforms that Support Cross-Platform Data Transport" for information about determining the platform nameCheck if the tablespaces to be transported are self-contained by executing the DBMS_TTS.TRANSPORT_SET_CHECK
procedure. If the TRANSPORT_SET_VIOLATIONS
view contains rows corresponding to the specified tablespaces, then you must resolve the dependencies before proceeding with the conversion.
Place the tablespaces to be transported in read-only mode. For example, enter:
ALTER TABLESPACE finance READ ONLY; ALTER TABLESPACE hr READ ONLY;
Choose a method for naming the output files.
You must use the FORMAT
or DB_FILE_NAME_CONVERT
arguments to the CONVERT
command to control the names of the output files. The rules are listed in order of precedence:
Any file that matches any pattern provided in the DB_FILE_NAME_CONVERT
clause is named based upon this pattern.
If you specify a FORMAT
clause, then any file not named based on the pattern provided in the DB_FILE_NAME_CONVERT
clause is named based on the FORMAT
pattern.
Note:
You cannot use theDB_FILE_NAME_CONVERT
clause to generate output file names for the CONVERT
command when the source and destination files have Oracle Managed File names.Start RMAN and connect to the source database (not the destination database) as TARGET
. For example, enter:
% rman RMAN> CONNECT TARGET "sbu@prod_source AS SYSBACKUP";
Run the CONVERT TABLESPACE
command to convert the data files into the endian format of the destination host.
In the following example, the FORMAT
argument controls the name and location of the converted data files:
RMAN> CONVERT TABLESPACE finance,hr 2> TO PLATFORM 'Linux IA (64-bit)' 3> FORMAT '/tmp/transport_linux/%U';
The result is a set of converted data files in the /tmp/transport_linux/
directory, with data in the correct endian format for the Linux IA (64-bit) platform.
See Also:
Oracle Database Backup and Recovery Reference for the full semantics of theCONVERT
commandFollow the rest of the general outline for transporting tablespaces:
Use the Oracle Data Pump Export utility to create the export dump file on the source host.
Move the converted data files and the export dump file from the source host to the desired directories on the destination host.
Plug the tablespace in to the new database with the DataPump Import utility.
If applicable, place the transported tablespaces into read/write mode.
See Also:
Oracle Database Administrator's Guide for information about using transportable tablespacesSee the list of CONVERT
command prerequisites described in Oracle Database Backup and Recovery Reference. Meet these prerequisites before performing the steps in this section.
Data file conversion necessitates that you choose a technique for naming the output files. You must use the FORMAT
or DB_FILE_NAME_CONVERT
arguments to the CONVERT
command to control the naming of output files. The rules are listed in order of precedence:
Any file that matches any pattern provided in the DB_FILE_NAME_CONVERT
clause is named based upon this pattern.
If you specify a FORMAT
clause, then any file not named based on the pattern provided in the DB_FILE_NAME_CONVERT
clause is named based on the FORMAT
pattern.
Note:
You cannot use theDB_FILE_NAME_CONVERT
clause to generate output file names for the CONVERT
command when both the source and destination files are Oracle Managed Files.If the source and destination platforms differ, then you must specify the FROM PLATFORM
parameter. View platform names by querying the V$TRANSPORTABLE_PLATFORM
. The FROM PLATFORM
value must match the format of the data files to be converted to avoid an error. If you do not specify FROM PLATFORM
, then this parameter defaults to the value of the destination platform.
See Also:
"Platforms that Support Cross-Platform Data Transport" for information about determining the platform nameThis section explains how to use the CONVERT DATAFILE
command. The section assumes that you intend to transport tablespaces finance
(data files fin/fin01.dbf
and fin/fin02.dbf
) and hr
(data files hr/hr01.dbf
and hr/hr02.dbf
) from a source database named prod_source
. The database runs on a Sun Solaris host. You plan to transport these tablespaces into a destination database named prod_dest
, which runs on a Linux PC. You plan to perform conversion on the destination host.
When the data files are plugged in to the destination database, you plan to store them in /orahome/dbs
and preserve the current directory structure. That is, data files for the hr
tablespace are stored in the /orahome/dbs/hr
subdirectory, and data files for the finance
tablespace are stored in the /orahome/dbs/fin
directory.
To perform cross-platform data file conversion with image copies:
Start SQL*Plus and connect to the source database prod_source
with administrator privileges.
Query the name for the source platform in V$TRANSPORTABLE_PLATFORM
.
For this scenario, assume that the PLATFORM_NAME
for the source host is Solaris[tm] OE (64-bit)
.
See Also:
"Platforms that Support Cross-Platform Data Transport" for information about determining the platform nameIdentify the tablespaces to be transported from the source database and place them in read-only mode.
For example, enter the following SQL statements to place finance
and hr
in read-only mode:
ALTER TABLESPACE finance READ ONLY; ALTER TABLESPACE hr READ ONLY;
On the source host, use Data Pump Export to create the export dump file
In this example, the dump file is named expdat.dmp
.
Make the export dump file and the data files to be transported available to the destination host.
You can use NFS to make the dump file and current database files (not copies) accessible. Alternatively, you can use an operating system utility to copy these files to the destination host.
In this example, you store the files in the /tmp/transport_solaris/
directory of the destination host. You preserve the subdirectory structure from the original location of the files; that is, the data files 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
Start RMAN and connect to the destination database (not the source database) as TARGET
. For example, the following command connects to the target database prod_dest
using the sbu
user who is granted the SYSBACKUP
privilege:
% rman RMAN> CONNECT TARGET "sbu@prod_dest AS SYSBACKUP";
Execute the CONVERT DATAFILE
command to convert the data files into the endian format of the destination host.
In this example, you use DB_FILE_NAME_CONVERT
to control the name and location of the converted data files. You also specify the FROM
PLATFORM
clause.
RMAN> CONVERT DATAFILE 2> '/tmp/transport_solaris/fin/fin01.dbf', 3> '/tmp/transport_solaris/fin/fin02.dbf', 4> '/tmp/transport_solaris/hr/hr01.dbf', 5> '/tmp/transport_solaris/hr/hr02.dbf' 6> DB_FILE_NAME_CONVERT 7> '/tmp/transport_solaris/fin','/orahome/dbs/fin', 8> '/tmp/transport_solaris/hr','/orahome/dbs/hr' 9> FROM PLATFORM 'Solaris[tm] OE (64-bit);
The result is a set of converted data files in the /orahome/dbs/
directory that are named as follows:
/orahome/dbs/fin/fin01.dbf
/orahome/dbs/fin/fin02.dbf
/orahome/dbs/hr/hr01.dbf
/orahome/dbs/hr/hr02.dbf
Follow the rest of the general outline for transporting tablespaces:
Plug the tablespace in to the new database with the DataPump Import utility.
If applicable, place the transported tablespaces into read-only mode.
See Also:
Oracle Database Backup and Recovery Reference for the syntax and semantics of the CONVERT
command
Oracle Database Administrator's Guide for information about transportable tablespaces
When you perform cross-platform database conversion with image copies, you can convert the data files on either the source host or the destination host.
This section contains:
Checking the Database Before Cross-Platform Database Conversion
Converting Data Files on the Source Host When Transporting a Database
Converting Data Files on the Destination Host When Transporting a Database
As explained in "Overview of Cross-Platform Data Transport Using Image Copies", you can use the RMAN CONVERT DATABASE
command to automate the copying of an entire database from one platform to another. You convert the database data files on either the source or destination platforms.
Before converting the database, see the list of CONVERT DATABASE
command prerequisites described in Oracle Database Backup and Recovery Reference. Confirm that you meet all these prerequisites before attempting the procedure in this section.
One prerequisite is that both the source and destination platform must share the same endian format. For example, you can transport a database from Microsoft Windows to Linux for x86 (both little-endian), or from HP-UX to AIX (both big-endian), but not from HP-UX to Linux for x86 (big-endian to little-endian).
Note:
If you cannot use theCONVERT DATABASE
command because the platforms do not share endian formats, then you can create a new database on the destination platform and then use cross-platform transportable tablespace to copy your data.When you transport entire databases, note that certain files require RMAN conversion to ensure compatibility with the destination platform. Even though the endian formats for the source and destination platform are the same, these files cannot be simply copied from the source to the destination system. The following kinds of files require RMAN conversion:
Any file containing undo segments
Any file containing automatic segment space management (ASSM) segment headers that is being transported to or from the HP Tru64 platform
Note:
When converting to or from Tru64 UNIX platform, even if the databases use the same endian format, you must use theCONVERT
command to convert data files with automatic segment space management (ASSM) headers. See My Oracle Support Note 732053.1 for information about identifying data files that contain undo data or ASSM headers.The CONVERT DATABASE
command, by default, processes all data files in the database using RMAN conversion. The RMAN conversion copies the files from one location to another, even when it does not make any changes to the file. If you have other preferred means to copy those files that do not require RMAN conversion, you can use the SKIP UNNECESSARY DATAFILES
option of the CONVERT DATABASE
command. If you select this option, then the CONVERT DATABASE
command only processes the files that require conversion. All other files must either be made accessible to the user or copied from the source to the destination database.
Whether the data file conversion is performed at the source or destination host, you must copy the files while the source database is open in read-only mode.
To check the database before cross-platform conversion:
On the source database, start a SQL*Plus session as a user with the SYSDBA
or SYSBACKUP
privilege.
Open the database in read-only mode.
SHUTDOWN IMMEDIATE STARTUP MOUNT ALTER DATABASE OPEN READ ONLY;
Ensure that server output is on in SQL*Plus.
For example, enter the following SQL*Plus command:
SET SERVEROUTPUT ON
Execute the DBMS_TDB.CHECK_DB
function.
This check ensures that no conditions 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 destination platform.
You can call CHECK_DB
without arguments to see if a condition at the source database prevents transport. You can also call this function with the arguments shown in Table 28-1.
Table 28-1 CHECK_DB Function Parameters
Parameter | Description |
---|---|
|
The name of the destination platform as it appears in the 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
|
The following example illustrates executing CHECK_DB
on a 32-bit Linux platform for transporting a database to 32-bit Windows, skipping read-only tablespaces.
DECLARE db_ready BOOLEAN; BEGIN db_ready := DBMS_TDB.CHECK_DB('Microsoft Windows IA (32-bit)',DBMS_TDB.SKIP_READONLY); END; / PL/SQL procedure successfully completed.
If no warnings appear, or if DBMS_TDB.CHECK_DB
returns TRUE
, then you can transport the database. Proceed to Step 6.
If warnings appear, or if DBMS_TDB.CHECK_DB
returns FALSE
, then you cannot currently transport the database. Proceed to Step 5.
Examine the output to learn why the database cannot be transported, fix the problem if possible, and then return to the Step 4.
Execute the DBMS_TDB.CHECK_EXTERNAL
function to identify any external tables, directories, or BFILEs. RMAN cannot automate the transport of these files, so you must copy the files manually and re-create the database directories.
The following example shows how to call the DBMS_TDB.CHECK_EXTERNAL
function.
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 no external objects exist, then the procedure completes with no output. If external objects exist, however, then the output is similar to the following:
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 you transport entire databases, certain types of blocks such as blocks in undo segments must be reformatted to ensure compatibility with the destination platform. Even though the endian formats for the source and destination platform are the same, certain data files must undergo a conversion process and cannot be simply copied from one platform to another.
Data files with undo information and those from the HP Tru64 platform must be converted. By default, all data files are converted when the CONVERT DATABASE
command is executed. If, however, SKIP UNNECESSARY DATAFILES
is used in the CONVERT DATABASE
command, then the data files with undo segments and those from the HP Tru64 platform are converted. All other data files do not require conversion and can be copied to the new database using FTP, an operating system copy command, or some other mechanism.
This section assumes that you have met all of the CONVERT DATABASE
prerequisites and followed the steps in "Checking the Database Before Cross-Platform Database Conversion". The goal of this procedure is to convert the format of data files on the source host as part of a cross-platform database transport.
Assume that you want to convert a database running on Solaris to a database that runs on Windows.
To convert the database on the source host:
Open the source database in read-only mode.
SHUTDOWN IMMEDIATE; STARTUP MOUNT; ALTER DATABASE OPEN READ ONLY;
Start RMAN and connect to the source database as TARGET
as described in "Making Database Connections with RMAN".
Run the CONVERT
DATABASE
command.
The following example shows a CONVERT DATABASE
command (sample output included). The TRANSPORT SCRIPT
parameter specifies the location of the generated SQL script that you can use to create the new database. The TO PLATFORM
parameter indicates the platform of the destination database. The DB_FILE_NAME_CONVERT
parameter specifies the naming scheme for the generated data files.
RMAN> CONVERT DATABASE 2> NEW DATABASE 'newdb' 3> TRANSPORT SCRIPT '/tmp/convertdb/transportscript.sql' 4> TO PLATFORM 'Microsoft Windows IA (32-bit)' 5> DB_FILE_NAME_CONVERT '/disk1/oracle/dbs' '/tmp/convertdb'; Starting conversion at source at 25-NOV-13 using channel ORA_DISK_1 External table SH.SALES_TRANSACTIONS_EXT found in the database . . . Directory SYS.ORACLE_HOME found in the database Directory SYS.ORACLE_BASE 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 SBU with SYSBACKUP 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 Edit init.ora file init_00gb3vfv_1_0.ora. This PFILE will be used to create the database on the target platform Run SQL script /tmp/convertdb/transportscript.sql on the target platform to create database 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 conversion at source at 25-NOV-13
After CONVERT
DATABASE
completes, you can open the source database read/write again.
Move the data files generated by CONVERT DATABASE
to the desired locations on the destination host.
In Step 3, the command creates the files in the /tmp/convertdb/
directory on the source host. Move these files to the directory on the destination host that will contain the destination database files.
If the path to the data files is different on the destination host, then edit the transport script to refer to the new data file locations.
If necessary, edit the initialization parameter file to change any settings for the destination database.
You must edit several entries at the top of the initialization parameter file when the database is moved to the destination platform. For example, the initialization parameter file may look as follows:
# Please change the values of the following parameters: control_files = "/tmp/convertdb/cf_D-NEWDBT_id-1778429277_00gb9u2s" service_names = "NEWDBT.example.com" db_recovery_file_dest = "/tmp/convertdb/orcva" db_recovery_file_dest_size= 10737418240 instance_name = "NEWDBT" db_name = "NEWDBT" plsql_native_library_dir = "/tmp/convertdb/plsqlnld1"
If necessary, edit the transport script to use the new names for the converted data files.
In the example in Step 3, the transport script is named /tmp/convertdb/transportscript.sql
. You run this script on the destination host to create the database. Thus, you must edit this script with the correct names for the data files.
On the destination host, start SQL*Plus and connect to the destination database instance as SYSDBA
or SYSBACKUP
using operating system authentication.
For example, connect as follows:
SQL> CONNECT / AS SYSBACKUP
If you choose not to use operating system authentication, you can create a password file and then connect with a user name and password.
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.
See Also:
Oracle Database Administrator's Guide for information about operating system authentication and password file authenticationThis section assumes that you have met all of the CONVERT DATABASE
command prerequisites and followed the steps in "Checking the Database Before Cross-Platform Database Conversion". The goal of this procedure is to convert the format of data files on the destination host as part of a cross-platform database transport.
Perform the data file conversion in the following phases:
In this procedure, you execute the CONVERT DATABASE
command on the source host. This command generates an initialization parameter file and scripts that you can edit for use on the destination host. You also copy the unconverted data files from the source host to the destination host.
To perform preliminary data file conversion steps on the source host:
Ensure that the database is open in read-only mode.
Start RMAN and connect to the source database as TARGET
, as described in "Making Database Connections with RMAN".
Run the CONVERT
DATABASE ON DESTINATION PLATFORM
command.
The following example shows a sample CONVERT DATABASE
command (sample output included). The ON DESTINATION PLATFORM
parameter specifies that any CONVERT
commands required for data files are executed on the destination platform rather than the source platform. The FORMAT
parameter specifies the naming scheme for the generated files.
RMAN> CONVERT DATABASE 2> ON DESTINATION PLATFORM 3> CONVERT SCRIPT '/tmp/convertdb/convertscript-target' 4> TRANSPORT SCRIPT '/tmp/convertdb/transportscript-target' 5> NEW DATABASE 'newdbt' 6> FORMAT '/tmp/convertdb/%U'; Starting conversion at source at 28-JAN-13 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.ORACLE_HOME found in the database Directory SYS.ORACLE_BASE 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 SBU with SYSBACKUP 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 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 SQL script /tmp/convertdb/transportscript-target on the target platform to create database 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 conversion at source at 28-JAN-13 Starting Control File Autobackup at 28-JAN-13 piece handle=/disk2/oracle/backups/c-1678658224-20131202-02 comment=NONE Finished Control File Autobackup at 28-JAN-13
The previous command creates a transport script, an initialization parameter file for the new database, and a convert script containing RMAN CONVERT DATAFILE
commands for each data file being converted.
Note:
CONVERT
DATABASE
ON
DESTINATION
PLATFORM
does not produce converted data file copies. The command only creates scripts.Use an operating system utility to copy the following files to a temporary location on the destination host:
The data files to be converted
The convert script
The transport script
The initialization file for the destination database
Make the source database read/write.
This section explains how to use the scripts created in the previous section to convert the data files on the destination host and complete the transport process.
The convert script created in the previous phase uses the original data file names of the source database files. The FORMAT
parameter specifies the name that was generated with the FORMAT
or DB_FILE_NAME_CONVERT
parameter of the CONVERT DATABASE
command.
If the data files of the source database are accessible from the destination host with the same path names, then so long as the source database is read-only you can run the convert script on the destination host without any changes. For example, if the source and destination hosts both use NFS to mount a disk containing the source data files, and if the mount point for both hosts is /fs1/dbs/
, then no editing is needed.
To run the conversion scripts on the destination host:
If necessary, edit the convert script.
In the script, one CONVERT
DATAFILE
command exists for each data file to be converted. The convert script must indicate the current temporary file names of the unconverted data files and the output file names of the converted data files. A typical convert script looks as follows:
RUN { CONVERT FROM PLATFORM 'Linux IA (32-bit)' PARALLELISM 10 DATAFILE '/disk1/oracle/dbs/tbs_01.f' FORMAT '/tmp/convertdb/data_D-TV_I-1778429277_TS-SYSTEM_FNO-1_7qgb9u2s' DATAFILE '/disk1/oracle/dbs/tbs_ax1.f' FORMAT '/tmp/convertdb/data_D-TV_I-1778429277_TS-SYSAUX_FNO-2_7rgb9u2s' DATAFILE '/disk1/oracle/dbs/tbs_03.f' FORMAT '/tmp/convertdb/data_D-TV_I-1778429277_TS-SYSTEM_FNO-17_7sgb9u2s' DATAFILE '/disk1/oracle/dbs/tbs_51.f' FORMAT '/tmp/convertdb/data_D-TV_I-1778429277_TS-TBS_5_FNO-15_8egb9u2u' DATAFILE '/disk1/oracle/dbs/tbs_52.f' FORMAT '/tmp/convertdb/data_D-TV_I-1778429277_TS-TBS_5_FNO-16_8fgb9u2u'; }
Edit each DATAFILE
command in the convert script to specify the temporary location of each data file as input. Also, edit the FORMAT
parameter of each command to specify the desired final location of the data files of the transported database.
If necessary, edit the initialization parameter file on the destination host to change settings for the destination database.
You must edit several entries at the top of the initialization parameter file. For example, the initialization parameter file may look as follows:
# 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.example.com" plsql_native_library_dir = "/tmp/convertdb/plsqlnld1" db_name = "NEWDBT"
On the destination host, use SQL*Plus to start the database instance in NOMOUNT
mode.
Specify the initialization parameter file that you copied in the preceding step. For example, enter the following command:
SQL> STARTUP NOMOUNT PFILE='/tmp/init_convertdb_00i2gj63_1_0.ora'
Start RMAN and connect to the destination database (not the source database) as TARGET
. For example, enter the following command:
% rman RMAN> CONNECT TARGET "sbu@prod_dest AS SYSBACKUP";
Run the convert script at the RMAN prompt. For example, enter the following command:
RMAN> @/tmp/convertdb/convertscript-target
Shut down the database instance.
This step is necessary because the transport script that must execute includes a STARTUP NOMOUNT
command.
If necessary, edit the transport script to use the new names for the converted data files.
In the example in Step 3, the transport script is /tmp/convertdb/transportscript.sql
. You run this script on the destination host to create the database. Thus, you must edit this script with the correct names for the data files.
Execute the transport script in SQL*Plus.
For example, create the new database on the destination host as follows:
SQL> @/tmp/convertdb/transportscript
When the transport script completes, the destination database is created.
RMAN can transport databases, data files, and tablespaces across platforms by using backup sets. Performing cross-platform data transport with backup sets enables you to use block compression to reduce the size of backups. This improves backup performance and reduces the time taken to transport backups over the network.
Note:
To perform cross-platform data transport using backup sets, the version of the destination database must be Oracle Database 12c Release 1 (12.1) or later.When you transport an entire database to a different platform, the source platform and the destination platform must use the same endian format. However, user tablespaces can be transported to a destination platform that uses a different endian format from the source platform.
On the source database, you create a cross-platform backup of the data that needs to be transported. A cross-platform backup is an RMAN backup that can be restored on a destination platform that is different from the source platform. On the destination database, you restore and then recover the cross-platform backup to obtain the data that you wanted to transport. Cross-platform backups can be restored on any platform that is supported in the V$TRANSPORTABLE_PLATFORM
view.
RMAN does not catalog backup sets created for cross-platform transport in the control file. This ensures that backup sets created for cross-platform transport are not used during regular restore operations.
Clauses Used to Create Cross-Platform Backups Using Backups Sets
Use the FOR TRANSPORT
or TO PLATFORM
clause in the BACKUP
command to create cross-platform backups. When you create a cross-platform backup of read-only tablespaces using either of these clauses, RMAN can also create a Data Pump export dump file containing the metadata required to plug these tablespaces into the destination database.
Although the TO PLATFORM
and FOR TRANSPORT
clauses are not supported in Oracle Database 10g Release 2 (10.2) or Oracle Database 11g, you can transport data from these versions of the database to Oracle Database 12c Release 1 (12.1). On the source database, you first create backup sets of the tablespaces to be transported and then create the Data Pump export dump file by using the expdp
command. To restore these backups on the destination database, you perform a restore operation using the RESTORE
command and then use the impdp
command to import the Data Pump export dump file.
Steps to Transport Data Across Platforms Using Backup Sets
Transporting data across platforms using backup sets consists of the following high-level steps:
On the source database, use the BACKUP
command to create a cross-platform backup of the database, tablespaces, or data files that need to be transported to a different platform. The backup is created as backup sets on the source host.
Transfer the backup sets created on the source host to the destination host.
You can transport the backup sets using operating system utilities. For example, if your operating system is Linux or UNIX, you can use the cp
command to transfer backup sets.
On the destination database, restore the backup sets that were transferred from the source host. Use the RESTORE
command to restore cross-platform backups.
When you are transporting tablespaces across platforms by using inconsistent tablespace backups, the additional step of recovering the tablespaces is required as described in "Performing Cross-Platform Transport of Tablespaces Using Inconsistent Backups".
See Also:
"About Restoring Data on the Destination Host During Cross-Platform Data Transport"
"About Selecting Objects to Be Restored from Cross-Platform Backups"
"About Names and Locations for Restored Objects on the Destination Database"
"About Importing the Data Pump Export Dump File Created During Cross-Platform Tablespace Transport"
Detailed information about how to transport data across platforms using backup sets, the prerequisites, and the RMAN syntax used are provided in the following sections:
"Performing Cross-Platform Database Transport with Backup Sets"
"Performing Cross-Platform Transport of Read-Only Tablespaces Using Backup Sets"
"Performing Cross-Platform Transport of Tablespaces Using Inconsistent Backups"
Before using backup sets to perform cross-platform data transport, it is useful to understand the following terms.
Data files that do not belong to the destination database are called foreign data files. These data files are being plugged in to the destination database as part of a data transfer to the destination database. In the source database, this data file is identified by its original data file number.
A foreign tablespace is a set of foreign data files that comprise a tablespace in the source database. These foreign data files do not belong to the destination database, but are being transported into the destination database and are identified by the original tablespace name in the source database.
A foreign data file copy is a data file that was restored from a cross-platform backup. It cannot be directly plugged in to the destination database because it is inconsistent. You must apply a cross-platform incremental backup to this data file and recover it before you can plug it in to the destination database.
A Data Pump destination is a location on the disk of the server host of the destination database on which the Data Pump export dump file and the Data Pump log files are stored.
To create the backup set containing data that must be transported to the destination database, use the BACKUP
command on the source database. To indicate that you are creating a cross-platform backup, the BACKUP
command must contain either the FOR TRANSPORT
or TO PLATFORM
clause.
When you use FOR TRANSPORT
, the backup set that is created can be transported to any destination database. If the destination database uses an endian format that is different from that of the source database, then the required endian format conversion is performed on the destination database. The benefit of this method is that the processing overhead of the conversion operation is offloaded to the destination database.
When you use TO PLATFORM
, the endian format conversion is performed on the source database. The target platform specified by the TO PLATFORM
clause must be a supported platform for cross-platform transport. The V$TRANSPORTABLE_PLATFORM
view contains the list of supported platforms.
You can create cross-platform backups that contain multiple backup sets or multiple backup pieces. See the Oracle Database Backup and Recovery Reference for examples.
You cannot use certain clauses of the BACKUP
command when you create a cross-platform backup using either the FOR TRANSPORT
or TO PLATFORM
clause. See Oracle Database Backup and Recovery Reference for information about the clauses that are not compatible with TO PLATFORM
and FOR TRANSPORT
.
When you create a cross-platform consistent tablespace backup, the backup set contains the data files that contain data related to the specified tablespaces. A consistent tablespace backup is a backup of one or more tablespaces that is created when the tablespaces are in read-only mode. After you restore this backup in your destination database, the tablespaces must be plugged in to the destination database. To do this, in addition to the backup set containing the tablespace data, you need the metadata for these tablespaces from the source database.
On the source database, use the DATAPUMP
clause in the BACKUP
command to create the metadata required to plug tablespaces in to the target database. The metadata is stored in a Data Pump export dump file as a separate backup set. Use this backup set to plug the transported tablespaces in to the target database.
You can specify how the backup set containing the tablespace metadata is named by using the FORMAT
option with the DATAPUMP
clause. If you omit the FORMAT
option, then the format specified in the BACKUP
command is used to name the export dump file. When no FORMAT
option is specified in the BACKUP
command, the default format is used.
Note:
When you use theDATAPUMP
clause, the tablespaces that are being transported must be made read-only.On the destination database, you use the RESTORE
command to restore the database, tablespaces, or data files contained in a cross-platform backup consisting of backup sets. When you perform a cross-platform restore operation, you must use the foreignFileSpec
subclause of the RESTORE
command. See Oracle Database Backup and Recovery Reference for more information.
When you restore cross-platform backups, you must specify the following information:
Backup sets that contain data that was backed up on the source database
Use the BACKUPSET
option of the foreignFileSpec
subclause to specify the name of the cross-platform backup set from which data must be restored. If the cross-platform backup consists of multiple backup sets, use a separate BACKUPSET
clause for each backup set. To restore tablespaces, you must specify the backup sets that contain the tablespace data using the BACKUPSET
clause and the backup set that contains the tablespace metadata using the DUMP FILE
option of the foreignFileSpec
subclause.
See Also:
Oracle Database Backup and Recovery Reference for information aboutBACKPSET
and DUMP FILE
Data file numbers or names of tablespaces as they exist in the source database
If you are restoring data files or tablespaces, you can restore specific tablespaces or data files that are contained in a cross-platform backup.
Location where the restored data files must be stored
Use the FORMAT
clause to specify the location and the names used to store the restored data files.
If you do not provide a destination, then the DB_FILE_CREATE_DEST
initialization parameter must be set in the target platform. RMAN restores the data files to the location specified by this parameter using new Oracle Managed File (OMF) names.
Name of the source platform (only when conversion is performed on the destination database)
Use FROM PLATFORM
to specify the name of the source platform on which the backup sets were created. The platform name must exactly match the name specified while creating the backup set. If there is a difference in the platform names, the restore operation fails.
While restoring data from a cross-platform backup, you can either restore all the data contained in the cross-platform backup or only certain objects.
See Also:
Oracle Database Backup and Recovery Reference for more information about the clauses described in this sectionRestoring All Data Contained in the Cross-Platform Backup
To restore the entire database, use the FOREIGN DATABASE
clause in the RESTORE
command. This clause can only be used when restoring from a whole database backup set and when both the source platform and destination platform use the same endian format. You can optionally use the FORMAT
clause to specify the pattern used to name restored files.
To restore all the data files contained in the cross-platform backup, use the ALL FOREIGN DATAFILES
clause in the RESTORE
command.
Restoring Part of the Data Contained in the Cross-Platform Backup Set
You can restore some data files or tablespaces contained in a cross-platform backup. To restore only some data files, use the FOREIGN DATAFILE
clause in the RESTORE
command. Specify the absolute file number of the data file in the source database while restoring data. To restore only some tablespaces contained in a cross-platform backup, use the FOREIGN TABLESPACE
clause in the RESTORE
command. Specify the names of the tablespaces that must be restored as part of this clause.
When you restore a cross-platform backup, specify the data file names and the location to which they are restored using one of the following options in the RESTORE
command:
Use the TO NEW
option with the ALL FOREIGN DATAFILES
clause to restore the data files to the location specified by the DB_FILE_CREATE_DEST
parameter. By default, RMAN uses OMF names for the data files.
Use the FORMAT
option to specify the pattern used to name restored data files. You can also specify the directory for these files as part of the FORMAT
specification.
See Also:
Oracle Database Backup and Recovery Reference for more information about the clauses described in this sectionWhile restoring a cross-platform backup of read-only tablespaces on the destination database, use the DUMP FILE ... FROM BACKUPSET
option of the foreignFileSpec
subclause to restore the backup set that contains the Data Pump export dump file. The export dump file contains the metadata required to plug the tablespace in to the destination database.
Use the DATAPUMP
clause in the RESTORE
command to specify the location on the destination host to which the export dump file is restored. If you omit this clause, the dump file is restored to a default operating system-specific location.
By default, RMAN automatically imports the export dump file after all the required foreign data files are restored. You can choose not to import the export dump file by specifying the NOIMPORT
clause. If you do not import the export dump file as part of the restore operation, then you must manually import the dump file when you want to plug the tablespaces in to the destination database.
Note:
If the export dump file is automatically imported (that is, theNOIMPORT
clause is not used), then the destination database must be open in read/write mode.You can transport an entire database from a source platform to a different destination platform. While creating the cross-platform backup to transport a database, you can convert the database either on the source database or the destination database. The benefit of performing the conversion on the destination database is that the processing overhead of the convert operation is offloaded from the source to the destination database.
Prerequisites for Cross-Platform Database Transport Using Backup Sets
Before you create a cross-platform backup to transport a database across platforms, the following prerequisites must be met:
The COMPATIBLE
parameter in the server parameter file of the source database and the destination database must be set to 12.0.0 or higher.
The source database must be open in read-only mode.
The DBMS_TDB.CHECK_DB
procedure must run successfully.
See Also:
"Checking the Database Before Cross-Platform Database Conversion" for information about using theDBMS_TDB.CHECK_DB
procedureThe source platform and destination platform must use the same endian format.
Scenarios in Which RMAN Automatically Creates a Cross-Platform Backup of the Database
When you use backup sets to back up an entire database RMAN automatically creates a cross-platform backup of the database in addition to the specified backup if the following conditions are met:
Prerequisites for transporting an entire database as a backup set are satisfied.
The BACKUP
command does not contain any clause that is incompatible with the FOR TRANSPORT
or TO PLATFORM
clause.
See Also:
Oracle Database Backup and Recovery Reference for information about the incompatible clausesThe following BACKUP
command creates a cross-platform backup of the database. Although the command does not contain either the FOR TRANSPORT
or TO PLATFORM
clause to indicate that it is a cross-platform backup, because the conditions described in "Prerequisites for Cross-Platform Database Transport Using Backup Sets" are satisfied, an implicit cross-platform backup of the database is created.
RUN { ALLOCATE CHANNEL c1 DEVICE TYPE DISK; ALLOCATE CHANNEL c2 DEVICE TYPE DISK; ALLOCATE CHANNEL c3 DEVICE TYPE DISK; BACKUP SKIP OFFLINE FILESPERSET 1 FORMAT '/tmp/xplat_backups/implicit_full_db_%U' DATABASE;}
Use the following steps to transport an entire database from one platform to another:
Ensure that the prerequisites required to perform cross-platform database transport are met.
Start SQL*Plus and connect to the source database prod_source
with administrator privileges.
% sqlplus sys@prod_source as SYSDBA
When prompted, enter the password for the sys
user.
Query the name of the destination platform in V$TRANSPORTABLE_PLATFORM
.
To transport the entire database, the endian formats of the source platform and the destination platform must be the same.
See Also:
"Platforms that Support Cross-Platform Data Transport" for information about determining the platform nameChoose a method for naming the output files.
Use the FORMAT
clause of the BACKUP
command to specify the names of the output files.
For example, the following FORMAT
clause specifies that the output files must be stored using unique names that begin with transport_
in the directory /oradata/backups/special.
FORMAT '/oradata/backups/special/transport_%U'
Start RMAN and connect to the source database as TARGET
.
The source database is the database that contains the data that needs to be transported to a different platform.
In this example, sbu
is a user who is granted the SYSBACKUP
privilege in the source database prod_source
.
% RMAN RMAN> CONNECT TARGET "sbu@prod_source AS SYSBACKUP";
Enter the password for the sbu
user when prompted.
Place the database in read-only mode.
SHUTDOWN IMMEDIATE; STARTUP MOUNT; ALTER DATABASE OPEN READ ONLY;
Back up the source database using the FOR TRANSPORT
or TO PLATFORM
clause in the BACKUP
command. Using either of these clauses creates a cross-platform backup that uses backup sets.
The following example creates a cross-platform backup of the entire database. This backup can be restored on any supported platform that uses the same endian format as the source database. The source platform is Sun Solaris x86 64-bit. Because the FOR TRANSPORT
clause is used, the conversion is performed on the destination database. The cross-platform database backup is stored in db_trans.bck
in the /tmp/xplat_backups
directory on the source host.
BACKUP FOR TRANSPORT FORMAT '/tmp/xplat_backups/db_trans.bck' DATABASE;
Disconnect from the source database.
Move the backup sets created by the BACKUP
command to the destination host.
Use operating system-specific utilities to transfer the created backup sets from the source host to the destination host.
For example, if the operating system of your source and destination hosts is Linux or UNIX, use the cp
command to move files.
Connect to the destination database, to which the database must be transported, as TARGET
.
In this example, sbu
is a user who is granted the SYSBACKUP
privilege in the destination database prod_dest
.
% RMAN RMAN> CONNECT TARGET "sbu@prod_dest AS SYSBACKUP";
Enter the password for the sbu
user when prompted.
Ensure that the destination database is in NOMOUNT
state.
Restore the backup sets that were transferred from the source by using the RESTORE
command with the FOREIGN DATABASE
clause.
The following example restores the cross-platform database backup created in Step 7. The destination database uses the same endian format as the source database. The FROM PLATFORM
clause specifies the name of the platform on which the backup was created. This clause is required to convert backups on the destination. The backup set containing the cross-platform database backup is stored in the /tmp/xplat_restores
directory on the destination host. The TO NEW
option specifies that the restored foreign data files must use new OMF-specified names in the destination database. Ensure that the DB_CREATE_FILE_DEST
initialization parameter is set.
RESTORE FROM PLATFORM 'Solaris Operating System (x86-64)' FOREIGN DATABASE TO NEW FROM BACKUPSET '/tmp/xplat_restores/db_trans.bck';
Use the BACKUP
command with the FOR TRANSPORT
or TO PLATFORM
clause to create backup sets that can be used to transport read-only tablespaces from one platform to another. When you transport read-only tablespaces, you must also export the metadata of these tablespaces. The metadata is required to plug the tablespaces in to the destination database. While transporting tablespaces across platforms, the source and destination platform can use different endian formats.
You can restore all the data files or tablespaces contained in a cross-platform backup or only some of them. After restoring these objects, you can specify the name and location for the restored data files.
See Also:
Prerequisites for Performing Cross-Platform Tablespace Transport Using Backup Sets
Before you create a cross-platform backup that can be used to transport tablespaces to a different platform, the following prerequisites must be met:
COMPATIBLE
parameter in the server parameter file of the source database and destination database is set to 12.0.0 or greater.
The tablespaces to be transported are in read-only mode, unless the ALLOW INCONSISTENT
clause is used in the BACKUP
command.
The tablespaces to be transported are self-contained.
Execute the DBMS_TTS.TRANSPORT_SET_CHECK
procedure to check for dependencies. If the TRANSPORT_SET_VIOLATIONS
view contains rows corresponding to the specified tablespaces, then you must resolve the dependencies before creating the cross-platform backup.
Ensure that the prerequisites required to transport tablespaces to another platform are met.
Connect to the source database from which you need to transport tablespaces as TARGET
.
In this example, sbu
is a user who is granted the SYSBACKUP
privilege on the source database prod_source
.
$ RMAN RMAN> CONNECT TARGET "sbu@prod_source AS SYSBACKUP";
Enter the password for the sbu
user when prompted.
Query the name of the destination platform in V$TRANSPORTABLE_PLATFORM
.
See Also:
"Platforms that Support Cross-Platform Data Transport" for information about determining the platform namePlace the tablespaces to be transported in read-only mode.
The following command places the tablespace EXAMPLE
in read-only mode.
ALTER TABLESPACE example READ ONLY;
Choose a method for naming the output files.
Use the FORMAT
clause of the BACKUP
command to specify a pattern for naming the output files.
Back up the tablespace on the source database using the BACKUP
command with the TO PLATFORM
or FOR TRANSPORT
clause. Use the DATAPUMP
clause to indicate that an export dump file for the tablespaces must be created. The export dump file is created in its own backup piece.
The following example creates a cross-platform backup of the tablespaces projects
and tasks
that can be restored on the Solaris[tm] OE (64-bit) platform. This backup is stored in the backup set trans_ts.bck
in the /tmp/xplat_backups
directory. The Data Pump export dump file containing metadata required to plug the tablespaces in to the destination database is stored in trans_ts_dmp.bck
in the /tmp/xplat_backups
directory.
RMAN > BACKUP TO PLATFORM 'Solaris[tm] OE (64-bit)' FORMAT '/tmp/xplat_backups/trans_ts.bck' DATAPUMP FORMAT '/tmp/xplat_backups/trans_ts_dmp.bck' TABLESPACE projects, tasks;
Because the TO PLATFORM
clause is used, conversion to the endian format of the destination database is performed on the source database.
Disconnect from the source database.
Move the backup sets created by the BACKUP
command and the Data Pump export dump file to the destination host.
You can use operating system utilities to move the backup sets from the source host to the destination host.
Connect to the destination database, in to which the tablespaces must be transported, as TARGET
.
In this example, sbu
is a user who is granted the SYSBACKUP
privilege on the destination database prod_dest
.
% RMAN RMAN> CONNECT TARGET "sbu@prod_dest AS SYSBACKUP";
Enter the password for the sbu
user when prompted.
Restore the backup sets that were transported from the source database using the RESTORE
command. Use the DUMP FILE
clause to import the export dump file containing the tablespace metadata and plug the tablespaces in to the destination database.
The following example restores the projects
and tasks
tablespaces from the cross-platform backup created in Step 6. The backup set trans_ts.bck
in the /tmp/xplat_restores
directory on the destination host. The Data Pump export dump file containing the metadata that is required to plug these tablespaces in to the destination database is stored in the trans_ts_dump.bck
in the /tmp/xplat_restores
directory.
RMAN> RESTORE FOREIGN TABLESPACE projects, tasks TO NEW FROM BACKUPSET '/tmp/xplat_restores/trans_ts.bck' DUMP FILE FROM BACKUPSET '/tmp/xplat_restores/trans_ts_dmp.bck';
See Also:
Oracle Database Backup and Recovery Reference for additional examples on performing cross-platform backup and restore operationsRMAN enables you to transport inconsistent tablespace backups across platforms. An inconsistent tablespace backup is a backup of one or more tablespaces that is created when the tablespaces are in read/write mode. The term inconsistent refers to the fact that data files in the backup contain changes that were made after the files were checkpointed. The foreign data files produced during a cross-platform inconsistent backup operation cannot be directly plugged in to the destination database. They must be made consistent before they can be opened on the destination database. You make the foreign data files consistent by applying a cross-platform incremental backup, created when the tablespaces are placed in read-only mode, to these foreign data files. This backup must also include the export dump file containing the metadata required for plug the transported tablespaces in to the destination database.
Inconsistent tablespace backups enable you to reduce application downtime. When the tablespaces are online and available to the users, you create cross-platform inconsistent backups on the source database. The first backup must be a level 0 incremental backup. Subsequently, create smaller level 1 incremental backups that contain the changes made to the tablespaces since the most recent level 1 backup. These level 0 and level 1 incremental backups can be restored and applied on the destination database even as other level 1 incremental backups are being created on the source database. You need not wait until all the level 1 incremental backups are created on the source database before you start applying previously-created level 1 backups on the destination database. Since the tablespaces are still online while these incremental backups are being created, there is no application downtime at this stage. The final level 1 incremental backup is created with the tablespaces placed in read-only mode. The application downtime begins at this stage. This final backup must include the metadata required to plug the tablespaces in to the destination database.
On the destination database, you first restore the level 0 incremental backup to create a set of foreign data files. Next, apply the level 1 incremental backups that were created when the tablespaces were in read/write mode to these restored foreign data files. Apply these backups in the same order in which they were created. In most cases, the destination database catches up with the last level 1 incremental backup before the final incremental backup, taken with the tablespaces placed in read-only mode, is created on the source database. The last step is to restore the final level 1 incremental backup, created when the tablespaces were placed in read-only mode, to make the foreign data files consistent. This backup contains the tablespace metadata required to plug the tablespaces in to the destination database.
You can transport inconsistent tablespaces across platforms using backup sets or image copies. Use the BACKUP
command to create a cross-platform backup using backup sets. The CONVERT
command creates cross-platform backups using image copies.
This section describes how to transport inconsistent tablespaces from one platform to another. An example of transporting an inconsistent tablespace across platforms using backup sets is included.
About Creating Inconsistent and Incremental Backups on the Source Database
Use the ALLOW INCONSISTENT
clause in a BACKUP
or CONVERT
command to create a cross-platform inconsistent backup of one or more tablespaces. The tablespaces being transported are in read/write mode when an inconsistent backup is created. To create incremental backups, use the INCREMENTAL LEVEL 1
clause in the BACKUP
command.
The first inconsistent backup is a level 0 incremental backup. Subsequently, you can create multiple cross-platform level 1 incremental backups. The final cross-platform incremental backup must be a consistent backup that is created when the tablespaces are read-only. When you create this final incremental backup, use the DUMP FILE
clause in the BACKUP
command to create the dump file containing the tablespace metadata.
When you use the CONVERT
command, you must explicitly create the export dump file that contains the metadata for the tablespaces by using the Data Pump Export utility.
Note:
TheALLOW INCONSISTENT
clause cannot be used for cross-platform whole database backups.See Also:
"Steps to Transport Inconsistent Tablespaces to a Different Platform" for information about specifying the SCNAbout Restoring and Recovering Inconsistent Backups on the Destination Database
You first restore the cross-platform level 0 incremental backup, taken when the tablespaces are placed in read/write mode, on the destination database. This operation creates restores the backup and creates foreign data file copies. These foreign data files are inconsistent because the tablespaces were not placed in read-only mode when the backup was created. To make these foreign data files consistent and achieve a consistent checkpointed SCN, apply the incremental backups in the order in which they were created. The final incremental backup applied must be a cross-platform incremental backup that was created when the tablespaces were in read-only mode. Next, to plug the tablespaces in to the destination database, you restore and import the dump file that contains the metadata of the tablespaces being transported.
Requirements for Applying Cross-Platform Incremental Backups to the Restored Data Files
To successfully apply a cross-platform incremental tablespace backup to a set of restored foreign data files, the following conditions must be satisfied:
For each data file that is included in the cross-platform incremental backup, the start SCN must be lower than the current checkpoint SCN of the foreign data file copy.
The foreign data file copies created by the restore operation must not be modified.
For example, if a foreign data file copy has been plugged in to the destination database, made read/write, and then made read-only, then RMAN considers that this file has been modified.
This section describes the steps used to transport inconsistent tablespaces across platforms. These steps apply to cross-platform transport using backup sets or image copies.
The prerequisites for transporting inconsistent tablespaces using backup sets are described in "Prerequisites for Performing Cross-Platform Tablespace Transport Using Backup Sets". The prerequisites for transporting inconsistent tablespaces using image copies (CONVERT
command) are described in Oracle Database Backup and Recovery Reference.
This step consists of performing the following tasks in the source database:
Create a cross-platform level 0 inconsistent backup of the tablespaces that must be transported to a different platform. The tablespaces are in read/write mode.
Use the ALLOW INCONSISTENT
and INCREMENTAL LEVEL 0
clauses in the BACKUP
command to indicate that the backup is an inconsistent backup of one or more tablespaces.
Create a cross-platform level 1 incremental backup of the tablespaces that must be transported to another platform. The tablespace are in read/write mode.
Subsequent to the first level 0 inconsistent backup, you can create any number of level 1 incremental backups when the tablespaces are in read/write mode. Use the ALLOW INCONSISTENT
and INCREMENTAL LEVEL 1
clause to create these incremental backups. Performing frequent incremental backups when the tablespaces are in read/write mode is advantageous because this reduces the amount of changed data that needs to be applied to the destination database using the final incremental backup that is taken when the tablespace is read-only.
Create a cross-platform level 1 incremental backup of the tablespaces with the tablespaces in read-only mode.
This is the final incremental backup and it must include the dump file that contains the metadata required to plug the transported tablespaces in to the destination database. Use the INCREMENTAL LEVEL 1
clause in the BACKUP
command to create a level 1incremental backup.
When you perform cross-platform transport using the BACKUP
command, use the DATAPUMP
clause to create the Data Pump export dump files along with the incremental backup. The dump file is created in a separate backup set. When you create cross-platform incremental backups using image copies, you must explicitly create the dump file containing tablespace metadata by using the Data Pump Export utility.
Use FTP, an operating system copy command, or some other mechanism to move the backup sets, data files, and the dump file that were created in the source database to the destination host.
This step consists of performing the following tasks on the destination database:
Restore the cross-platform level 0 inconsistent backup.
This restore operation creates a set of foreign data files on the destination database. These foreign data files are inconsistent, and they need recovery before they can be plugged in to the destination database.
Use the RESTORE
command to restore the cross-platform level 0 inconsistent backup. When you restore a cross-platform inconsistent backups that consist of backup sets, use the FROM BACKUPSET
clause to specify the name of the backup set that contains the level 0 inconsistent backup.
See Also:
Oracle Database Backup and Recovery Reference for information about using theRESTORE
command for cross-platform restore operationsApply the cross-platform level 1 incremental backup, taken when the tablespaces were in read/write mode, to the foreign data files restored in Step 1.
If you created multiple cross-platform level 1 incremental backups, these incremental backups must be applied in the order in which they were created. Use the RECOVER
command to apply the incremental backups. The FOREIGN DATAFILECOPY
clause of the RECOVER
command must list each data file to which the incremental backup must be applied. Use the FROM BACKPSET
clause to specify the name of the backup set that contains the data to be recovered.
Apply the cross-platform level 1 incremental backup, taken when the tablespaces were in read-only mode, to the foreign data files restored in Step 1.
Use the RECOVER
command to apply the incremental backup. The FOREIGN DATAFILECOPY
clause of the RECOVER
command must list each data file to which the incremental backup needs to be applied. Use the FROM BACKPSET
clause to specify the name of the backup set that contains the data to be recovered.
Restore the backup set containing the tablespace metadata.
Use the RESTORE
command to restore the backup set that contains the dump file created during the cross-platform incremental backup. The tablespaces were in read-only mode when this backup was created. You can optionally use the DUMP FILE
clause to specify a name for the dump file on the destination database and the DATAPUMP DESTINATION
clause to specify the directory in which the dump file is restored. If these clauses are omitted, RMAN uses the configured defaults. When transporting data using backup sets, use the FROM BACKUPSET
clause to specify the name of the backup set that contains the dump file.
Import the dump file containing the tablespace metadata into the destination database.
Plug the recovered tablespaces in to the destination database by using the Data Pump Import utility to import the dump file created during the incremental backup. You must run the Data Pump Import utility as a user with the SYSDBA
privilege.
This example transports the inconsistent tablespace my_tbs
from the source database, which is on the Sun Solaris platform, to a destination database on the Linux x86 64-bit platform.
See Also:
"Steps to Transport Inconsistent Tablespaces to a Different Platform" for conceptual information about each step in this exampleThe following steps enable you to transport the inconsistent tablespace my_tbs
across platforms using backup sets:
Connect to the source database as a user who is granted the SYSBACKUP
privilege.
RMAN> CONNECT TARGET "sbu@prod_source AS SYSBACKUP";
Ensure that the prerequisites required to transport tablespaces to another platform are met.
Create a cross-platform level 0 inconsistent backup of the tablespace my_tbs
when the tablespace is read/write mode. This backup is stored in a backup set named my_tbs_incon.bck
in the directory /tmp/xplat_backups
.
BACKUP FOR TRANSPORT ALLOW INCONSISTENT INCREMENTAL LEVEL 0 TABLESPACE my_tbs FORMAT '/tmp/xplat_backups/my_tbs_incon.bck';
Because FOR TRANSPORT
is used instead of TO PLATFORM
, this cross-platform backup can be restored on any platform. The conversion will be performed on the destination database.
Create a cross-platform level 1 incremental backup of the tablespace my_tbs
that contains the changes made after backup in Step 2 was created. The tablespace is still in read/write mode. This incremental backup is stored in my_tbs_incon1.bck
in the directory /tmp/xplat_backups
.
BACKUP FOR TRANSPORT ALLOW INCONSISTENT INCREMENTAL LEVEL 1 TABLESPACE my_tbs FORMAT '/tmp/xplat_backups/my_tbs_incon1.bck';
To minimize application downtime, the level 0 and level 1 incremental backups created in Steps 2 and 3 can be restored and applied on the destination database while the source tablespace is still in read/write mode. When the destination database catches up with last level 1 incremental backup, you can create the final incremental backup with the tablespace placed in read-only mode.
Place the tablespace my_tbs
in read-only mode.
ALTER TABLESPACE my_tbs READ ONLY;
Create the final cross-platform level 1 incremental backup of the tablespace my_tbs
. This backup contains changes made to the database after the backup that was created in Step 3. It must include the export dump file that contains the tablespace metadata.
BACKUP FOR TRANSPORT INCREMENTAL LEVEL 1 TABLESPACE my_tbs FORMAT '/tmp/xplat_backups/my_tbs_incr.bck' DATAPUMP FORMAT '/tmp/xplat_backups/my_tbs_incr_dp.bck';
The incremental backup is stored in my_tbs_incr.bck
. The export dump file containing the tablespace metadata is stored in a backup set named my_tbs_incr_dp.bck
.
The following is a formatted output of the BACKUP
command that was run in this step. The output is edited to display only the relevant information. Observe that the dump file is called backup_tts_RDBMS_13462.dmp
, which is a name assigned by the operating system, and is stored in the directory specified by the DESTINATION
clause.
Starting backup at 12-SEP-12 …… Performing export of metadata for specified tablespaces... EXPDP> Starting "SYS"."TRANSPORT_EXP_RDBMS_zocc": ......... EXPDP> *************************************************************************** EXPDP> Dump file set for SYS.TRANSPORT_EXP_RDBMS_zocc is: EXPDP> /ade/b/191802369/oracle/backup_tts_RDBMS_13462.dmp EXPDP> ************************************************************************** ....... Export completed ....... …… channel ORA_DISK_1: specifying datafile(s) in backup set input datafile file number=00006 name=/ade/b/191802369/oracle/dbs/tbs_11.f input datafile file number=00007 name=/ade/b/191802369/oracle/dbs/tbs_12.f input datafile file number=00020 name=/ade/b/191802369/oracle/dbs/tbs_14.f input datafile file number=00010 name=/ade/b/191802369/oracle/dbs/tbs_13.f …… …… Finished backup at 12-SEP-12
Move the backup sets and the export dump file generated in Steps 2, 3, and 5 from the source host to the desired directories on the destination host.
In this example, all the required files are moved to the directory /tmp/xplat_restores
on the destination host.
Connect to the destination database as a user who is granted the SYSBACKUP
privilege.
RMAN> CONNECT TARGET "sbu@prod_dest AS SYSBACKUP";
sbu
is a user who is granted the SYSBACKUP
privilege in the destination database.
Restore the cross-platform level 0 inconsistent backup created in Step 2.
Use the FOREIGN DATAFILE
clause to specify the data files that must be restored. The FROM PLATFORM
clause specifies the name of the platform on which the backup was created. This clause is required to convert backups on the destination database.
In this example, the data files with numbers 6, 7, 20, and 10 are restored to the names specified in the FORMAT
clause corresponding to that data file. The data file numbers must be the numbers used on the source database. You can obtain the data file numbers from the RMAN output of the inconsistent backup created in Step 2.
RESTORE FROM PLATFORM 'Solaris[tm] OE (64-bit)' FOREIGN DATAFILE 6 FORMAT '/tmp/aux/mytbs_6.df', 7 FORMAT '/tmp/aux/mytbs_7.df', 20 FORMAT '/tmp/aux/mytbs_20.df', 10 FORMAT '/tmp/aux/mytbs_10.df' FROM BACKUPSET '/tmp/xplat_restores/my_tbs_incon.bck';
Recover the foreign data files obtained in Step 8 by applying the first cross-platform level 1 incremental backup that was created Step 3.
RECOVER FROM PLATFORM 'Solaris[tm] OE (64-bit)' FOREIGN DATAFILECOPY '/tmp/aux/mytbs_6.df','/tmp/aux/mytbs_7.df','/tmp/aux/mytbs_20.df','/tmp/aux/mytbs_10.df' FROM BACKUPSET '/tmp/xplat_restores/my_tbs_incon1.bck';
In this example, the incremental backup that is being applied to the restored foreign data files is stored in /tmp/xplat_restores/my_tbs_incon1.bck
.
Recover the foreign data files obtained in Step 8 by applying the final cross-platform level 1 incremental backup that was created in Step 5. This backup was created with the tablespaces in read-only mode.
RECOVER FROM PLATFORM 'Solaris[tm] OE (64-bit)' FOREIGN DATAFILECOPY '/tmp/aux/mytbs_6.df','/tmp/aux/mytbs_7.df','/tmp/aux/mytbs_20.df','/tmp/aux/mytbs_10.df' FROM BACKUPSET '/tmp/xplat_restores/my_tbs_incr.bck';
In this example, the incremental backup that is being applied to the restored foreign data files is stored in /tmp/xplat_restores/my_tbs_incr.bck
.
Restore the backup set containing the export dump file. This dump file contains the tablespace metadata required to plug the tablespaces into the destination database.
RESTORE FROM PLATFORM 'Solaris[tm] OE (64-bit)' DUMP FILE 'my_tbs_restore_md.dmp' DATAPUMP DESTINATION '/tmp/dump' FROM BACKUPSET '/tmp/xplat_restores/my_tbs_incr_dp.bck';
In this example, the dump file is restored to a file called my_tbs_restore_md.dmp
in the directory /tmp/dump
. You can omit the name of the dump file and the DATAPUMP DESTINATION
clause and allow RMAN to use operating-system defaults for these parameters.
Plug the tablespace in to the destination database. Use the Data Pump import utility to import the dump file containing the tablespace metadata in to the destination database.
# impdp directory=dp_dir dumpfile=backup_tts_RDBMS_13462.dmp transport_datafiles='/tmp/aux/mytbs_6.df','/tmp/aux/mytbs_7.df','/tmp/aux/mytbs_20.df','/tmp/aux/mytbs_10.df' nologfile=Y
When prompted for a user name and password, enter the credentials of the SYS
user. In this example, dp_dir
is a directory object that was created using CREATE DIRECTORY
command and is mapped to the /tmp
directory.
RMAN provides support for transporting data across platforms in a multitenant environment. You can transport a whole multitenant container database (CDB), the root only, or one or more pluggable databases (PDBs) across platforms. The cross-platform transport can be performed using images copies or backup sets. The information in this chapter is applicable to CDBs and PDBs with the differences described in the following sections.
This section contains the following topics:
In a CDB, the steps to transport data across platforms are similar to the ones used for non-CDBs. The only difference is that, on both the source and destination databases, you must connect to the root as a common user with the common SYSBACKUP
or SYSDBA
privilege.
To transport an entire CDB, the source platform and the destination platform must use the same endian format.
The BACKUP FOR TRANSPORT
or BACKUP TO PLATFORM
command creates a cross-platform backup of the whole CDB. The CONVERT
command creates image copies of the CDB that can be transported to a different platform.
The following command, when connected to the root, creates a cross-platform backup of the whole CDB:
BACKUP TO PLATFORM 'Linux x86 64-bit' DATABASE FORMAT '/tmp/backups/cdb_%U;
While restoring the cross-platform backup on the destination database, the RESTORE DATABASE
command restores the whole CDB.
See Also:
"Making RMAN Connections to a CDB"To transport an entire PDB to a different platform, the source platform and destination platform must use the same endian format.
Use one of the following techniques to transport PDBs across platforms:
Connect to the root and use the BACKUP FOR TRANSPORT ... PLUGGABLE DATABASE
or BACKUP TO PLATFORM ... PLUGGABLE DATABASE
command to create a cross-platform backup of one or more PDBs.
When you are connected to the root, the following command creates a cross-platform backup of the PDBs hr_pdb
and sales_pdb
. The PDBs must be read-only mode before the cross-platform backup is created.
BACKUP FOR TRANSPORT PLUGGABLE DATABASE hr_pdb, sales_pdb FORMAT '/tmp/backups/pdb_%U';
Connect to the PDB and use the BACKUP FOR TRANSPORT
or BACKUP TO PLATFORM
commands to create backup sets that can be used to transport the PDB data to another platform.
Note:
Performing cross-platform data transport of one or more PDBs by using theCONVERT
command is not supported.See Also:
"Making RMAN Connections to a CDB"RMAN enables you to transport user tablespaces contained in a PDB to a different platform by using either the CONVERT
or BACKUP
command. In this case, the source platform and the destination platform can use different endian formats.
Use one of the following techniques to transport a tablespace in a PDB:
Connect to the PDB as TARGET
and use the BACKUP TABLESPACE
command to create a cross-platform backup of the selected tablespaces.
See "Steps to Transport Read-Only Tablespaces to a Different Platform Using Backup Sets".
Connect to the PDB as TARGET
and use the CONVERT TABLESPACE
command to transport a read-only tablespace.
The following command, when connected to the PDB, converts the read-only tablespace my_tbs
:
CONVERT TABLESPACE my_tbs TO PLATFORM 'Solaris[tm] OE (64-bit)' FORMAT '/tmp/xplat_backups/my_tbs_%U.bck';
Connect to the PDB as TARGET
and use the CONVERT DATAFILE
command.
The following command, when connected to the PDB, converts the data file sales.df
:
CONVERT FROM PLATFORM 'Solaris[tm] OE (64-bit)' DATAFILE '/u01/app/oracle/oradata/orcl/sales.df' FORMAT '/tmp/xplat_backups/sales_df_solaris.dat'
However, when connected as TARGET
to a PDB, you cannot use the CONVERT DATAFILE
command to convert a tablespace that contains undo segments.
This example used the CONVERT
command to transport the tablespace sales_tbs
from the PDB pdb5
to the destination PDB pdb3
. The source PDB is on a Sun Solaris platform and the destination PDB is on a Linux x86 64-bit platform.
Ensure that the required prerequisites are met.
See Also:
"Prerequisites for Performing Cross-Platform Tablespace Transport Using Backup Sets"
Oracle Database Backup and Recovery Reference for the CONVERT
command prerequisites
Start SQL*Plus and connect to the source PDB as a user who is granted the SYSDBA
or SYSBACKUP
privilege.
In this example, sbu
is a user who has been granted the SYSBACKUP
privilege on the source PDB pdb5
.
% sqlplus sbu@pdb5 AS SYSBACKUP
Query the name for the destination platform in the V$TRANSPORTABLE_PLATFORM
view.
In this example, the platform name for the destination platform is Linux x86 64-bit
.
Verify that the tablespace that is to be transported is self-contained.
See Also:
Oracle Database Administrator's Guide for information about determining whether tablespaces are self-containedPlace the tablespace to be transported in read-only mode.
SQL> ALTER TABLESPACE sales_tbs READ ONLY;
Create the directory object that is used to store the files generated by the DataPump export and import utilities.
SQL> CREATE OR REPLACE DIRECTORY xtt_dir AS '/scratch/xtt'; Directory created.
Start RMAN and connect to the source PDB as a user with the SYSDBA
or SYSBACKUP
privilege.
The following example starts RMAN and connects to the source PDB pdb5
as the sbu
user who has been granted the SYSBACKUP
privilege.
% rman RMAN> CONNECT TARGET "sbu@pdb5 as sysbackup"
Convert the tablespace on the source database using the CONVERT
command.
The following command converts the tablespace sales_tbs
to the destination platform Linux x86-64 bit. The converted data files are stored in /tmp/xplat_convert/sales_tbs_conv.bck
.
RMAN> CONVERT TABLESPACE 'SALES_TBS' TO PLATFORM 'Linux x86 64-bit' FORMAT '/tmp/xplat_convert/sales_tbs_conv.bck';
Exit RMAN.
On the source database, use the DataPump export utility to create an export dump file containing the metadata for tablespace sales_tbs
. Use the credentials of the SYS
user to perform the export.
The following command creates an export dump file called sales_tbs_conv.dmp
in the location specified by the directory object xtt_dir
. The credentials used to perform the export are that of the SYS
user.
# expdp "'"sys@pdb5 as sysdba"'" directory=xtt_dir dumpfile=sales_tbs_conv.dmp logfile=sales_tbs_conv.log transport_tablespaces=sales_tbs
Copy the converted data files created in Step 8 and the export dump file created in Step 10 to the destination PDB. You can use operating system commands to copy the files.
On the destination PDB, plug the tablespace into the PDB by using the DataPump import utility. Use the credentials of the SYS
user to perform the import.
The following example imports the metadata contained in the export dump file sales_tbs_conv.dmp
and the converted data files in /tmp/xplat_convert/sales_tbs_conv.bck
into the PDB pdb3
.
#impdp "'"sys@pdb3 as sysdba"'" directory=xtt_dir dumpfile=sales_tbs_conv.dmp datafiles=/tmp/xplat_convert/sales_tbs_conv.bck
Start SQL*Plus and connect to the destination PDB as a user with the SYSDBA
or SYSBACKUP
privilege.
The following command connects to the PDB pdb3
as the sbu
user who has been granted the SYSBACKUP
privilege.
%sqlplus sbu@pdb3 as sysbackup
Verify the status of the converted tablespace on the destination PDB.
The following query determines the status of the tablespace sales_tbs
.
SQL> SELECT status FROM dba_tablespaces WHERE tablespace_name LIKE 'SALES_TBS'; STATUS --------- READ ONLY
Make the tablespace sales_tbs
in the destination PDB pdb3
online.
SQL> ALTER TABLESPACE DUMMY08 READ WRITE;