XTTS (Cross-Platform Transportable Tablespaces) is used to migrate large Oracle databases between different platforms while minimizing downtime.
It combines three technologies:

• Transportable Tablespaces
• RMAN Incremental Backups
• Data Pump Metadata Export/Import

The idea is:

• Move most of the data while the database is running
• Synchronize changes using incremental backups
• Perform a small final cutover

Below is the full operational procedure used in real migrations.

---

Step 1 — Verify Platform Compatibility

Identify the source and target platform endian format.

SELECT platform_name, endian_format
FROM v$transportable_platform
ORDER BY platform_name;

Confirm the target platform name, which will be required during RMAN conversion.

Example:

Platform	Endian
Linux x86 64-bit	Little
Solaris	Big

---

Step 2 — Identify Tablespaces to Transport

Select the application tablespaces that must be migrated.

SELECT tablespace_name
FROM dba_tablespaces
WHERE contents='PERMANENT';

Exclude these system tablespaces:

• SYSTEM
• SYSAUX
• UNDO
• TEMP

---

Step 3 — Verify Transportable Set

Ensure the selected tablespaces are self-contained.

EXEC DBMS_TTS.TRANSPORT_SET_CHECK('SALES_TS,HR_TS', TRUE);

Check violations:

SELECT * FROM transport_set_violations;

No rows must be returned.

---

Step 4 — Capture Baseline SCN

Record the database SCN which will be used for incremental backups.

SELECT current_scn FROM v$database;

Example:

BASELINE SCN = 123456789

This SCN represents the starting point for change tracking.

---

Step 5 — Convert Tablespaces for Target Platform

Run RMAN conversion to create datafiles compatible with the target platform.

rman target /

CONVERT TABLESPACE sales_ts, hr_ts
TO PLATFORM 'Linux x86 64-bit'
FORMAT '/xtts_stage/%U';

This creates converted datafiles.

Example output:

/xtts_stage/datafile01.dbf
/xtts_stage/datafile02.dbf

---

Step 6 — Transfer Converted Datafiles to Target

Copy the converted files to the target system.

Example:

scp /xtts_stage/*.dbf target_server:/u02/oradata/

This represents the initial full data transfer.

During this time the source database remains online.

---

Step 7 — Take First Incremental Backup

Capture blocks changed after the baseline SCN.

RMAN> BACKUP INCREMENTAL FROM SCN 123456789
TABLESPACE sales_ts, hr_ts
FORMAT '/xtts_stage/incr_%U';

This backup contains only changed blocks.

---

Step 8 — Transfer Incremental Backup to Target

Copy incremental backup files.

Example:

scp /xtts_stage/incr_* target_server:/xtts_stage/

---

Step 9 — Apply Incremental Backup on Target

Start RMAN on the target database.

rman target /

Catalog the incremental backup pieces that were copied from the source server so RMAN becomes aware of them.

CATALOG START WITH '/xtts_stage/';

Apply the incremental changes to the transported tablespace datafiles.

RECOVER TABLESPACE sales_ts, hr_ts;

RMAN reads the cataloged backup pieces and applies the changed blocks to synchronize the target datafiles with the source database.

---

Step 10 — Repeat Incremental Synchronization

Repeat Steps:

• Incremental backup
• Transfer backup
• Apply backup

Each cycle captures only changed blocks since the last SCN.

Example cycle timeline:

Cycle	Action
Cycle 1	Initial incremental backup
Cycle 2	Next incremental backup
Cycle 3	Next incremental backup

After several cycles the target becomes almost fully synchronized.

---

Step 11 — Prepare for Final Cutover

Stop application activity on the source database.

Set tablespaces to read-only.

ALTER TABLESPACE sales_ts READ ONLY;
ALTER TABLESPACE hr_ts READ ONLY;

---

Step 12 — Take Final Incremental Backup

Capture last changes.

BACKUP INCREMENTAL FROM SCN <last_scn>
TABLESPACE sales_ts, hr_ts
FORMAT '/xtts_stage/final_%U';

Transfer backup to the target.

---

Step 13 — Apply Final Incremental Backup

On the target system:

RECOVER TABLESPACE sales_ts, hr_ts
FROM BACKUPSET;

Now the transported tablespaces are fully synchronized.

---

Step 14 — Export Metadata

Export tablespace metadata from source database.

expdp system/password \
TRANSPORT_TABLESPACES=sales_ts,hr_ts \
DIRECTORY=DATA_PUMP_DIR \
DUMPFILE=tts_meta.dmp

Transfer the dump file to the target.

---

Step 15 — Import Metadata on Target

Attach transported datafiles to the target database.

impdp system/password \
DIRECTORY=DATA_PUMP_DIR \
DUMPFILE=tts_meta.dmp \
TRANSPORT_DATAFILES='/u02/oradata/datafile01.dbf',
'/u02/oradata/datafile02.dbf'

---

Step 16 — Make Tablespaces Read Write

ALTER TABLESPACE sales_ts READ WRITE;
ALTER TABLESPACE hr_ts READ WRITE;

---

Step 17 — Validate Migration

Verify tablespaces.

SELECT tablespace_name, status
FROM dba_tablespaces;

Check invalid objects.

SELECT owner, object_name
FROM dba_objects
WHERE status='INVALID';

Compile if needed.

@?/rdbms/admin/utlrp.sql

---

XTTS Migration Timeline Example

Phase	Time
Initial copy	12 hours
Incremental sync cycles	Several days
Final cutover	20 minutes

---

Why XTTS Reduces Downtime

Without XTTS:

Copy entire database during downtime

With XTTS:

Initial copy while database is online
Incremental sync of changes
Final small synchronization

Only the final incremental changes require downtime.

---

When Step 3 (Verify Transportable Set) Failed

Scenario	Example Violation	Why It Happens
Index in another tablespace	Index HR.EMP_IDX in INDEX_TS points to table HR.EMP in SALES_TS	Table is inside transport set but index is stored in a different tablespace
Fix (Steps) Step 1: Identify the index tablespace. Step 2: Move the index: ALTER INDEX hr.emp_idx REBUILD TABLESPACE sales_ts; Step 3: Run transport check again.
LOB segment in another tablespace	LOB segment HR.DOC_LOB in LOB_TS while table HR.DOC_TABLE is in SALES_TS	Table resides in transport set but LOB segment exists in another tablespace
Fix (Steps) Step 1: Identify the LOB column. Step 2: Move the LOB segment: ALTER TABLE hr.doc_table MOVE LOB(doc_column) STORE AS (TABLESPACE sales_ts); Step 3: Run transport check again.
Partitioned table across tablespaces	Partition SALES_Q1 in SALES_TS and SALES_Q2 in DATA_TS	Different partitions of the same table exist in different tablespaces
Fix (Steps) Step 1: Identify partitions outside transport set. Step 2: Move partition: ALTER TABLE sales MOVE PARTITION sales_q2 TABLESPACE sales_ts; Step 3: Run transport check again.
Foreign key dependency	Foreign key between SALES_TS table and USERS_TS table	Table inside transport set references table outside transport set
Fix (Steps) Option 1: Include USERS_TS in transport set. Option 2: Disable constraint: ALTER TABLE sales DISABLE CONSTRAINT fk_customer;