Encrypting an Existing Oracle Tablespace with TDE Without a Full Downtime Export

You have a production tablespace that holds PII and a new compliance requirement says data at rest must be encrypted. Export/import is not an option for the maintenance window you have, and you cannot create a new application user or change SQL. The useful takeaway is that Oracle Transparent Data Encryption can be applied to an existing tablespace with online redefinition, but the operational risk moves from the database to the wallet and key lifecycle.

The problem is the wallet, not the encryption

TDE encrypts data blocks with AES and keeps the tablespace usable by normal SQL. Applications do not need changes because encryption and decryption happen in the buffer cache. The master encryption key is stored in an Oracle Wallet or an HSM, and the wallet must be open for the instance to read encrypted blocks.

If the wallet is unavailable or the master key is lost, encrypted data becomes inaccessible. That is the primary operational boundary. For Data Guard, the standby must have access to the same wallet material and have the wallet open, otherwise redo apply will fail for encrypted objects.

Enable TDE for an existing tablespace with minimal disruption

The approach assumes Oracle Database 12c or later with TDE licensed and enabled. It requires SYSDBA for wallet and key management, and CREATE TABLESPACE privilege for the target user.

First, ensure a wallet exists and is open. Run as SYSDBA in SQL*Plus:

ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY \"&master_password\" FORCE KEYSTORE OPEN;

Set ENCRYPTION_WALLET_LOCATION to the wallet directory before opening. Verify wallet state with:

SELECT WRL_PARAMETER, STATUS FROM V$ENCRYPTION_WALLET;

STATUS should be OPEN for normal operation. The WRL_PARAMETER shows the wallet location used by the instance.

Create a new encrypted tablespace that will receive the data:

CREATE TABLESPACE encrypted_ts DATAFILE '&path/encrypted_ts01.db' SIZE 1G ENCRYPTION USING 'AES256' DEFAULT STORAGE(ENCRYPT);

Then move objects online with DBMS_REDEFINITION. This avoids a full export/import and keeps the original tablespace online during the copy. A simplified pattern is:

BEGIN DBMS_REDEFINITION.START_REDEF_TABLE(uname => 'SCHEMA_NAME', tname => 'TABLE_NAME', options_flag => DBMS_REDEFINITION.CONS_USE_ROWID); END;

Copy dependent objects, sync interim changes, and finish redefinition:

BEGIN DBMS_REDEFINITION.FINISH_REDEF_TABLE('SCHEMA_NAME','TABLE_NAME'); END;

Repeat for each table in the source tablespace or use a script to generate the calls. After redefinition, the table resides in the encrypted tablespace and its blocks are encrypted on write.

Check that encryption is actually in effect

Query the data dictionary to confirm the tablespace is marked encrypted:

SELECT TABLESPACE_NAME, ENCRYPTED FROM DBA_TABLESPACES WHERE TABLESPACE_NAME = 'ENCRYPTED_TS';

ENCRYPTED should be YES. For objects, check:

SELECT OWNER, TABLE_NAME, ENCRYPTED FROM DBA_TABLES WHERE TABLESPACE_NAME = 'ENCRYPTED_TS';

Measure CPU impact on a representative workload using AWR snapshots or SQL*Plus timing before and after the change. Typical overhead is low, often in the 1-3% CPU range for OLTP, because AES operations benefit from CPU AES-NI instructions and occur in memory. The exact impact depends on workload, CPU, and I/O profile.

Trade-off and limitation

Key rotation is supported without re-encrypting data. Changing the master encryption key updates the key in the wallet and re-wraps data keys. That satisfies periodic key-change policies without a data rewrite.

The limitation is operational coupling to the wallet. Backups of the wallet must be stored securely and separately from database backups. Restoring an encrypted tablespace without the correct wallet and master key will not succeed. In a Data Guard topology, wallet synchronization and open status must be maintained on primary and standby.

Rollback is possible before FINISH_REDEF_TABLE by calling DBMS_REDEFINITION.ABORT_REDEF_TABLE. After finish, reverting requires moving data back to an unencrypted tablespace using the same redefinition process.

Actionable close

Start with a non-critical schema, open the wallet, create one encrypted tablespace, and move a single table with DBMS_REDEFINITION. Verify ENCRYPTED = YES and wallet STATUS = OPEN. Document wallet location, backup procedure, and Data Guard wallet sync steps before expanding to PII tablespaces.