Hybrid Oracle Data Guard without Transparent Data Encryption (TDE) License

Hybrid Oracle Data Guard can be made to comply with OCI encryption requirements even when the on-premises primary database has no Transparent Data Encryption (TDE) license—by shifting decryption/encryption behavior to the standby side using a new static initialization parameter. The core issue is straightforward: if an unencrypted on-prem primary ships redo/data to an OCI standby over an encrypted channel, Oracle’s mandate still requires that data be encrypted before it’s written to the standby. Without special handling, a role switch would force manual intervention—decrypting incoming data on the standby and then re-encrypting it, which effectively demands a fully functional TDE setup (including licensing) on the primary.

Oracle Database 19.16 addresses this gap. With the right configuration, the primary can remain unencrypted while still participating in a complete TDE environment: the primary sends cleartext over an encrypted transport, but the standby decrypts before writing. After a Data Guard role switch, the newly promoted primary can immediately access the required encryption keys because the standby has an auto-open wallet and the master key is already present. The mechanism relies on introducing the static initialization parameter TABLESPACE_ENCRYPTION with a “decrypt only” setting on the side that lacks a TDE license, and complementary settings on the other side so that tablespaces end up encrypted with AES256 where required.

A live walkthrough demonstrates the operational steps. First, both primary (on-prem) and standby (OCI) create the directory structure needed for TDE wallet storage and set WALLET_ROOT, a static parameter that requires a restart. Next, the configuration diverges: the on-prem primary sets TABLESPACE_ENCRYPTION to decrypt-only behavior (and ensures the default algorithm is AES256 rather than the default AES128), while the OCI standby sets the parameter to auto-enable so tablespaces are encrypted as they are created/replicated. The demo then creates a password-protected auto-open wallet on the primary, sets the first master encryption key for the container database and all PDBs, and copies the wallet to the standby.

To prove encryption is actually happening, the demo creates an encrypted tablespace on the primary, inserts and queries data, and verifies from the root container that the corresponding tablespace is encrypted on the standby. While the standby’s MRP is paused briefly, remaining tablespaces are encrypted—only the ones targeted for user/system coverage—without primary downtime. After restarting MRP, queries confirm which tablespaces are encrypted on each side.

Finally, a Data Guard broker role switch promotes the standby. The new primary can read encrypted data immediately because the auto-open wallet is in place and the master key is available. The demo deletes the original test tablespace, creates a new one, and shows that it becomes encrypted on the new primary (auto-enable behavior) while the old primary remains unencrypted.

The closing guidance broadens the message: even when only a few databases use hybrid deployment, key management still matters. Oracle Key Vault (OKV) is positioned as a way to centralize wallets and synchronize encryption keys across an OKV cluster, reducing wallet-copy overhead and avoiding key material on database hosts. The result is a cleaner operational model for Data Guard encryption in mixed licensing scenarios.