Back to Blog
Oracle 10 min readMay 29, 2025

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)
sql
-- 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.

sql
-- 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:

bash
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.

sql
-- 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';
bash
# 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.

sql
-- 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';
bash
# Transfer final backup to target
scp /oracle/staging/xtt/final_* oracle@target-server:/oracle/staging/xtt/

Phase 4 — Apply Final Incremental on Target

bash
# 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

sql
-- 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'
sql
-- 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

sql
-- 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.

sql
-- 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 V4
💡

Endian 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

FeatureV1/V2 (old)V4 (DocID 2471245.1)
DowntimeFull copy duration (hours/days)Final incremental only (minutes)
Source during copyREAD ONLYREAD WRITE
Endian conversionManual RMAN CONVERTAutomatic
Incremental applyNot supportedSupported (key advantage)
Min Oracle version8i+12.1.0.2+
All postsOracle · TTS · Cross-Platform · RMAN · MOS 2471245.1

naresh@gowda:~$ built with Next.js + Tailwind + Framer Motion