Transportable Tablespaces with Cross-Platform Incremental Backup

This method uses transportable tablespaces in conjunction with cross-platform incremental backup. By using this combination, the downtime required for the migration can be reduced significantly; however, this comes at the cost of using more administration and processing resources overall. It also provides the benefits associated with transportable tablespaces; namely, broad cross-platform migration support, limited support for source and destination databases with different character sets, and the ability to migrate data to a later version of Oracle Database.

A migration using transportable tablespaces in conjunction with cross-platform incremental backup in accomplished in three phases:

1. Preparation.

   1. Use RMAN to backup your source tablespaces.

   2. Transfer the backups to an Exadata Cloud at Customer compute node.

   3. On the Exadata Cloud at Customer compute node, load the tablespace data files into ASM and Exadata Storage Server. If required, perform an endian format conversion at this stage.

      You can load and convert the data files by using the RMAN CONVERT command, or the PUT_FILE procedure in the DBMS_FILE_TRANSFER package.

2. Roll forward.

   1. Use RMAN to create an incremental backup on the source system.

   2. Transfer the incremental backup to an Exadata Cloud at Customer compute node.

   3. On the Exadata Cloud at Customer compute node, use RMAN to convert the incremental backup to the target system endian format and apply it to the target data files.

   Repeat the roll forward tasks until the target database is almost up to date with the source database.

   This method relies on the notion that the incremental backups can be taken, transported and applied quicker than the time period covered by each backup. If this is true, each backup will get successively smaller and the target system will catch up with the source system. If the incremental backups take too long to generate and apply, the target system will never catch up and this method cannot be used.

3. Final roll forward and metadata transport.

   1. On the source database, place the source tablespaces into read-only mode.

   2. On the source database host, use RMAN to create the final incremental backup.

   3. On the source database host, execute Data Pump Export to unload the metadata associated with the tablespace set.

   4. Transfer the final incremental backup and the Data Pump dump file to an Exadata Cloud at Customer compute node.

   5. On the Exadata Cloud at Customer compute node, use RMAN to convert the final incremental backup to the target system endian format and apply it to the target data files.

   6. On the Exadata Cloud at Customer compute node, use Data Pump Import to load the metadata associated with the tablespace set.

   7. Set the tablespaces on the Exadata Cloud at Customer database to read-write mode.

By using this method, no downtime is incurred in the preparation and roll forward phases, which is where most of the data transportation occurs. Downtime is only incurred in the final roll forward and metadata transport phase. Consequently, the required downtime depends on the rate of change and the amount of metadata in the source database, rather than its overall size. Therefore, using transportable tablespaces in conjunction with cross-platform incremental backup is a good candidate for situations where data file transfer and conversion would otherwise require unacceptably long downtime.

Note that cross-platform incremental backup does not affect the amount of time it takes to perform metadata export and import. So databases that have very large amounts of metadata will see limited benefit if the migration time is dominated by metadata operations, not data file transfer and conversion.

For information about this approach, including specific requirements and limitations, see Reduce Transportable Tablespace Downtime using Cross-Platform Incremental Backup for Oracle Database 11g and 12c.