OracleAppsDBAKK1: V4 Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup (Doc ID 2471245.1)

Purpose

NOTE:  If the source and destination are running Oracle Database 19.18 or higher, see the new version of this procedure:

M5 Cross Endian Platform Migration using Full Transportable Data Pump Export/Import and RMAN Incremental Backups (Doc ID 2999157.1)

This article covers the steps needed to use V4 Cross Platform Transportable Tablespaces (XTTS) with RMAN incremental backups to migrate data between systems that have different endian formats, with the least amount of application down time.

The first step will be to copy a full backup from the source to the destination. Then, by using a series of incremental backups, each smaller than the last, the data at the destination system can be brought nearly current with the source system, before any downtime is required. This procedure requires down time only during the final incremental backup, and the meta-data export/import.

This document describes the V4 procedures for Cross Platform Incremental Backup which can be used with 11.2.0.3 and higher. This new procedure is simplified version of previous XTTs versions. This version has the following differences:

this procedure uses simplified commands. One command (--backup) for the source and one command (--restore) for the destination.
this procedure works for multi-tenant environment, including transporting tablespace from non-CDB to CDB or visa versa. TTS restrictions may apply.
this procedure requires only one file to be copied between the source's and destination's $TMPDIR (res.txt).
this procedure will automatically resolve added datafiles with no additional intervention.
this procedure allows for multiple incremental backups taken off the source without running the recovery. After which, recovery will be of all the incremental backups in the destination at once.

NOTE:
Exadata databases migrating from Solaris (big endian) to Linux (little endian) or vice versa may face block corruptions due to invalid conversion of HCC tables.
ALERT: Possible Block Corruption After Migrating From Solaris to Linux Exadata using HCC (Doc ID 2888288.1)

NOTE: There are a reported issues with multiple incremental backup recovery and large number of datafiles. The recover command creation may cause backups to not be found (ORA-19625) and/or the recovery attempts to apply the backups in the wrong order resulting in:

ORA-19638: file /<path>/<datafile name> is not current enough to apply this incremental backup
ORA-19642: start SCN of incremental backup is <scn>
ORA-19641: backup datafile checkpoint is SCN <scn> time MM/DD/YYYY HH:MM:SS
ORA-19640: datafile checkpoint is SCN <scn> time MM/DD/YYYY HH:MM:SS

Review the following for details and workaround:
V4 XTTs: Restore Returns Errors (ORA-19625 or ORA-19641) With Large Number of Datafiles (Note 2689397.1)

Although it is strongly recommended to use V4 of XTTs, the earlier versions of this procedure is available:

11G - Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup (Note 1389592.1)

The Cross Platform Incremental Backup feature does not affect the amount of time it takes to perform other actions for XTTS, such as metadata export and import. Hence, databases that have very large amounts of metadata (DDL) will see limited benefit from Cross Platform Incremental Backup because migration in these environments is typically dominated by metadata operations, not datafile transfer and conversion.

NOTE: Only those database objects that are physically located in the tablespace(s) being transported will be copied to the destination system. Other objects, such as users, pl/sql objects, sequences, views etc., located in the SYSTEM tablespace will not be transported. You will need to pre-create the users and copy such objects to the destination system, possibly using data pump.

The following may help:

Oracle Database 12c: Full Transportable Export/Import

and/or

MAA paper Platform Migration Using Transportable Tablespaces: Oracle Database.

The high-level steps for Cross Platform Incremental Backup are:

1. Initial setup

2. Prepare phase (source data remains online)

Backup (level=0) of tablespaces to be transported
Transfer backup and other necessary setup files to destination system
Restore datafiles on destination system endian format

3. Roll Forward phase (source data remains online - Repeat this phase as many times as necessary to catch destination datafile copies up to source database)

Create incremental backup on source system
Transfer incremental backup and other necessary setup files to destination system
Convert incremental backup to destination system endian format and apply the backup to the destination datafile copies
Repeat steps until ready to transport the tablespace.

NOTE: In Version 4, added files will automatically be added in the destination with no additional intervention required. I.e., if a datafile is added to the tablespace OR a new tablespace name is added to the xtt.properties file.

4. Transport phase (source data is READ ONLY)

1. Alter the tablespaces in the source database to READ ONLY
2. Repeat the Roll Forward phase one final time
3. Import metadata of objects in the tablespaces into destination database using Data Pump
4. Alter the tablespaces in the destination database to READ WRITE

Scope

The source system may be any platform provided the prerequisites referenced and listed below for both platform and database are met.

If you are migrating from a little endian platform to Oracle Linux, then the migration method that should receive first consideration is Data Guard. See Note 413484.1 for details about heterogeneous platform support for Data Guard between your current little endian platform and Oracle Linux.

