You can use transportable tablespace to migrate your data between databases. It is a great way of moving your data. How does it work together with TDE Tablespace Encryption?

It depends on which kind of migration you are planning. The endian format of the source and target platforms (or operating system) plays a vital role.

First, you determine the endian format of the source and target database:

SQL> select platform_name, endian_format from v$transportable_platform;

• If the endian formats are identical, you will perform a same-endian migration.
• If the endian formats differ, you will perform a cross-endian migration.

Same-endian Migration of TDE Encrypted Tablespaces

It is supported to use transportable tablespace when you migrate to a different platform as long as the endian format does not change.

Oracle Database uses a two-tier key architecture which consists of two encryption keys:

• Master Encryption Key (MEK)
• Tablespace Encryption Key (TEK)

In the tablespace, the TEK is stored. When you use transportable tablespace, you copy the data files, and thus, the TEK remains the same. The data in the tablespace continues to be encrypted during the entire migration using the same TEK.

But what about the MEK? It is required to get access to the TEK.

Option 1: Use ENCRYPTION_PASSWORD parameter

1. During Data Pump transportable tablespace export, you specify an ENCRYPTION_PASSWORD:

   expdp ... encryption_password=<a_strong_and_secure_password>
   

   The encryption password is not the MEK of the source but a special password you choose for the migration only.

2. On import, you specify the encryption password:

   impdp ... encryption_password=<a_strong_and_secure_password>
   

A benefit of this option is that the source and target database is encrypted using a different MEK. You can query the database and verify that no new MEK is added to the target database. The target database continues to use its own MEK:

SQL> select * from v$encryption_keys;

According to the documentation, this is the recommended option.

Option 2: Import Master Encryption Key

1. You start the Data Pump transportable tablespace export.
2. In the source database, you export the source database MEK:

   SQL> administer key management export keys 
        with secret "<another_strong_and_secure_password>"
        to '/home/oracle/secure_location/exported-keys'
        force keystore identified by "<source_database_MEK";
   

3. You import the source database MEK into the target database:

   SQL> administer key management import keys 
        with secret "<another_strong_and_secure_password>"
        from '/home/oracle/secure_location/exported-keys'
        force keystore identified by "<target_database_MEK>"
        with backup;
   

4. You start the Data Pump transportable tablespace import.

By querying v$encryption_keys, you can see that another key has been added to the database.

You can read more about export and import of MEKs in the documentation.

Option 3: Oracle Key Vault

If you are using Oracle Key Vault, it’s very easy to allow the target database to access the source database master encryption key.

When you perform the Data Pump transportable tablespace import in the target database, it will already have access to the encryption keys that protect the tablespaces. Nothing further is needed.

What About Rekeying?

If you make the source database encryption key available to the target database, consider whether you also want to perform a rekey operation. This applies to options 2 and 3.

ORA-39396

If you use options 2 or 3, you will receive the below warning during Data Pump transportable tablespace export:

ORA-39396: Warning: exporting encrypted data using transportable option without password

This is expected behavior:

This warning points out that in order to successfully import such a transportable tablespace job, the target database wallet must contain a copy of the same database master key used in the source database when performing the export. Using the ENCRYPTION_PASSWORD parameter during the export and import eliminates this requirement.

Cross-endian Migration of TDE Encrypted Tablespaces

You can’t migrate an encrypted tablespace to a platform with a different endian format using transportable tablespace. It is not supported.

If you have an encrypted tablespace and you want to use transportable tablespace:

1. Decrypt the tablespace
2. Migrate the tablespace using transportable tablespace
3. Re-encrypt the tablespace

Appendix

Further Reading

• Transparent Data Encryption FAQ
• Advanced Security Guide, Oracle Database 19c

Other Blog Posts in This Series

• Introduction
• Prerequisites
• Full Transportable Export/Import
• What Is a Self-contained Transportable Tablespace Set
• How to Migrate a Database Using Full Transportable Export/Import and Incremental Backups
• Make It Fast
• Backup on Standby Database
• Slow Network Between Source and Target
• Bigfile Tablespaces
• Testing the Procedure On Activated Standby Database
• Testing the Procedure Multiple Times Using Read-Only Tablespaces
• Target Database and Data Guard
• ASM Aliases and Why You Should Get Rid of Them
• How to use Transportable Tablespace with TDE Tablespace Encryption
• Pro Tips