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

Last updated on JUNE 13, 2023

Applies to:

Oracle Database Cloud Schema Service - Version N/A and later
Oracle Database Backup Service - Version N/A and later
Oracle Database Cloud Service - Version N/A and later
Oracle Database - Enterprise Edition - Version 10.2.0.3 and later
Oracle Database Exadata Express Cloud Service - Version N/A and later
Linux x86-64

Purpose

This note describes an older version of this procedure, V3. It should NOT be used unless absolutely necessary.

To use XTTs, use:
V4 Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup (Doc ID 2471245.1)

The rest of the details in this article are relating to XTTs V3 only.

When using Cross Platform Transportable Tablespaces (XTTS) to migrate data between systems that have different endian formats, the amount of downtime required can be substantial because it is directly proportional to the size of the data set being moved. However, combining XTTS with Cross Platform Incremental Backup can significantly reduce the amount of downtime required to move data between platforms.

Traditional Cross Platform Transportable Tablespaces

The high-level steps in a typical XTTS scenario are the following:

Make tablespaces in source database READ ONLY
Transfer datafiles to destination system
Convert datafiles to destination system endian format
Export metadata of objects in the tablespaces from source database using Data Pump
Import metadata of objects in the tablespaces into destination database using Data Pump
Make tablespaces in destination database READ WRITE

Because the data transported must be made read only at the very start of the procedure, the application that owns the data is effectively unavailable to users for the entire duration of the procedure. Due to the serial nature of the steps, the downtime required for this procedure is proportional to the amount of data. If data size is large, datafile transfer and convert times can be long, thus downtime can be long.

Reduce Downtime using Cross Platform Incremental Backup

To reduce the amount of downtime required for XTTS, Oracle has enhanced RMAN's ability to roll forward datafile copies using incremental backups, to work in a cross-platform scenario. By using a series of incremental backups, each smaller than the last, the data at the destination system can be brought almost current with the source system, before any downtime is required. The downtime required for datafile transfer and convert when combining XTTS with Cross Platform Incremental Backup is now proportional to the rate of data block changes in the source system.

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 since migration time is typically dominated by metadata operations, not datafile transfer and conversion.

Only those database objects that are physically located in the tablespaces that are being transported will be copied to the destination system. If you need for other objects to be transported, that are located in different tablespaces (such as, for example, pl/sql objects, sequences, etc., that are located in the SYSTEM tablespace), you can use data pump to copy those objects to the destination system.

The high-level steps using the cross platform incremental backup capability are the following:

1. Prepare phase (source data remains online)

Transfer datafiles to destination system
Convert datafiles, if necessary, to destination system endian format

2. 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 to destination system
Convert incremental backup to destination system endian format and apply the backup to the destination datafile copies

NOTE: In Version 3, if a datafile is added to the tablespace OR a new tablespace name is added to the xtt.properties file, a warning and additional instructions will be required.

3. Transport phase (source data is READ ONLY)

Make tablespaces in source database READ ONLY
Repeat the Roll Forward phase one final time

This step makes destination datafile copies consistent with source database.
Time for this step is significantly shorter than traditional XTTS method when dealing with large data because the incremental backup size is smaller.

Export metadata of objects in the tablespaces from source database using Data Pump
Import metadata of objects in the tablespaces into destination database using Data Pump
Make tablespaces in destination database READ WRITE

The purpose of this document is to provide an example of how to use this enhanced RMAN cross platform incremental backup capability to reduce downtime when transporting tablespaces across platforms.

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.