Oracle TDE: Observations on Online Encryption, Standby Behaviour, and Crash Recovery

 

In the modern security landscape, Transparent Data Encryption (TDE) is no longer optional, it is a fundamental requirement for protecting data at rest. While the ALTER TABLESPACE command seems straightforward, the underlying mechanics of how Oracle handles online encryption especially in environments with Data Guard can be surprising.

Recently, I’ve been exploring the nuances of online TDE operations. Here are the key takeaways and "gotchas" every DBA should know before hitting 'enter' on that encryption command.

1. The Power of Online Encryption

Oracle allows you to encrypt an existing unencrypted tablespace while the database is open and being accessed by users. The syntax is simple:

SQL

ALTER TABLESPACE TEST ENCRYPTION ONLINE ENCRYPT;

Pro Tip: In Oracle 19c, the default algorithm is AES128. If your security standards require AES256, you should set the parameter tablespace_encryption_default_algorithm to 'AES256' or specify it explicitly in your command or specify the algorithm explicitly in the CREATE TABLESPACE command. 

New tablespace

I am going to create a new tablespace in my PDB and I want any new tablespaces to be encrypted.

SQL

alter system set encrypt_new_tablespaces=always;

Create tablespace test_encrypt;

The results confirm that the tablespace was successfully created, defaulting to AES128 encryption.

2. Real-time Standby Synchronization

One of the most impressive features of TDE in a Data Guard environment is how the standby database reacts.

• Observation: The standby database doesn't wait for the primary to finish. It receives the encryption command via REDO and begins its own online encryption process almost simultaneously.
• Latency: The time difference between the primary starting a datafile conversion and the standby starting is often measured in milliseconds.

3. The "Zeroing Out" Security Feature

When Oracle performs an online encryption, it creates a new encrypted datafile. But what happens to the old, unencrypted blocks on the disk? Oracle doesn't just delete the old file; it zeros out the original datafile before deletion. This ensures that no forensic tool can "undelete" the old file to read the unencrypted data. Note that this same process occurs during a rekey (e.g., moving from AES128 to AES256).

Primary Database Alert log:

Standby Database Alert log:

Notice that the conversion of the first datafile on the Primary started at 2026-03-10T10:48:44.473301-07:00 And the standby database started converting the first datafile at 2026-03-10T10:48:44.976604-07:00

The difference is milliseconds due to latency.

Note: we can observe the sequence of zeroing out original files also from the above logs.

4. The RMAN Surprise: Why Incremental Backups Might Fail You

This is a critical observation for backup strategies. Even though every block in your tablespace is being encrypted (and thus changed), RMAN does not necessarily see these as "changed blocks."

• The Reason: Online encryption changes the data within the block, but it often leaves the block header - specifically the SCN untouched.
• The Impact: If you rely on Block Change Tracking (BCT) and incremental backups, your next Level 1 backup might be tiny because RMAN thinks nothing has changed.
• The Fix: To ensure your backups are actually stored in an encrypted state, you must perform a new Level 0 backup immediately after the encryption process completes.

5. Handling Crashes During Encryption

What happens if the database or server crashes in the middle of a tablespace rekey?

• The Rule: Once started, you cannot back out. There is no "undo" for a TDE encryption in progress.
• The Status: Upon restart, the tablespace will likely show a status of REKEYING in V$ENCRYPTED_TABLESPACES.
• The Recovery: You must manually resume and finish the operation using:

SQL

ALTER TABLESPACE TEST ENCRYPTION FINISH REKEY;

• The Cleanup: A crash during the "zeroing out" phase may leave "orphan" files on your storage. Always check your data directory for old files that weren't successfully deleted and clean them up manually to save space.

Summary Checklist for DBAs:

1. Backup first: Even though it’s "online," never perform encryption without a fresh backup.
2. Monitor the Alert Log: Both primary and standby logs will provide millisecond-level detail on the conversion progress.
3. Plan for Storage: Remember that for a period, you will need double the space for the tablespace being encrypted as the new files are created alongside the old ones.
4. Reset Backups: Schedule a Full/Level 0 backup immediately following the TDE conversion.

TDE is a robust tool, but understanding these "under the hood" behaviours is what separates a standard DBA from an Oracle expert.