Physical transport: TTS with incremental backups
Where transportable tablespaces earn their place, and the conditions that undo projects.
Transportable Tablespaces with incremental backups moves Oracle data in its physical form: a level-0 baseline, a series of ordered level-1 incrementals, then a final incremental taken with the source read-only, after which data and metadata are restored to the target and validated.
Its appeal on a large platform is real. It avoids a full logical unload and reload, and the incremental structure means most of the movement happens while the source is still serving the business. For a genuinely large historical layer whose physical design is being preserved, nothing else moves the data with less business disruption.
The conditions are strict, and they are where projects come unstuck:
- Self-containment. Tablespace sets must be self-contained, including dependent objects and metadata. On a warehouse that has grown organically for a decade, this is frequently not the case, and untangling it is real work.
- Compatibility. Source release, platform, character set, encryption and feature usage all constrain eligibility.
- Target provisioning. The documented workflow may require a new target instance. If workloads or integrations have already been attached to an existing target, this is a design-invalidating constraint, not an inconvenience. Confirm it before you commit.
Two things to hold on to. First, a successful TTS test proves that the physical transport works and nothing else — your BI, ETL, procedural code, security model and operating procedures all need separate tests, and they are the ones that will find problems. Second, TTS preserves the physical design faithfully, including the parts of it you were hoping to leave behind. If your target design includes different partitioning, compression or tablespace layout, TTS is fighting you.
Use the TTS eligibility checklist in the reference section before investing in detailed assessment.