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
During Data Pump transportable tablespace export, you specify an
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.
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
- You start the Data Pump transportable tablespace export.
- 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";
- 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;
- You start the Data Pump transportable tablespace import.
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.
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:
- Decrypt the tablespace
- Migrate the tablespace using transportable tablespace
- Re-encrypt the tablespace
- Transparent Data Encryption FAQ
- Advanced Security Guide, Oracle Database 19c
Other Blog Posts in This Series
- 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
2 thoughts on “How to use Transportable Tablespace with TDE Tablespace Encryption”
Excellent article. I have learned from your blog a lot. Oracle TDE Tablespace Encryption is very good for data security. But it is a little bit to deal with if you lost MEK. I have come across this problem. We have a Test instance. Someone tested tablespace encryption with wallet a few years ago. Then the person left without leaving any wallet password and MEK information. Now when DBA log into this instance and do some work there. DB will request MEK information and block any queries. I consulted with Oracle Support. It seems that MEK missing cannot be brought back. I have to drop instance and re-create this instance again. Fortunately, this is a Test instance only. Thanks for your excellent blog on Oracle database admin.
Thanks for the kind words. I am glad that you find a use for my blog.
You’re absolutely right about TDE. As soon as you create a TDE Master Key, then that database is bound FOREVER together with the keystone. Even if you don’t encrypt any tablespaces, you have TDE enabled forever in that database.
When you create a TDE Master Key it is VERY important that the keystone and the password protecting the keystore are kept safe. There is no backdoor in our encryption. If you lose the TDE Master Key – you lose your data. Oracle won’t be able to help you.
I’m glad that it happened to you – only in a test database.