Reduce Transportable Tablespace Downtime Using Cross-Platform Incremental Backup (V4)
Reference: Oracle MOS DocID 2471245.1
Overview
The Transportable Tablespace (TTS) feature lets you move tablespaces between Oracle databases — including across different operating systems and platforms (e.g., Solaris → Linux, HP-UX → RHEL).
The traditional TTS approach requires the tablespace to be in READ ONLY mode for the entire duration of the copy — which can mean hours or days of downtime for large tablespaces.
The V4 cross-platform incremental backup method reduces this downtime to minutes:
Traditional TTS: READ ONLY → full copy (days) → import
V4 method: READ WRITE → full copy → incrementals → READ ONLY (minutes) → final incremental → import
Prerequisites
- Oracle 12.1.0.2+ on source and target
- Source and target DB block size must match
- Both platforms must be in Oracle's supported cross-platform list
- Target platform must be confirmed with:
SELECT * FROM v$transportable_platform ORDER BY platform_name; - RMAN must have access to both source and target (or shared staging area)
-- Check compatible cross-platform targets
SELECT platform_name, endian_format
FROM v$transportable_platform
ORDER BY platform_name;
-- Check source platform endian
SELECT platform_name, endian_format
FROM v$database d
JOIN v$transportable_platform tp ON d.platform_id = tp.platform_id;Phase 1 — Initial Full Cross-Platform Backup (Source READ WRITE)
The tablespace stays open for writes during this phase — no downtime yet.
-- On SOURCE: create a cross-platform backup of the tablespace(s)
-- The tablespace remains READ WRITE during this step
BACKUP
FOR TRANSPORT
ALLOW INCONSISTENT
TABLESPACE sales_data, sales_idx
FORMAT '/oracle/staging/xtt/full_%U'
DATAPUMP FORMAT '/oracle/staging/xtt/meta_%U';Transfer the initial backup files to the target staging area:
scp /oracle/staging/xtt/full_* oracle@target-server:/oracle/staging/xtt/
scp /oracle/staging/xtt/meta_* oracle@target-server:/oracle/staging/xtt/Phase 2 — Apply Incremental Backups (Repeated, Source READ WRITE)
Apply incremental backups on the target repeatedly over days or weeks while the tablespace is still online. Each application reduces the final sync window.
-- On SOURCE: take incremental backup since last SCN
-- Run this command multiple times over the migration period
BACKUP
FOR TRANSPORT
ALLOW INCONSISTENT
FROM SCN <last_applied_scn>
TABLESPACE sales_data, sales_idx
FORMAT '/oracle/staging/xtt/incr_%U';# On TARGET: restore incremental to advance the datafiles
rman target /
RMAN> RECOVER
FOREIGN TABLESPACE sales_data, sales_idx
FROM BACKUPSET '/oracle/staging/xtt/incr_*'
FOREIGN DATAFILECOPY '/oracle/staging/xtt/datafiles/*';Run Phase 2 daily (or more frequently) as the migration date approaches. Each run reduces the SCN gap, meaning the final READ ONLY window shrinks. For a 2TB tablespace, daily incrementals typically take only minutes if change rate is low.
Phase 3 — Final Cutover (Minimal Downtime Window)
During the maintenance window, put the tablespace in READ ONLY and take the final incremental backup. This is the only period of actual downtime.
-- On SOURCE: set tablespace READ ONLY (START of downtime)
ALTER TABLESPACE sales_data READ ONLY;
ALTER TABLESPACE sales_idx READ ONLY;
-- Take the final incremental backup
BACKUP
FOR TRANSPORT
FROM SCN <last_applied_scn>
TABLESPACE sales_data, sales_idx
FORMAT '/oracle/staging/xtt/final_%U'
DATAPUMP FORMAT '/oracle/staging/xtt/final_meta_%U';# Transfer final backup to target
scp /oracle/staging/xtt/final_* oracle@target-server:/oracle/staging/xtt/Phase 4 — Apply Final Incremental on Target
# On TARGET: apply the final incremental
rman target /
RMAN> RECOVER
FOREIGN TABLESPACE sales_data, sales_idx
FROM BACKUPSET '/oracle/staging/xtt/final_*'
FOREIGN DATAFILECOPY '/oracle/staging/xtt/datafiles/*';Phase 5 — Import Tablespace on Target
-- On TARGET: import the tablespace using Data Pump metadata file
-- The metadata dump was created in Phase 1/Phase 3 DATAPUMP FORMAT step
impdp '/ as sysdba'
DUMPFILE=final_meta_%U.dmp
DIRECTORY=DATA_PUMP_DIR
TRANSPORT_DATAFILES='/oracle/staging/xtt/datafiles/sales_data_01.dbf',
'/oracle/staging/xtt/datafiles/sales_idx_01.dbf'-- Verify tablespace is now part of target DB
SELECT tablespace_name, status FROM dba_tablespaces
WHERE tablespace_name IN ('SALES_DATA','SALES_IDX');
-- Make tablespace READ WRITE on target
ALTER TABLESPACE sales_data READ WRITE;
ALTER TABLESPACE sales_idx READ WRITE;Phase 6 — Drop or Migrate Source Tablespace
-- On SOURCE: after confirming target is working,
-- drop the tablespace (or leave READ ONLY temporarily for rollback window)
DROP TABLESPACE sales_data INCLUDING CONTENTS AND DATAFILES;
DROP TABLESPACE sales_idx INCLUDING CONTENTS AND DATAFILES;Endian Conversion Handling
When source and target platforms have different endian formats (e.g., Solaris Big Endian → Linux Little Endian), Oracle RMAN automatically converts blocks during the backup/restore. No manual conversion needed when using theFOR TRANSPORT syntax.
-- Verify endian compatibility before starting
SELECT platform_name, endian_format FROM v$transportable_platform
WHERE platform_name IN ('Solaris[tm] OE (SPARC)', 'Linux x86 64-bit');
-- Output:
-- Solaris[tm] OE (SPARC) Big
-- Linux x86 64-bit Little
-- Endian differs → RMAN handles conversion automatically in V4Endian conversion only applies to datafile blocks — the metadata (Data Pump export/import) is always platform-neutral XML. The V4 method handles this transparently unlike older methods that required RMAN CONVERT commands.
Comparison — V1/V2 vs V4 Method
| Feature | V1/V2 (old) | V4 (DocID 2471245.1) |
|---|---|---|
| Downtime | Full copy duration (hours/days) | Final incremental only (minutes) |
| Source during copy | READ ONLY | READ WRITE |
| Endian conversion | Manual RMAN CONVERT | Automatic |
| Incremental apply | Not supported | Supported (key advantage) |
| Min Oracle version | 8i+ | 12.1.0.2+ |