Why XTTS
| Method | Downtime for 20 TB |
|---|---|
| Data Pump export/import | Many hours to days |
| XTTS with incremental roll-forward | Final incremental + metadata export/import. Often 1–4 hours |
| GoldenGate / logical replication | Minutes, but licence and complexity |
XTTS moves datafiles (converting endianness) and keeps them current with RMAN incremental backups until cut-over.
How it works
1. Full backup of the tablespaces on source (online) ──► restore + convert on Linux target
2. Incremental backups (repeat) ──► apply + convert on target
3. Cut-over: tablespaces READ ONLY, last incremental ──► apply
4. Data Pump metadata export (TTS) ──► import metadata, plug tablespaces in
5. Make tablespaces READ WRITE on target, validate, switch apps
Prerequisites
- Use Oracle's current XTTS V4 scripts from My Oracle Support (the "V4 Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup" note) and follow that note's version requirements.
- Target database created on Linux with the same (or compatible) character set, same block size(s), and the same or newer version.
- Tablespaces must be self-contained:
EXEC DBMS_TTS.TRANSPORT_SET_CHECK('APP_DATA,APP_INDEX', TRUE);
SELECT * FROM transport_set_violations;
SYSTEM,SYSAUX,UNDO,TEMPare not transported. Users, roles, grants, PL/SQL in SYSTEM, sequences and public synonyms are moved separately (Data Pump withFULLmetadata or targeted exports).- Staging space reachable by both (NFS or copy).
Configure and run (outline)
The V4 driver uses an xtt.properties file (tablespaces, source/target platform IDs, backup and restore directories, destination datafile location):
# source
$ORACLE_HOME/perl/bin/perl xttdriver.pl --backup # first run: level 0 backup of the tablespaces
# copy files to target staging; on target:
$ORACLE_HOME/perl/bin/perl xttdriver.pl --restore # restore + convert to Linux format
Repeat --backup / --restore as often as needed. Each run takes only the changes since the last one (block change tracking on the source makes this fast).
Cut-over
- Stop application, then on source:
ALTER TABLESPACE app_data READ ONLY;(all transported tablespaces). - Final
--backup/--restore. - Export metadata on source:
expdp system directory=DP_DIR dumpfile=tts_meta.dmp transport_tablespaces=APP_DATA,APP_INDEX transport_full_check=y logfile=tts_exp.log
- Create users/roles on target, then import, pointing to the converted datafiles:
impdp system directory=DP_DIR dumpfile=tts_meta.dmp \
transport_datafiles='/u02/oradata/NEW/app_data01.dbf','/u02/oradata/NEW/app_index01.dbf' logfile=tts_imp.log
- Import remaining metadata (sequences, procedures, grants, synonyms) with a Data Pump
CONTENT=METADATA_ONLYexport of the schemas excluding tables. ALTER TABLESPACE app_data READ WRITE;, gather statistics, validate and switch applications.
Full transportable export/import (FULL=Y TRANSPORTABLE=ALWAYS) can combine steps 3–5 for 12c+ sources. Check whether it fits your case.
Validation
- Object counts and invalid objects by schema, source vs target.
- Row counts on key tables (tablespaces were read-only, so counts must match exactly).
RMAN VALIDATEon the new datafiles.- Application smoke tests, batch jobs, DB links.
Warning
Rehearse the whole cut-over on a copy first. The metadata import step and missing non-transported objects (sequences, grants on SYS objects, public synonyms) cause most cut-over surprises, not the datafiles.
Checklist
- Latest XTTS V4 scripts and MOS note followed
- Self-contained tablespace check clean
- Block change tracking on source
- Incremental cycles timed; final incremental size known
- Non-transported objects scripted
- Full rehearsal with timings and rollback (source stays intact until switch)