Details

NOTE: If the source and destination are running Oracle Database 19.18 or higher, see the new version available:

M5 Cross Endian Platform Migration using Full Transportable Data Pump Export/Import and RMAN Incremental Backups (Doc ID 2999157.1)

NOTE: Before proceeding with this procedure, review the following notes to understand all the restrictions and issues associated with the transportable tablespace feature (TTS). All such restrictions/limitations of TTS apply.

Transportable Tablespace (TTS) Restrictions and Limitations: Details, Reference, and Version Where Applicable (Note 1454872.1)
Primary Note for Transportable Tablespaces (TTS) -- Common Questions and Issues (Note 1166564.1)

Overview

This document provides a procedural example of transporting two tablespaces called TS1 and TS2 from an Oracle Solaris SPARC system to Oracle Linux, incorporating Oracle's Cross Platform Incremental Backup capability to reduce downtime.

After performing the initial setup, moving the data is performed as follows:

Prepare
During the prepare phase, a level =0 backup of the tablespaces' datafiles is taken on the source. The backups are transferred to the destination, datafiles are restored and converted to the destination endian format.

Roll Forward
During the roll forward phase, the datafiles restored during the prepare phase are rolled forward using incremental backups taken from the source database. By performing this phase multiple times, each successive incremental backup becomes smaller and faster to apply, allowing the data at the destination system to be brought almost current with the source system. The application being migrated is fully accessible during the Roll Forward phase.

Transport
During the transport phase, the tablespaces being transported are put into READ ONLY mode, a final incremental backup is taken from the source database, backups are transferred to destination and applied to the destination datafiles. At this point, the destination datafile copies consistent with source database and the application being migrated cannot receive any further updates. The tablespaces then are TTS-exported from the source database and TTS-imported into the destination database. Finally, the tablespaces are made READ WRITE for full access on the destination database.

Cross Platform Incremental Backup Supporting Scripts

The Cross Platform Incremental Backup core functionality was delivered in Oracle Database 11.2.0.3 and later. Some of the features in the prior versions (such as using DBMS_FILE_TRANSFER) are not available in this Version 4. If you need such functionality, use the standard procedure for 11g outlined in Note 1389592.1. The procedures outlined in this note applies to both Oracle 11.2.0.3 and later , 12c and higher. See the Requirements and Recommendations section for details. In addition, a set of supporting scripts in the file rman_xttconvert_VER4.3.zip is attached to this document that are used to manage the procedure required to perform XTTS with Cross Platform Incremental Backup using Version 4.

The two primary supporting scripts files are the following:

Perl script xttdriver.pl script that is run to perform the main steps of the XTTS with Cross Platform Incremental Backup procedure.
Parameter file xtt.properties: the file which stores site-specific configuration.

Prerequisites

The following prerequisites must be met before starting this procedure:

The limitations and considerations for transportable tablespaces must still be followed. They are defined in the following manuals:

Oracle Database Administrator's Guide
Oracle Database Utilities

In addition to the limitations and considerations for transportable tablespaces, the following conditions must be met:
- The current version does NOT support Windows as either source or destination.
- Cross platform is only possible with Enterprise Edition. This procedure cannot be used with Standard Edition.
- The source database's COMPATIBLE parameter must not be greater than the destination database's COMPATIBLE parameter.
- The source database must be in ARCHIVELOG mode.
- Before running XTTs scripts, set NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1. Other NLS_LANG settings may cause errors.
- RMAN on the source system must not have DEVICE TYPE DISK configured with COMPRESSED.
- RMAN on the source system must not have BACKUP TYPE TO COPY. The source must have BACKUP TYPE TO BACKUPSET.
- RMAN on the source system must not have default channel configured to type SBT. I.e., this procedure can only be used with DISK channels.
- RMAN on the source system must not have ANY channel configuration limitations. For example, MAXSETSIZE, MAXPIECESIZE, etc.
- The set of tablespaces being moved must all be online, and contain no offline data files. Tablespaces must be READ WRITE.
- Tablespaces that are READ ONLY may be moved with the normal XTTS method. There is no need to incorporate Cross Platform Incremental Backups to move tablespaces that are always READ ONLY.
- Although preferred destination system is Linux (either 64-bit Oracle Linux or a certified version of RedHat Linux), this procedure can be used with other Unix based operating systems. However, any non-Linux operating system must be running 12.1.0.1 or higher in both destination and source.
- The Oracle version of source must be lower or equal to destination. Therefore, this procedure can be used as an upgrade method. Transportable tablespace restrictions WILL apply.
- Minimum version for source and destination is 11.2.0.3.
- ASM can only be used for final location of datafiles in destination, backups cannot be placed on ASM with this version.
- The backup location of destination MUST be a device with read/write privileges. I.e., cannot be a READONLY device. This can cause ORA-19624 on the backupset conversion.
- The source and target database must use a compatible character set and national character set.
- The tablespace must be in READ WRITE at the first backup, (level 0) otherwise, the following errors will occur:
  RMAN> DECLARE
  2> *
  3> ERROR at line 1:
  4> ORA-20001: TABLESPACE(S) IS READONLY OR,
  5> OFFLINE JUST CONVERT, COPY
  6> ORA-06512: at line 284
  7>
  8>
  9>
  RMAN-00571: ===========================================================
  RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
  RMAN-00571: ===========================================================
  RMAN-00558: error encountered while parsing input commands
  RMAN-01006: error signaled during parse
  RMAN-02002: unexpected end of input file reached

