Jeff Stonacek, Principal Architect

Overview

We are all aware of the issue surrounding cross platform database migrations.  The endian difference between RISC Unix platforms (big endian) versus x86 platforms (little endian) causes a conversion of the data before it is usable by Oracle.  There are three methodologies possible when converting the endian-ness of a database.

• Traditional export using exp/imp or Data Pump
• Cross platform transportable tablespaces (XTTS)
• Logical replication with Streams or Golden Gate

Each method has its roadblocks.  Exporting the data is fairly simple, but requires a lot of downtime for large databases.  XTTS too requires a lot of downtime for large databases, although usually less than exporting and importing.  Logical replication offers less downtime, but Golden Gate is a separately licensed product that comes with a hefty price tag.

As of 11.2.0.4 there is an additional method, which is based on traditional XTTS.  This is XTTS along with cross platform incremental backups.

Traditional XTTS

The steps involved with traditional XTTS are as follows:

• Make the source datafiles read only (downtime begins)
• Transfer datafiles to the destination
• Convert datafiles to new endian format
• Export metadata from the source
• Import metadata on the destination
• Make tablespaces on destination read/write

The problem is that the source datafiles must be made read only before the copy to the target system.  This copy can take a very long time for a large, multi-terabyte database.

XTTS with Cross Platform Incremental Backup

The main difference with this procedure is that the initial copy of the datafiles occurs while the source database remains online.  Then, incremental backups are taken of the source database, transferred to the destination, converted to the new endian-ness, and applied to the destination.  Here are the steps.

• Transfer source datafiles to the destination (source database remains online)
• Convert datafiles to new endian format
• Create an incremental backup of the source tablespaces
• Transfer the incremental backup to the destination
• Convert the incremental backup to new endian format
• Apply the incremental backup to the destination database
• Repeat the incremental backup steps as needed
• Place the source database into read only mode
• Repeat the incremental backup steps
• Export metadata from the source
• Import metadata on the destination
• Make tablespaces on destination read/write

Cross Platform Incremental Caveat
The one caveat to this process is that the functionality of converting an incremental backup is new in 11.2.0.4.  This means that an 11.2.0.4 Oracle home must exist on the destination system to perform the conversion of the incremental backup.  That does not mean that the destination database must be 11.2.0.4.  The 11.2.0.4 home can be used for the conversion even if the destination database is a lower version.

Conclusion

In this post I described, in more detail, one of the three methodologies possible when converting the endian-ness of a database – cross platform transportable tablespaces (XTTS). Hopefully you now have a better understanding of the pros and cons of this method and whether or not it’s a good fit for your Oracle environment.