XTTS Deep Dive: Cross-Platform Oracle Migration Without a Full Export

A manufacturing company running Oracle on Solaris SPARC (big-endian) needs to land on Linux x86-64 (little-endian) for its new OCI footprint. A straight file copy of the datafiles would corrupt every row - the byte order of multi-byte fields differs between platforms.

The rows, columns, and values in the database are logically identical on both platforms – the number 1,000 means the same thing on SPARC and on x86-64. What differs is purely the physical byte order used to store multi-byte fields on disk, which is why a naive file copy corrupts the data even though nothing about the data itself has changed. XTTS's entire job is to rewrite that physical representation during the transfer, so the logical overlap in the middle of this diagram survives the trip intact.

Figure 2 · Why a raw file copy across these platforms corrupts data

Historically this meant a full Data Pump export and import - safe, but painfully slow for multi-terabyte databases. Cross-Platform Transportable Tablespaces (XTTS) instead converts the physical datafiles themselves, incrementally, while the source stays live almost the entire time.

XTTS is Oracle's V4 scripted framework (driven by xttdriver.pl) that automates RMAN incremental backups, cross-platform conversion via DBMS_FILE_TRANSFER or RMAN CONVERT, and iterative rollforward - reducing the read-only cutover window to just the final incremental and the metadata transfer.

Because Level 1 incrementals only capture blocks changed since the last backup, the final cutover window shrinks dramatically compared to transferring the full dataset in one pass.

This number is the payoff of the incremental strategy shown above: because almost all of the data has already crossed the wire before the read-only window even opens, what's left to transfer in that final window is small. For a multi-terabyte VLDB, that difference is the difference between a migration that fits inside a Saturday-night maintenance window and one that doesn't fit inside any window your business is willing to grant.

Figure 4 · Most of the transfer happens before the read-only clock ever starts

1. Run Multiple Level 1 PassesThe more incremental rollforward cycles completed before cutover, the smaller the final read-only window.

The Level 0 backup captures the entire database while it stays fully read-write, so none of that time counts against your outage budget at all. Each Level 1 incremental pass afterward only needs to capture blocks that changed since the previous pass, which is why the amount of remaining data shrinks quickly – often by two-thirds or more per cycle. Run enough incremental passes before the scheduled cutover, and the final read-only window that actually blocks the application can shrink to a small fraction of the database's total size.

Figure 3 · Each pass narrows the remaining data until only a sliver needs a read-only window

2. Validate the Platform Compatibility Matrix FirstConfirm source and target platforms are certified for direct XTTS conversion before scripting anything.
3. Stage Conversion on the Target HostRunning datafile conversion on the target avoids doubling network transfer of already-converted files.
4. Track Tablespace Self-ContainmentTransportable tablespace sets must be self-contained - resolve cross-tablespace dependencies before the final export.