Transportable Tablespaces in Oracle 26ai

A transportable tablespace (TTS) operation transfers a set of user tablespaces by copying their physical datafiles and separately transferring the metadata that describes the objects stored in those files. In Oracle AI Database 26ai, a conventional workflow uses Data Pump Export and Import for the metadata and a separate file-transfer operation for the datafiles.

The central idea is straightforward: the table rows and index blocks already exist in Oracle datafiles. Transporting those files avoids unloading and reloading each row through a conventional logical export and import. This can make TTS attractive for large datasets, although copying files, performing any required conversion, and validating the result still take time.

This lesson explains a conventional transport between a source and a target pluggable database (PDB). It introduces the decisions behind the commands rather than providing a complete production migration runbook. TTS is an established Oracle capability that remains useful in 26ai.

A tablespace is a logical storage container. Its datafiles hold the physical blocks used by segments such as tables, indexes, and large objects. A transport operation brings those two perspectives together:

1. Datafiles: copies of every required file belonging to the selected tablespaces. These contain the stored data blocks.
2. Metadata dump: a Data Pump dump containing the associated object definitions and transport information needed by the receiving database.

The metadata dump does not replace the datafiles. Conversely, copying datafiles into a target directory does not register their tables and other objects in the target database. Both parts must belong to the same prepared transport operation.

For example, assume a warehouse application stores historical tables in WAREHOUSE1. If that tablespace has three datafiles, all three must be included in the transport, even when an example command shows only one. If strict containment checking identifies related storage in another tablespace, the transport set or object layout must be adjusted before proceeding.

TTS is especially useful when a substantial collection of data can be treated as a manageable unit. Typical uses include warehouse staging, historical archives, large database transfers, and distribution of reference data.

Consider a reporting system that needs several years of completed sales history. If the history and its associated storage are isolated in a suitable transport set, copying the files may be more practical than exporting and importing the same rows. The active application can continue using unrelated tablespaces while the historical set is prepared, subject to the application's dependencies.

The tablespace layout therefore matters. Organizing active and historical data separately can simplify future transport. Placing unrelated applications in the same tablespace can make the proposed transfer larger or more complicated than expected. TTS operates on selected tablespaces, not on an arbitrary business label such as “last year's orders.”

For a small selection of tables, a conventional Data Pump export may be simpler. Evaluate the required scope, permitted interruption, transfer capacity, and operational effort before selecting the method.

1. Source: Check the Transport Set

Run the following in the source PDB using an appropriately authorized account:

BEGIN
  DBMS_TTS.TRANSPORT_SET_CHECK(
    ts_list          => 'WAREHOUSE1',
    incl_constraints => TRUE,
    full_check       => TRUE
  );
END;
/

SELECT * FROM TRANSPORT_SET_VIOLATIONS;

incl_constraints => TRUE includes referential-integrity constraints in the check. full_check => TRUE requests strict checking of dependencies in both directions. The default is less strict, so explicitly selecting these options makes the example's intent clear.

Inspect the returned violations, resolve them, and rerun the check. No returned rows means the set passed the requested containment check. For several tablespaces, supply a comma-separated list in ts_list and use that same set throughout the workflow. Avoid changing the relevant object layout after validation.

2. Source: Establish the Read-Only Window

ALTER TABLESPACE warehouse1 READ ONLY;

Repeat this operation for each tablespace in the set. Read-only mode permits queries while preventing changes to the affected tablespace's contents. Applications that attempt writes to those objects must be accounted for in the maintenance plan.

For this conventional workflow, retain the source read-only state through metadata export and completion of the consistent datafile copies. Otherwise, files copied at different times could no longer represent the prepared set. Schedule the operation around actual application requirements, rather than assuming “historical” means nobody writes to the data.

3. Source: Export Transport Metadata

From the operating-system shell, run:

expdp tts_admin@srcpdb DIRECTORY=dp_dir DUMPFILE=tts_meta.dmp LOGFILE=tts_export.log TRANSPORT_TABLESPACES=WAREHOUSE1 TRANSPORT_FULL_CHECK=YES

Omitting a password lets Data Pump prompt for it. The account requires DATAPUMP_EXP_FULL_DATABASE for this export mode. The dump and log are written on the database server through DP_DIR, not automatically into the shell's current directory.

