Mastering XTTS: Fast, Low‑Downtime Oracle Table‑Space Migration

What is XTTS

XTTS (Extended Table‑Space Transfer) builds on Oracle's traditional TTS (Table‑Space Transfer) by adding cross‑platform capability and incremental backup support, allowing data to be moved between databases with minimal downtime.

When to Use XTTS

XTTS is suitable for large‑scale migrations where continuous availability is required, especially when the source and target platforms differ or when incremental data needs to be captured after an initial bulk load.

Comparison of Migration Methods

Data Pump : Simple, requires the source to be read‑only, best for <5 TB data volumes; longest downtime.

GoldenGate : Near‑real‑time replication, minimal downtime, but complex to set up for large environments.

XTTS : Intermediate downtime, supports cross‑platform moves and incremental backup, balancing simplicity and speed.

XTTS Basic Procedure

The process mirrors TTS with additional steps for incremental handling:

Set source tablespace to READ ONLY.

Transfer data files to the target.

Convert file byte order if needed.

Export metadata from source and import on target.

Set target tablespace to READ WRITE.

Perform incremental backup (C) and restore (D) repeatedly.

Finalize with a last incremental backup and metadata import.

Key Parameters

XTTS relies on the DBMS_FILE_TRANSFER package. Required parameters include:

Platform ID (queried from source).

Source data‑file directory.

Target data‑file directory.

Target DB link.

Backup destination paths for full and incremental files.

Practical Example Commands

Typical workflow using the provided Perl driver: $ORACLE_HOME/perl/bin/perl xttdriver.pl -S – generates xttnewdatafiles.txt and getfile.sql. $ORACLE_HOME/perl/bin/perl xttdriver.pl -i – creates an incremental backup and produces tsbkupmap.txt, incrbackups.txt, xttplan.txt. $ORACLE_HOME/perl/bin/perl xttdriver.pl -r – restores the incremental backup on the target. $ORACLE_HOME/perl/bin/perl xttdriver.pl -s – advances the SCN to set the start point for the next incremental backup.

Performance Tips

To reduce migration time, enable Oracle BCT (Block Change Tracking) for faster incremental backups, run parallel transfers in RMAN, and split large tablespaces into multiple slices for concurrent file copy. During metadata import, skip statistics on the first pass and add them on the second pass with parallelism to speed up the process.

Pre‑Migration Checklist

Identify tablespaces to migrate and confirm required data.

Verify source character set and check for empty segments.

Validate objects for invalid status and XMLSchema‑based types.

Create necessary DB links on the target.

Ensure tablespace names are unique on the target and that no application users reside in SYSTEM, SYSAUX, or USERS.

Confirm all tablespaces are self‑contained and prepare scripts for user and temporary tablespace creation.

Conclusion

XTTS enables cross‑platform Oracle migrations with relatively short downtime, simplifying the DBA’s workload while supporting incremental data movement and offering flexibility between the simplicity of Data Pump and the near‑zero downtime of GoldenGate.

Q&A

Q1: Can archival backup be used for incremental restore?

A1: No, XTTS does not support archival backup for incremental restores.

Q2: Does enabling parallel transfer for a 20 TB migration affect production?

A2: Parallelism can be used for both initial file transfer and incremental backup; impact depends on network bandwidth and should be tested.

Q3: Will parallel transfer cause production pauses?

A3: Parallel jobs consume resources; reserve enough capacity to avoid affecting live workloads.

Q4: Could EXP export encounter ORA‑01555?

A4: With tablespaces set to READ ONLY, ORA‑01555 is unlikely.

Q5: Why does XTTS restart the target during the –l step?

A5: The –l operation brings the target to NOMOUNT state for file recovery; a separate instance can be used to avoid disrupting the production database.