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

Traditional Cross Platform Transportable Tablespaces

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

1. Make tablespaces in source database READ ONLY
2. Transfer datafiles to destination system
3. Convert datafiles to destination system endian format
4. Export metadata of objects in the tablespaces from source database using Data Pump
5. Import metadata of objects in the tablespaces into destination database using Data Pump
6. 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 high-level steps using the cross platform incremental backup capability are the following:

• Prepare phase (source data remains online)

1. Transfer datafiles to destination system
2. Convert datafiles, if necessary, to destination system endian format

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

1. Create incremental backup on source system
2. Transfer incremental backup to destination system
3. Convert incremental backup to destination system endian format and apply the backup to the destination datafile copies

• Transport phase (source data is READ ONLY)

1. Make tablespaces in source database READ ONLY
2. Repeat the Roll Forward phase one final time
3. 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.

1. Export metadata of objects in the tablespaces from source database using Data Pump
2. Import metadata of objects in the tablespaces into destination database using Data Pump
3. 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.

Oracle Architecture

An Oracle database server consists of an oracle database and one or more database instances.

Oracle instance consists of memory structures and background processes. Every time when the instance started, shared memory area called the system global area(SGA) is allocated and background processes are started.

The database consists of both physical structures and logical structures. Because the physical and logical structures are separate, the physical storage of data can be managed without affecting access

to logical storage structures.