TRANSPORT_TABLESPACES selects transportable tablespace mode. It is different from TABLESPACES, which selects a conventional tablespace-mode export. TRANSPORT_FULL_CHECK=YES requests strict containment checking during export.

Review the export log for errors and record the required datafile list. Treat the dump, file list, and validation records as parts of one transfer package. If export fails, resolve the cause before treating the package as ready.

4. Transfer the Dump and All Datafiles

Copy tts_meta.dmp into the directory used by the target's DP_DIR. Copy every required datafile into suitable target storage. The example assumes ordinary filesystem paths; ASM and other storage configurations need an appropriate transfer procedure.

Use independent target copies. Do not point this example's import at files still being used as writable source datafiles. Verify that transfers completed successfully and that the target database can access the resulting files.

For cross-platform transport, inspect the supported platforms and their byte ordering:

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

Compare the actual source and target platforms. Different endian formats require a supported conversion procedure, such as an appropriate RMAN conversion workflow. Different operating systems do not automatically imply different endianness. Matching endianness also does not remove the other compatibility requirements.

Choose the RMAN procedure for the platform pair and storage layout rather than applying a generic conversion command. Advanced incremental cross-platform methods can reduce the final read-only window, but they require a separate backup and recovery plan.

After the conventional export and consistent file copies are safely complete, the source tablespace can return to READ WRITE if needed. Subsequent source changes are not propagated to the transported target copy.

5. Target: Import Metadata and Register the Files

Prepare the required owning schemas in the target PDB, confirm permissions, and resolve tablespace-name conflicts before import. Do not create an empty WAREHOUSE1 tablespace as a destination for this operation.

impdp tts_admin@dstpdb DIRECTORY=dp_dir DUMPFILE=tts_meta.dmp LOGFILE=tts_import.log TRANSPORT_DATAFILES='/u02/oradata/dstpdb/warehouse1_01.dbf'

The account requires the appropriate DATAPUMP_IMP_FULL_DATABASE role. The example assumes one datafile. Supply all transported datafile paths for a larger set, using syntax appropriate to the shell or a Data Pump parameter file.

TRANSPORT_DATAFILES identifies files accessible to the target database server. Import integrates the transported files and associated metadata into the target database. It does not reconstruct the table rows from a conventional row-data dump.

Modern transportable imports can temporarily make tablespaces read/write and return them to read-only. Ensure target file permissions allow the import's work, even if the intended final use is read-only. Review the import log rather than assuming that a finished utility session means every object is ready.

6. Target: Validate and Select the Final Mode

Check the target tablespace and registered files:

SELECT tablespace_name, status
FROM dba_tablespaces
WHERE tablespace_name = 'WAREHOUSE1';

SELECT file_id, file_name, bytes
FROM dba_data_files
WHERE tablespace_name = 'WAREHOUSE1'
ORDER BY file_id;

Compare the result with the expected file inventory. Confirm important tables, indexes, constraints, and application queries. Choose data checks proportionate to the workload, such as representative totals, key ranges, or row counts. A full count of every large table may be expensive; define the acceptance criteria in advance.

If the target application must update the transported data, change its tablespace mode:

ALTER TABLESPACE warehouse1 READ WRITE;

A reporting or archive target can remain read-only. The target's mode is independent of the source's mode because this workflow uses separate copies. Record the final state, complete application testing, and take an appropriate target backup before operational handover.

Before committing to TTS, review Oracle's current transport restrictions for the actual source and target combination. Check release and COMPATIBLE requirements, database and national character sets, supported platforms, tablespace block sizes, and object-type restrictions. A successful containment check does not certify these other conditions.

Encrypted tablespaces and encrypted columns require additional planning. Confirm the supported transport method and necessary encryption-key or keystore handling. Copying encrypted datafiles alone does not establish that the destination can use them.

This lesson concerns user tablespaces. Do not apply its commands to transport SYSTEM, SYSAUX, undo, or temporary tablespaces as an ordinary user transport set. Full transportable export/import and moving an entire PDB have different scopes and procedures.

Plan capacity for staging as well as final storage. Conversion may require additional space, and retaining the original transfer package can help with diagnosis or a controlled retry. Decide which files can be removed only after validation and recovery requirements are satisfied.

Practice identifying a transport set, its dependencies, and the files needed at the destination in the Transportable Tablespaces - Exercise.

In the next lesson, you will examine operational considerations related to READ ONLY tablespaces.