All steps in this procedure are run as the oracle user that is a member of the OSDBA group. OS authentication is used to connect to both the source and destination databases.
Although NOT recommended, a standby database can be used for this procedure. See Using XTTs in a Data Guard Environment (Doc ID 2853054.1)
A Snapshot Standby database is NOT supported for this procedure.
No datafiles should be dropped from the tablespaces being migrated once the migration begins. This can especially be a problem if the datafile number is reassigned to an added datafile to a migrated tablespace.

Whole Database Migration

If Cross Platform Incremental Backups will be used to reduce downtime for a whole database migration, then the steps in this document can be combined with the XTTS guidance provided in the MAA paper Platform Migration Using Transportable Tablespaces: Oracle Database.

Troubleshooting

Debug mode enables additional screen output and causes all RMAN executions to be performed with the debug command line option. To enable debug mode, set the environment variable XTTDEBUG=1 before running xttdriver.pl OR
run xttdriver.pl with the --debug flag. This flag allows for 3 levels, -d [1/2/3] with 3 generating the most information.

As it is recommended to run these steps in debug, so necessary information is available for diagnosis, the commands listed will include the debug option.

Known Issues

If your source database is running 12c or higher, un-comment the usermantransport parameter in the xtt.properties. This parameter should ONLY be used for an 12c and higher source.
i.e.,:
usermantransport=1 <== remove the '#'

Regardless of the destination version, the value of this parameter in the destination's xtt.properties must be the SAME as the source.
If using ASM in both source and destination, see XTTS Creates Alias on Destination when Source and Destination use ASM (Note 2351123.1)
If using ASM for datafiles, an error deleting file system file using ASMCMD can be ignored. (unpublished Bug 29268792, currently open)
The existence of a GLOGIN.sql, in either source or destination, can cause syntax errors.
For other known issues, see other issues within Known Issues for Cross Platform Transportable Tablespaces XTTS (Note 2311677.1).
You cannot use this procedure for a TDE tablespace.
This procedure has only been tested with English language.
Be aware of open bug 30777480 which can cause an issue if the CDB's tablespace number (TS#) is the same as the tablespace id (TS#) belonging to a tablespaces being transported.
You may receive an error RMAN-20201 'datafile not found in the recovery catalog' on the datafile number.
Backup creation parallelism is defined by RMAN configuration for DEVICE TYPE DISK PARALLELISM. For incremental backups (after Level 0), parallelism is on the tablespace level.
If the target database character set is not compatible with source database character set the following error may occur at tablespace plug-in (phase 5):
ORA-39123: Data Pump transportable tablespace job aborted
ORA-19736: can not plug a tablespace into a database using a different national character set

V4 Transport Tablespaces with Reduced Downtime using Cross Platform Incremental Backup

The XTTS with Cross Platform Incremental Backups procedure is divided into the following phases:

Phase 1 - Initial Setup phase
Phase 2 - Prepare phase
Phase 3 - Roll Forward phase
Phase 4 - Final Incremental Backup
Phase 5 - Transport Phase: Import Metadata
Phase 6 - Validate the Transported Data
Phase 7 - Cleanup

Conventions Used in This Document

All command examples use bash shell syntax.
Commands prefaced by the shell prompt string [oracle@source]$ indicate commands run as the oracle user on the source system.
Commands prefaced by the shell prompt string [oracle@dest]$ indicate commands run as the oracle user on the destination system.

Phase 1 - Initial Setup

Perform the following steps to configure the environment to use Cross Platform Incremental Backups:

Step 1.1 - Install the destination database software and create the destination database

Install the desired Oracle Database software on the destination system that will run the destination database.

Identify (or create) a database on the destination system to transport the tablespace(s) into and create the schema users required for the tablespace transport. I.e., users who own the objects within the tablespaces being transported.

