V4 Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup
(Doc ID 2471245.1)
Last updated on OCTOBER 21, 2024
Applies to:
Oracle Cloud Infrastructure - Database Service - Version N/A and later Oracle Database Cloud Schema Service - Version N/A and later Oracle Database Cloud Exadata Service - Version N/A and later Oracle Database Backup Service - Version N/A and later Gen 1 Exadata Cloud at Customer (Oracle Exadata Database Cloud Machine) - Version N/A and later Linux x86-64
Updated 09-Nov-2018 -- Version 4
Updated 07-Jul-2022 - incorporated 12.2 last incremental backup functionality.
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. Earlier 11.2 versions will likely function the same, however were not tested. As suggested, test the procedure before relying on it for a production environment.
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:
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 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)
Alter the tablespaces in the source database to READ ONLY
Repeat the Roll Forward phase one final time
This step makes destination datafile copies consistent with source database and generates necessary export.
Time for this step is significantly shorter than traditional XTTS method when dealing with large data because the incremental backup size is smaller.
Import metadata of objects in the tablespaces into destination database using Data Pump
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
To view full details, sign in with your My Oracle Support account.
Don't have a My Oracle Support account? Click to get started!