Per generic TTS requirement, ensure that the schema users required for the tablespace transport exist in the destination database.

Step 1.2 - Identify tablespaces to be transported

Identify the tablespace(s) in the source database that will be transported. Tablespaces TS1 and TS2 will be used in the examples in this document. As indicated above, the limitations and considerations for transportable tablespaces must still be followed.

Step 1.3 - Install xttconvert scripts on the source system

On the source system, as the oracle software owner, download and extract the supporting scripts attached as rman_xttconvert_VER4.3.zip to this document.

[oracle@source]$ pwd
/home/oracle/xtt

[oracle@source]$ unzip rman_xttconvert_VER4.3.zip
Archive: rman_xttconvert_VER4.3.zip
inflating: xtt.newproperties
inflating: xtt.properties
inflating: xttcnvrtbkupdest.sql
inflating: xttdbopen.sql
inflating: xttdriver.pl
inflating: xttprep.tmpl
extracting: xttstartupnomount.sql

Step 1.4 - Create necessary directories

On source:
- Location of backups as defined by src_scratch_location parameter in the xtt.properties file. NOTE: Only one location is allowed for this parameter.
On destination:
- Location of backups as defined by the dest_scratch_location parameter in the xtt.properties file.
- Location for datafiles on destination, as defined by dest_datafile_location parameter in the xtt.properties file. NOTE: Only one location is allowed for this parameter.

Step 1.5 - Configure xtt.properties on the source system

Edit the xtt.properties file on the source system with your site-specific configuration. For more information about the parameters in the xtt.properties file, refer to the Description of Parameters in Configuration File xtt.properties section in the Appendix below. For this procedure, only the following parameters are mandatory. Others are optional and/or available for use.

- tablespaces
- platformid
- src_scratch_location
- dest_scratch_location
- dest_datafile_location
- usermantransport=1 - It is recommended this be set if the source database is running 12c or higher. This causes new 12c (and higher) functionality to be used when this parameter is set.
  NOTE: regardless of the destination version, the value of this parameter in the destination's xtt.properties must be the SAME as the source.

Step 1.6 - Copy xttconvert scripts and xtt.properties to the destination system

As the oracle software owner copy all xttconvert scripts and the modified xtt.properties file to the destination system.

[oracle@source]$ scp -r /home/oracle/xtt oracle@dest:/home/oracle/xtt

Step 1.7 - Set TMPDIR environment variable

In the shell environment on both source and destination systems, set environment variable TMPDIR to the location where the supporting scripts exist. Use this shell to run the Perl script xttdriver.pl as shown in the steps below. If TMPDIR is not set, output files are created in and input files are expected to be in /tmp.

[oracle@source]$ export TMPDIR=/home/oracle/xtt

[oracle@dest]$ export TMPDIR=/home/oracle/xtt

Phase 2 - Prepare Phase

During the Prepare phase, datafiles of the tablespaces to be transported are backed up on source, backups transferred to the destination system and restored by the xttdriver.pl script.

NOTE: For large number of files, if you wish to use dbms_file_transfer you will not be able to use V4, you will have to use 11G - Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup (Note 1389592.1). It has been found to be the fastest method for transferring datafiles to destination. This method can be used by ALL Oracle version migrations wanting to use dbms_file_transfer.

Step 2.1 - Run the backup on the source system

On the source system, logged in as the oracle user with the environment (ORACLE_HOME and ORACLE_SID environment variables) pointing to the source database, run the backup as follows:
[oracle@source]$ $ORACLE_HOME/perl/bin/perl xttdriver.pl --backup --debug 3

Step 2.2 - Transfer the following files to the destination system

Backups created from source src_scratch_location to destination dest_scratch_location. NOTE: Only one location is allowed for these parameters.
The res.txt file from source $TMPDIR to destination $TMPDIR:
In the example below, scp is used to transfer the level=0 backup created by the previous step from the source system to the destination system.
[oracle@source]$ scp /src_scratch_location/* oracle@dest:/dest_scratch
[oracle@source]$ scp res.txt oracle@dest:/home/oracle/xtt

Step 2.3 - Restore the datafiles on the destination system

On the destination system, logged in as the oracle user with the environment (ORACLE_HOME and ORACLE_SID environment variables) pointing to the destination database, run the restore as follows:
[oracle@dest]$ $ORACLE_HOME/perl/bin/perl xttdriver.pl --restore --debug 3

Datafiles will be placed on the destination system in the defined dest_datafile_location. NOTE: Only one location is allowed for this parameter.

Phase 3 - Roll Forward Phase

During this phase an incremental backup is created from the source database, transferred to the destination system, converted to the destination system endian format, then applied to the converted destination datafile copies to roll them forward. This phase may be run multiple times. Each successive incremental backup should take less time than the prior incremental backup, and will bring the destination datafile copies more current with the source database. The data being transported (source) is fully accessible during this phase.

NOTE: Multiple backups can be executed against the source without applying them to the destination. The backup files and the res.txt must be copied before the '--restore' is executed at the destination.

NOTE: The script will shutdown and startup, in NOMOUNT, the destination database before the --restore.

Step 3.1 - Create an incremental backup of the tablespaces being transported on the source system

On the source system, logged in as the oracle user with the environment (ORACLE_HOME and ORACLE_SID environment variables) pointing to the source database, run the create incremental step as follows:
[oracle@source]$ $ORACLE_HOME/perl/bin/perl xttdriver.pl --backup --debug 3

This step will create an incremental backup for all tablespaces listed in xtt.properties.

Step 3.2 - Transfer incremental backups and res.txt to the destination system

Transfer the incremental backup(s) (between src_scratch_location and dest_scratch_location) and the res.txt (between the $TMPDIRs) from the source to the destination. The list of incremental backup files from current backup can be
found in the incrbackups.txt file on the source system.
[oracle@source]$ scp `cat incrbackups.txt` oracle@dest:/dest_scratch_location
[oracle@source]$ scp res.txt oracle@dest:/home/oracle/xtt

If the src_scratch_location on the source system and the dest_scratch_location on the destination system refer to the same NFS storage location, then the backups do not need to be copied as they are available in the expected location on the destination system.

However, the res.txt file MUST be copied after the LAST incremental backup before it can be applied on destination (step 3.3).

Step 3.3 - Apply the incremental backup to the datafile copies on the destination system

On the destination system, logged in as the oracle user with the environment (ORACLE_HOME and ORACLE_SID environment variables) pointing to the destination database, run the roll forward datafiles step as follows:
[oracle@dest]$ $ORACLE_HOME/perl/bin/perl xttdriver.pl --restore --debug 3
The roll forward step connects to destination database and applies the incremental backups on the tablespaces' datafiles for each tablespace being transported.

NOTE: Although multiple backups can be executed against the source without being applied on the destination, the res.txt must be copied after the last backup and before the '--restore' is executed at the destination.

Step 3.4 - Repeat the roll forward phase 3 (3.1 - 3.3) or proceed to phase 4, final incremental backup

At this point there are two choices:
If you need to bring the files at the destination database closer in sync with the production system, then repeat the Roll Forward phase, starting with step 3.1.
If the files at the destination database are as close as desired to the source database, then proceed to the Transport phase.

Phase 4 - Final Incremental Backup

During this phase the source data is made READ ONLY and the destination datafiles are made consistent with the source database by creating and applying a final incremental backup. After the destination datafiles are made consistent, the normal transportable tablespace steps are performed to export object metadata from the source database and import it into the destination database. The data being transported is accessible only in READ ONLY mode until the end of this phase.

There are two options for this phase if you are running 12c and higher. If you are running 11g, only option #1 is available.

OPTION #1 Take the final backup

Option1.A: Alter source tablespace(s) to READ ONLY in the source database

On the source system, logged in as the oracle user with the environment (ORACLE_HOME and ORACLE_SID environment variables) pointing to the source database, alter the tablespaces being transported to READ ONLY.

system@source/prod SQL> alter tablespace TS1 read only;

Tablespace altered.

system@source/prod SQL> alter tablespace TS2 read only;

Tablespace altered.

Option1.B: Create the final incremental backup of the tablespaces being transported on the source system

On the source system, logged in as the oracle user with the environment (ORACLE_HOME and ORACLE_SID environment variables) pointing to the source database, run the backup as follows:

[oracle@source]$ $ORACLE_HOME/perl/bin/perl xttdriver.pl --backup --debug 3

NOTE: As the tablespaces are in READ ONLY mode, the following warning received can be ignored:

####################################################################
Warning:
------
Warnings found in executing /home/oracle/convert_source/backup_Nov9_Fri_09_08_26_213//xttpreparenextiter.sql
####################################################################
Prepare newscn for Tablespaces: 'SECOND'
DECLARE*
ERROR at line 1:
ORA-20001: TABLESPACE(S) IS READONLY OR,
OFFLINE JUST CONVERT, COPY
ORA-06512: at line 284

NOTE: This error should NOT be ignored if the tablespaces are in READ ONLY at the first (LEVEL=0) backup, see prerequisites.

Option1.C: Transfer incremental backups and res.txt to the destination system

[oracle@source]$ scp 'cat incrbackups.txt' oracle@dest:/dest_scratch_location
[oracle@source]$ scp res.txt oracle@dest:/home/oracle/xtt

Option1.D: Apply last incremental backup to destination datafiles

The final incremental backup must be applied to the destination datafiles:

[oracle@dest]$ $ORACLE_HOME/perl/bin/perl xttdriver.pl --restore --debug 3

This step will apply the last incremental backup to the datafiles on the destination.

OPTION #2. Take last incremental backup with new 12c feature, which also runs the export

This option is only available with 12c and higher. The only difference with this option is that the XTTs command, --bkpexport, will take BOTH the last incremental backup AND export the meta data.

Option2.A: Alter source tablespace(s) READ ONLY in the source database

On the source system, logged in as the oracle user with the environment (ORACLE_HOME and ORACLE_SID environment variables) pointing to the source database, alter the tablespaces being transported to READ ONLY.

system@source/prod SQL> alter tablespace TS1 read only;
Tablespace altered.
system@source/prod SQL> alter tablespace TS2 read only;
Tablespace altered.

Option2.B: Create the final incremental backup and export file for transfer to the destination

The final incremental backup is created with the "--bkpexport" option, then transferred to the destination.

[oracle@source]$ $ORACLE_HOME/perl/bin/perl xttdriver.pl --bkpexport
[oracle@source]$ scp `cat incrbackups.txt` oracle@dest:/stageondest
[oracle@source]$ scp xttplan.txt oracle@dest:/home/oracle/xtt
[oracle@source]$ scp tsbkupmap.txt oracle@dest:/home/oracle/xtt
[oracle@source]$ scp incrbackups.txt oracle@dest:/home/oracle/xtt

Option2.C: Apply last incremental backup to destination datafiles

The final incremental backup must be applied to the destination datafiles using "--resincrdmp"

[oracle@dest]$ $ORACLE_HOME/perl/bin/perl xttdriver.pl --resincrdmp

This step will apply the last incremental backup to the datafiles. In addition, it will restore the export dump file from the backupset and generate a script file, xttplugin.txt. This script can be used in phase 5 Option 2 below.

At this point, the restored export file can be used in Phase 5 step option1.C (skip step option1.A)
OR
the xttplugin.txt can be used for Phase 5 Option #2 (skip step option2.B).

Phase 5 - Transport Phase: Export Metadata and Plug-in Tablespaces into Destination Database

NOTE: Be sure the destination database has the necessary objects to allow the import to succeed. This includes pre-creating the owners of the tables in the tablespace being plugged in. See information on Transportable Tablespace and the guidance provided in the MAA paper Platform Migration Using Transportable Tablespaces: Oracle Database 11g.

Alternatively, if using 12c and higher, see Oracle Database 12c: Full Transportable Export/Import

During this phase, you need an export of the metadata of the tablespaces from the source and plug in the tablespace(s) into the destination.

There are two options, run metadata export and plug in the tablespaces using this file OR run the import command across sqlnet"

OPTION #1. Run metadata export and import using export file

Option1.A: Run datapump export on source database

Perform the tablespace transport by running transportable mode Data Pump export on the source database to export the object metadata being transported into a dump file. The below example assumes a directory (DATA_PUMP_DIR) already exists in the source. For example:

[oracle@source]$ cat exp.par

dumpfile=xttdump.dmp
directory=DATA_PUMP_DIR
exclude=TABLE_STATISTICS,INDEX_STATISTICS
transport_tablespaces=TS1,TS2
transport_full_check=yes
logfile=tts_export.log

[oracle@source]$ expdp system/manager parfile=exp.par

NOTE: Be aware of:
EXCLUDE=STATISTICS Or EXCLUDE=INDEX_STATISTICS During Datapump Import Still Analyzes The Indexes (Doc ID 793585.1)

Refer to the following manuals for details:

Oracle Database Administrator's Guide
Oracle Database Utilities

Option1.B: Transfer the export file to destination directory used by datapump

Option1.C: Run datapump import using the export file on destination to plug in the tablespaces. For example:

[oracle@dest]$ cat manual_imp.par
dumpfile= xttdump.dmp
directory=DATAPUMP
transport_datafiles='/dest_datafile_location/TS1.dbf','/dest_datafile_location/TS2.dbf'
logfile=tts_import.log

[oracle@dest]$ impdp system/oracle parfile=manual_imp.par

OPTION #2. Run import across sqlnet

Option2.A: Create datapump directory and grant privilege

Datapump will look for the export file in the specified directory. Either copy the '.dmp' file in your existing data pump directory or create a new directory pointing to the or copy the '.dmp' in an existing datapump directory

SYS@DESTDB> create directory dpump_tts as '/home/oracle/destination/convert';

The directory must be granted to use who will do the import:

SYS@DESTDB> GRANT READ, WRITE ON DIRECTORY dpump_tts TO system;

Option2.B: Generate new xttplugin.txt for network import

On the destination system, logged in as the oracle user with the environment (ORACLE_HOME and ORACLE_SID environment variables) pointing to the destination database, run the generate Data Pump TTS command step as follows:

[oracle@dest]$ $ORACLE_HOME/perl/bin/perl xttdriver.pl -e

This will generate a sample Data Pump network_link transportable import command in the file xttplugin.txt with the transportable tablespaces parameters TRANSPORT_TABLESPACES and TRANSPORT_DATAFILES correctly set. In addition, a datapump export file will also be created.

NOTE: This command will overwrite the previous xttplugin.txt which is needed by Step5A.

Option2.C: Create a database link on destination database

Connecting to the destination database, create a database link connecting to the source database. For example:

SQL@dest> create public database link ttslink connect to system identified by <password> using '<tns_to_source>';

Verify the database link can properly access the source system:

SQL@dest> select name from v$database@ttslink;

Option2.D: Modify and execute Impdp command

A separate export or dump file is not required. To perform the tablespace transport with this command, then you must edit the import command file xttplugin.txt (generated in step 5B.1) and replace import parameters DIRECTORY, LOGFILE, and NETWORK_LINK with site-specific values.

The following is an example network mode transportable import command:

[oracle@dest]$ impdp directory=DATA_PUMP_DIR logfile=tts_imp.log network_link=ttslink \
transport_full_check=yes \
transport_tablespaces=TS1,TS2 \
transport_datafiles='+DATA/prod/datafile/ts1.285.771686721', \
'+DATA/prod/datafile/ts2.286.771686723', \
'+DATA/prod/datafile/ts2.287.771686743'

NOTE: Per generic TTS requirement, database users that own objects being transported must exist in the destination database before performing the transportable import.

Resources:

Phase 6 - Validate the Transported Data

Step 6.1 Check destination database for objects, pl/sql objects, sequences, views etc., are not transported by TTS

Only those database objects that are physically located in the tablespace(s) being transported will be copied to the destination system. Other objects, such as users, pl/sql objects, sequences, views etc., located in the SYSTEM tablespace will not be transported. You will need to pre-create the users and copy such objects to the destination system, possibly using data pump. See:

MAA paper Platform Migration Using Transportable Tablespaces: Oracle Database.

Step 6.2 Check tablespaces for corruption

At this step, the transported data is READ ONLY in the destination database. Perform application specific validation to verify the transported data.

Also, run RMAN to check for physical and logical block corruption by running VALIDATE TABLESPACE as follows:

RMAN> validate tablespace TS1, TS2 check logical;

Step 6.3 - Alter the tablespace(s) READ WRITE in the destination database

The final step is to make the destination tablespace(s) READ WRITE in the destination database.
system@dest/prod SQL> alter tablespace TS1 read write;

Tablespace altered.

system@dest/prod SQL> alter tablespace TS2 read write;

Tablespace altered.

Phase 7 - Cleanup

If a separate incremental convert home and instance were created for the migration, then the instance may be shutdown and the software removed.

Files created by this process are no longer required and may now be removed. They include the following:

src_scratch_location location on the source system
dest_scratch_location location on the destination system
$TMPDIR location in both source and destination systems

Appendix

Description of Perl Script xttdriver.pl Options

The following table describes the options available for the main supporting script xttdriver.pl.

Option	Description
--backup	Creates a level 0 or level 1 backup of the datafiles belonging to the selected tablespaces. These backups will be written into the location pointed to by the xtt.properties variable “src_scratch_location”. These backups need to be copied over to the destination to the location pointed to by the variable “dest_scratch_location”.
--restore	Restores and converts the datafiles from the backups copied to the location “dest_scratch_location” in destination. The restored files will be placed in the path defined by the variable “dest_datafile_location”.
-e	Generates Data Pump TTS command step which can be executed on the destination system. This command is executed on the source and the command file created can be transfered to the destination for execution. This step creates the template of a Data Pump Import command that uses a network_link to import metadata of objects that are in the tablespaces being transported. It should be executed on the source and the resulting file transferred to the destination.
--debug	Enables debug mode for xttdriver.pl and RMAN commands it executes. Debug mode can also be enabled by setting environment variable XTTDEBUG=1. Debug allows for 1,2,3 levels of debug. I.e., xttdriver.pl -debug 3

Description of Parameters in Configuration File xtt.properties

The following table describes the parameters used by xttdriver.pl which must be defined in the xtt.properties file that are needed for this 12c or higher procedure. Other parameters may exist which are needed for backward compatibility.

Parameter	Description	Example Setting
tablespaces	Comma-separated list of tablespaces to transport from source database to destination database. Must be a single line, any subsequent lines will not be read.	tablespaces=TS1,TS2
platformid	Source database platform id, obtained from V$DATABASE.PLATFORM_ID.	platformid=13
dest_datafile_location	Directory object in the destination database that defines where the destination datafiles will be created. NOTE: Only one location is allowed for this parameter.	dest_datafile_location=/u01/oradata/V122 i.e.: dest_datafile_location=+DATA
src_scratch_location	Location on the source system where backups are created. This location must have sufficient free space to hold the level=0 backup of the tablespace datafiles and all subsequent incremental backups created for one iteration through the process documented above. This location may be an NFS-mounted filesystem that is shared with the destination system, in which case it should reference the same NFS location as the dest_scratch_location parameter for the destination system. NOTE: Only one location is allowed for this parameter.	src_scratch_location=/stage_source
dest_scratch_location	Location on the destination system where backups are placed by the user when they are transferred manually from the source system. This location must have sufficient free space to hold level=0 backup and all subsequent incremental backups transferred from the source. This location may be a DBFS-mounted filesystem. This location may be an NFS-mounted filesystem that is shared with the source system, in which case it should reference the same NFS location as the src_scratch_location parameters for the source system. See Note 359515.1 for mount option guidelines. NOTE: Only one location is allowed for this parameter.	dest_scratch_location=/stage_dest
asm_home	ORACLE_HOME for the ASM instance that runs on the destination system.	asm_home=/u01/app/ 12.2.0.1 /grid
asm_sid	ORACLE_SID for the ASM instance that runs on the destination system.	asm_sid=+ASM1
parallel	Defines the degree of parallelism used in copying (prepare phase), converting. Incremental backup creation parallelism is defined by RMAN configuration for DEVICE TYPE DISK PARALLELISM.	parallel=3
srcconnstr	In CDB environment, specifies connect string of the source pluggable database.	srcconnstr=sys/passwd@sourc_cdb_PDB1
destconnstr	In CDB environment, specifies connect string of the destination pluggable database.	destconnstr=sys/passwd@dest_cdb_PDB1
usermantransport	It is recommended this be set if the source database is running 12c or higher. This causes new 12c (and higher) functionality to be used. Note, this must be set to the SAME value between source and destination. So if source is running 11g, this parameter should NOT be set on the destination, regardless of the destination version. Again, usermantransport is set (or remains commented out) in BOTH the source and destination xtt.properties. It should never be different between the source and destination.	usermantransport=1

Change History

Change	Date
rman_xttconvert_VER4.zip released	29-Nov-2018
rman_xttconvert_VER4.3.zip released	05-Mar-2021

References

BUG:18596700 - CHANGE TRACKING IS NOT USED DURING INCREMENTAL BACKUP FOR READ ONLY TBS
NOTE:25890056.8 - Bug 25890056 - Fix for Bug 25670970 on 12.2 - ORA-600 [25027] on Securefile Lob Segment after XTTS

NOTE:2853054.1 - Using XTTs in a Data Guard Environment

NOTE:2311677.1 - Known Issues for Cross Platform Transportable Tablespaces XTTS
NOTE:25670970.8 - Bug 25670970 - ORA-600 [25027] or ORA-600 [kcfrbd_3] on Securefile Lob Segment after XTTS
NOTE:2689397.1 - V4 XTTs: Restore Returns Errors (ORA-19625 or ORA-19641) With Large Number of Datafiles

NOTE:2888288.1 - ALERT: Possible Block Corruption After Migrating From Solaris to Linux Exadata using HCC
NOTE:2013271.1 - 12c How Perform Cross-Platform Database Transport to different Endian Platform with RMAN Backup Sets
NOTE:2460552.1 - Cross Platform Database Migration using ZDLRA
NOTE:35022351.8 - Bug 35022351 - ORA-600: [kdbblkcheckerror], Block Checking error code [6101] / [6108] against HCC tables with ROW LEVEL LOCKING enabled

BUG:28309542 - LFI-00005 LFI-01007 XTTDRIVER.PL --RESTORE

NOTE:2999157.1 - M5 Cross Endian Platform Migration using Full Transportable Data Pump Export/Import and RMAN Incremental Backups
BUG:29268792 - V4 XTTS WILL ATTEMPT TO DELETE FILE SYSTEM FILE WITH ASMCMD
NOTE:793585.1 - EXCLUDE=STATISTICS Or EXCLUDE=INDEX_STATISTICS During Datapump Import Still Analyzes The Indexes

Wednesday, August 21, 2024

V4 Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup (Doc ID 2471245.1)