Transparent Data Encryption (TDE) Enablement in Oracle Database 19c

A practical, end-to-end DBA walkthrough for enabling TDE on Oracle 19c with ASM storage — covering wallet design, keystore lifecycle, master key management, online tablespace encryption, and operational best practices.

Transparent Data Encryption (TDE) is one of the most important security features in Oracle Database 19c. It protects sensitive data at rest by encrypting database files, tablespaces, backups, redo logs, and archive logs — all without requiring application-level changes. For enterprises subject to PCI-DSS, GDPR, HIPAA, NCA ECC-2, or similar mandates, TDE is no longer optional; it is a baseline control.

This guide provides a complete hands-on walkthrough for enabling TDE in Oracle 19c using ASM storage, including wallet configuration, software keystore creation, auto-login wallet setup, master encryption key generation, and online tablespace encryption with AES256.

1. What is Transparent Data Encryption (TDE)?

Transparent Data Encryption automatically encrypts data before it is written to storage and decrypts it when read by authorized users. The encryption and decryption are performed inside the Oracle kernel — completely transparent to applications, SQL statements, and end users.

TDE helps organizations:

Protect sensitive data from unauthorized access at the storage layer (stolen disks, leaked datafile copies, misconfigured backups).
Meet compliance requirements such as PCI-DSS, GDPR, HIPAA, SOX, and regional mandates like Saudi Arabia's NCA ECC-2 / CCC-2.
Secure backups and storage media, since RMAN, Data Pump, and archive logs inherit encryption from the source.
Encrypt tablespaces and database files transparently, with no changes to application logic, SQL, or user privileges.

TDE addresses a specific threat model: data at rest. It does not replace network encryption (Native Network Encryption / TLS), database auditing, fine-grained access control, or Database Vault — these layers complement each other.

2. TDE Architecture in Oracle 19c

TDE in Oracle 19c is built on a two-tier key hierarchy:

Component	Role
Keystore / Wallet	Secure container that stores the TDE master encryption key. Can be a software keystore (file-based) or a hardware keystore (HSM, OKV).
Master Encryption Key (MEK)	A single high-level key per database. Encrypts every tablespace encryption key. Stored only inside the keystore.
Tablespace / Column Encryption Keys	Per-tablespace (or per-column) data encryption keys, stored encrypted inside the database header. Used directly to encrypt/decrypt data blocks.

Why two tiers? Rotating the master key only re-encrypts the tablespace keys, not every block in the database — making key rotation an O(seconds) operation instead of O(terabytes).

Typical ASM Wallet Layout

+DATA1/DEV/wallet/
└── tde/
    ├── ewallet.p12     ← Password-protected software keystore
    └── cwallet.sso     ← Auto-login keystore (optional)

Oracle 19c Improvements

WALLET_ROOT — a unified, static initialization parameter that replaces the older sqlnet.ora ENCRYPTION_WALLET_LOCATION approach. Simpler, multitenant-aware, and ASM-friendly.
TDE_CONFIGURATION — a per-PDB-aware parameter that selects the keystore type (FILE, OKV, HSM).
Online tablespace encryption — encrypt existing tablespaces with users still connected, no outage required.
Native AES256 default — strong cipher with hardware-assisted acceleration on modern CPUs (AES-NI).

3. Environment Details

Component	Value
Database Version	Oracle Database 19c
Storage Type	ASM (Automatic Storage Management)
DB Unique Name	`DEV`
Encryption Algorithm	AES256
Wallet Location	`+DATA1/DEV/wallet`
Keystore Mode	Software keystore + auto-login
Sample Tablespace	`APPS` (online encryption target)

4. Pre-Implementation Checklist

Before starting, confirm the following:

Database is patched to a supported 19c Release Update (RU).
You have SYSDBA or a user with ADMINISTER KEY MANAGEMENT system privilege.
Sufficient ASM space on the diskgroup that will host the wallet (only a few MB needed).
A maintenance window for the one mandatory restart after setting WALLET_ROOT (static parameter).
An off-cluster backup destination for ewallet.p12 and cwallet.sso is identified — without these files, encrypted data is permanently lost.
The tablespaces selected for online encryption have at least as much free space as their largest datafile (Oracle creates a temporary copy during online encryption).
Existing RMAN backups have been validated; a fresh full backup is taken before any structural change.

5. Step-by-Step Implementation

Step 1 — Backup Existing SPFILE as PFILE

Before making configuration changes, take a backup of the existing SPFILE so parameter changes can be rolled back if necessary.

SQL> startup
SQL> create pfile='/tmp/pfile_backup.ora' from spfile;

Expected output:

File created.

This single text file becomes your safety net if any subsequent ALTER SYSTEM ... SCOPE=SPFILE change prevents a clean startup.

Step 2 — Verify `DB_UNIQUE_NAME`

The database unique name is important because wallet paths are conventionally organized using it (especially in Data Guard configurations where each member has a distinct DB_UNIQUE_NAME).

SQL> show parameter db_unique_name;

Example output:

NAME              TYPE      VALUE
----------------- --------- -----
db_unique_name    string    dev

Tip: If you run Data Guard, each standby database needs its own wallet under its own DB_UNIQUE_NAME directory. The master key inside, however, must be the same — copy ewallet.p12 from primary to each standby.

Step 3 — Check Existing Wallet and TDE Parameters

Verify whether TDE has already been partially configured.

SQL> show parameter wallet_root;
SQL> show parameter tde_configuration;

Expected output on a fresh database:

NAME                TYPE      VALUE
------------------- --------- -----
wallet_root         string
tde_configuration   string

Empty values confirm that TDE is not yet configured — proceed with the next steps.

Step 4 — Create Wallet Directories in ASM

Create the wallet directories using the ASM Command Line utility (asmcmd). Run this as the Grid Infrastructure owner (typically grid).

$ asmcmd
ASMCMD> mkdir +DATA1/DEV/wallet
ASMCMD> mkdir +DATA1/DEV/wallet/tde
ASMCMD> ls +DATA1/DEV/wallet

Expected listing:

tde/

Naming convention: +<DISKGROUP>/<DB_UNIQUE_NAME>/wallet/tde is the most widely adopted convention and aligns cleanly with WALLET_ROOT semantics.

Step 5 — Configure `WALLET_ROOT` Parameter

Set the wallet root location at the database level.

SQL> ALTER SYSTEM SET WALLET_ROOT='+DATA1/DEV/wallet' SCOPE=SPFILE;

Expected output:

System altered.

Important: WALLET_ROOT is a static parameter — the database must be restarted for the change to take effect.

Restart the Database

SQL> shutdown immediate;
SQL> startup;

Verify the Parameter

SQL> show parameter wallet_root;

Expected output:

NAME           TYPE     VALUE
-------------- -------- -------------------------
wallet_root    string   +DATA1/DEV/wallet

Step 6 — Configure TDE Keystore Type

Configure the database to use a file-based keystore. (Other valid values are OKV for Oracle Key Vault and HSM for hardware security modules.)

SQL> ALTER SYSTEM SET tde_configuration='KEYSTORE_CONFIGURATION=FILE' SCOPE=SPFILE;

Note: TDE_CONFIGURATION is dynamic in 19c when you use SCOPE=BOTH, but using SCOPE=SPFILE followed by a restart is the safest approach for first-time setup.

Verify:

SQL> show parameter tde_configuration;

Expected output:

NAME                TYPE      VALUE
------------------- --------- -------------------------------
tde_configuration   string    KEYSTORE_CONFIGURATION=FILE

Step 7 — Verify Wallet Status

Check the wallet status before creating the keystore.

SQL> select status from v$encryption_wallet;

Expected output:

STATUS
----------------
NOT_AVAILABLE

For a more detailed view:

SQL> set lines 200 pages 200
SQL> col WRL_PARAMETER for a60
SQL> col STATUS for a30

SQL> select WRL_TYPE, WRL_PARAMETER, STATUS
     from v$encryption_wallet;

Expected output:

WRL_TYPE   WRL_PARAMETER                 STATUS
---------- ----------------------------- ----------------
ASM        +DATA1/DEV/wallet/tde/        NOT_AVAILABLE

This confirms that Oracle resolves the wallet path correctly but no keystore file exists yet.

Step 8 — Create the Software Keystore

Create the password-protected software keystore. Choose a strong password and store it in your enterprise password vault — losing it makes the wallet unrecoverable except from backup.

SQL> ADMINISTER KEY MANAGEMENT CREATE KEYSTORE
     '+DATA1/DEV/wallet/tde'
     IDENTIFIED BY manager;

Expected output:

keystore altered.

The literal password manager is shown for demonstration only. In production, use a complex passphrase of at least 14 characters with mixed case, numbers, and symbols.

Verify Wallet Files

ASMCMD> ls +DATA1/DEV/wallet/tde

Expected output:

ewallet.p12

The ewallet.p12 file is the encrypted PKCS#12 keystore. It contains the master key metadata and is password-protected — it will not auto-open at instance startup.

Step 9 — Create Auto-Login Keystore

Create an auto-login wallet so the keystore opens automatically at instance startup, removing the need for manual ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN ... after every restart.

SQL> ADMINISTER KEY MANAGEMENT CREATE AUTO_LOGIN KEYSTORE
     FROM KEYSTORE '+DATA1/DEV/wallet/tde'
     IDENTIFIED BY manager;

Expected output:

keystore altered.

Verify Files

ASMCMD> ls +DATA1/DEV/wallet/tde

Expected output:

cwallet.sso
ewallet.p12

File	Purpose
`ewallet.p12`	Password-protected keystore — the source of truth, required for key rotation and administrative operations.
`cwallet.sso`	Auto-login keystore — derived from `ewallet.p12`, opens automatically when the instance starts.

Verify Wallet Status

SQL> select WRL_TYPE, WRL_PARAMETER, STATUS
     from v$encryption_wallet;

Expected output:

WRL_TYPE   WRL_PARAMETER                STATUS
---------- ---------------------------- --------------------
ASM        +DATA1/DEV/wallet/tde/       OPEN_NO_MASTER_KEY

The wallet is open, but no master encryption key has been generated yet.

Security trade-off: Auto-login wallets simplify operations but mean that anyone with access to cwallet.sso plus the datafiles can read encrypted data. For the strongest posture, prefer local auto-login (binds to the host) or use a password-protected keystore with controlled startup automation.

Step 10 — Open the Keystore

Even though cwallet.sso causes the wallet to open at startup, you must explicitly open it now to perform administrative key management on the freshly created keystore.

SQL> ADMINISTER KEY MANAGEMENT
     SET KEYSTORE OPEN
     FORCE KEYSTORE
     IDENTIFIED BY manager;

Expected output:

keystore altered.

The FORCE KEYSTORE clause is required when an auto-login wallet is already open — it temporarily switches to the password-protected keystore to allow privileged operations.

Step 11 — Create the Master Encryption Key

Generate the TDE master encryption key. The WITH BACKUP clause is mandatory — Oracle creates a copy of the keystore (ewallet_<timestamp>.p12) before modifying it.

SQL> ADMINISTER KEY MANAGEMENT
     SET KEY
     FORCE KEYSTORE
     IDENTIFIED BY manager
     WITH BACKUP;

Expected output:

keystore altered.

Verify Wallet Status

SQL> select WRL_TYPE, WRL_PARAMETER, STATUS
     from v$encryption_wallet;

Expected output:

WRL_TYPE   WRL_PARAMETER                STATUS
---------- ---------------------------- -------
ASM        +DATA1/DEV/wallet/tde/       OPEN

🎉 TDE is now fully enabled at the database level. The infrastructure is in place; the next step is to encrypt actual data.

Step 12 — Verify Existing Encrypted Tablespaces

Before encrypting anything, take inventory of the current encryption state.

SQL> select t.name,
            e.encryptionalg,
            e.encryptedts,
            e.status
     from v$encrypted_tablespaces e,
          v$tablespace t
     where t.ts# = e.ts#(+);

Example output:

NAME       ENCRYPTIONALG   ENCRYPTEDTS   STATUS
---------- --------------- ------------- --------
APPS
SYSAUX
UNDOTBS1
USERS
TEMP
SYSTEM

No tablespaces are currently encrypted. The outer join surfaces every tablespace; encryption columns are NULL for unencrypted ones.

Step 13 — Encrypt Existing Tablespace Online

Oracle 19c supports online tablespace encryption with minimal downtime — the tablespace remains read/write throughout, and Oracle relocates extents into encrypted form transparently.

SQL> ALTER TABLESPACE apps
     ENCRYPTION ONLINE
     USING 'AES256'
     ENCRYPT;

Expected output:

Tablespace altered.

What Happens Under the Hood

Oracle creates an auxiliary set of datafiles (you must have at least equivalent free space).
Extents are copied from the source datafile into the auxiliary file in encrypted form.
After all extents are migrated, the original datafile is dropped and the auxiliary becomes authoritative.
The tablespace key is stored encrypted inside the datafile header, wrapped by the master encryption key.

For very large tablespaces, encryption can be paused/resumed:

ALTER TABLESPACE apps ENCRYPTION ONLINE FINISH ENCRYPT;

Supported algorithms: AES128, AES192, AES256 (default and recommended), 3DES168, ARIA128/192/256, GOST256, SEED128. AES256 is the standard choice for new deployments.

Step 14 — Verify Tablespace Encryption

SQL> select t.name,
            e.encryptionalg,
            e.encryptedts,
            e.status
     from v$encrypted_tablespaces e,
          v$tablespace t
     where t.ts# = e.ts#(+);

Expected output:

NAME       ENCRYPTIONALG   ENCRYPTEDTS   STATUS
---------- --------------- ------------- --------
APPS       AES256          YES           NORMAL
SYSAUX
UNDOTBS1
USERS
TEMP
SYSTEM

The APPS tablespace is now encrypted using AES256, with status NORMAL (i.e., encryption finished cleanly and the tablespace is fully online).

6. Important Views for TDE Administration

View	Purpose
`V$ENCRYPTION_WALLET`	Wallet path, type, status (`OPEN`, `CLOSED`, `OPEN_NO_MASTER_KEY`).
`V$ENCRYPTION_KEYS`	Master keys ever generated; key IDs, activation timestamps.
`V$ENCRYPTED_TABLESPACES`	Encrypted tablespaces, algorithm, encryption status.
`DBA_ENCRYPTED_COLUMNS`	Per-column TDE encryption (when used).
`DBA_TABLESPACE_USAGE_METRICS`	Free-space confirmation before online encryption.

Quick reference queries:

-- Wallet status
SELECT * FROM v$encryption_wallet;

-- Encryption key history
SELECT key_id, creation_time, activation_time, creator, user
FROM   v$encryption_keys
ORDER  BY creation_time;

-- All encrypted tablespaces
SELECT * FROM v$encrypted_tablespaces;

7. Recommended Best Practices

7.1 Use Auto-Login Wallet Carefully

Auto-login wallets simplify startup but reduce the security perimeter — anyone with cwallet.sso plus datafiles can read your data.

Prefer local auto-login (CREATE LOCAL AUTO_LOGIN KEYSTORE) — the wallet only opens on the original host.
Restrict OS and ASM permissions on the wallet directory to the Oracle owner only.
Never copy cwallet.sso to file shares, snapshots, or developer laptops.

7.2 Backup Wallet Files Religiously

Without ewallet.p12, encrypted data becomes permanently unrecoverable. Backup is non-negotiable.

Always back up:

ewallet.p12 (password-protected — the master)
cwallet.sso (auto-login — convenience)
All ewallet_<timestamp>.p12 files generated by WITH BACKUP operations

7.3 Store Wallet Backups Outside ASM

Maintain copies in at least two independent locations, separate from the database storage:

Secure NAS or encrypted file share
Object storage (OCI Object Storage, AWS S3, Azure Blob) with bucket-level encryption
Offline vault / safe for ultra-critical environments
Enterprise secrets manager (HashiCorp Vault, CyberArk)

A wallet that lives only inside the same diskgroup as the encrypted datafiles offers no protection against site failure or storage corruption.

7.4 Rotate Master Keys Periodically

Periodic key rotation is recommended by NIST and most compliance frameworks (typically every 12–24 months, or after any suspected compromise).

ADMINISTER KEY MANAGEMENT
SET KEY
FORCE KEYSTORE
IDENTIFIED BY manager
WITH BACKUP USING 'rotation_2026q2';

Rotation re-encrypts only the tablespace keys, not the data — completing in seconds even on multi-terabyte databases.

7.5 Treat Keystore Passwords as Privileged Credentials

Store keystore passwords in an enterprise password vault, not in scripts or runbooks.
Use distinct passwords per environment (DEV / TEST / PROD).
Rotate passwords (ADMINISTER KEY MANAGEMENT ALTER KEYSTORE PASSWORD) on a schedule and after personnel changes.

7.6 Plan for Data Guard and RMAN

Data Guard: copy ewallet.p12 to every standby; standbys cannot open redo without the same master key.
RMAN: when WALLET_ROOT is configured, RMAN backups of encrypted tablespaces are encrypted by default. Use CONFIGURE ENCRYPTION FOR DATABASE ON; for full-database encrypted backups.
Data Pump: use ENCRYPTION=ALL and ENCRYPTION_MODE=TRANSPARENT to inherit keystore-based encryption automatically.

8. Common Errors and Troubleshooting

`ORA-28367: wallet does not exist`

Cause:

Incorrect wallet path
Wallet directory missing in ASM
WALLET_ROOT not yet effective (database not restarted after setting it)

Solution:

Verify WALLET_ROOT with show parameter wallet_root.
Confirm the ASM directory exists: ASMCMD> ls +DATA1/DEV/wallet/tde.
If the parameter was just changed with SCOPE=SPFILE, restart the database.

`ORA-28353: failed to open wallet`

Cause:

Incorrect password
Corrupted or partially copied wallet file
Wallet file on a filesystem unreachable from the instance (cluster failover edge case)

Solution:

Confirm the keystore password — it is case-sensitive.
Verify file integrity (ASMCMD> ls -l ...); restore from backup if size or timestamp is unexpected.
On RAC, ensure the wallet path is reachable from every node.

`Wallet Status = OPEN_NO_MASTER_KEY`

Cause:
The keystore is open but no master encryption key has been generated.

Solution:

ADMINISTER KEY MANAGEMENT
SET KEY
FORCE KEYSTORE
IDENTIFIED BY manager
WITH BACKUP;

`ORA-28365: wallet is not open`

Cause:
Auto-login wallet is missing, or password-protected wallet has not been opened explicitly.

Solution:

ADMINISTER KEY MANAGEMENT
SET KEYSTORE OPEN
FORCE KEYSTORE
IDENTIFIED BY manager;

Or create a cwallet.sso (Step 9) so it auto-opens on startup.

`ORA-28374: typed master key not found in wallet`

Cause:
The database expects a master key (referenced by encrypted datafiles) that is not present in the current wallet — typically after restoring datafiles to a new host without the wallet, or copying datafiles between databases.

Solution:

Restore the matching ewallet.p12 from backup.
If migrating between databases, export and import keys with ADMINISTER KEY MANAGEMENT EXPORT/IMPORT KEYS.

Online Encryption Fails with Insufficient Space

Cause:
Online tablespace encryption needs free space equal to the size of the largest datafile being encrypted.

Solution:

Add a temporary datafile to the tablespace, or
Add space to the diskgroup, or
Use the offline encryption path (ALTER TABLESPACE ... OFFLINE; ALTER DATABASE DATAFILE ... ENCRYPT;) when downtime is acceptable.

9. Operational Considerations

9.1 Performance Impact

With AES-NI hardware acceleration on modern Intel/AMD CPUs, the overhead of AES256 TDE is typically 2–5% for OLTP workloads and is often negligible for I/O-bound workloads (the bottleneck is disk, not CPU). Always benchmark on your hardware before broad rollout.

9.2 Things That Are Encrypted Automatically Once TDE Is On

Redo logs generated for changes to encrypted blocks
Archive logs containing those redo records
Undo blocks generated by transactions on encrypted tablespaces
Temporary tablespace blocks spilled from queries on encrypted data
RMAN backups of encrypted tablespaces (when written to disk)

9.3 Things That Are NOT Automatically Encrypted

Pre-existing tablespaces — you must run ALTER TABLESPACE ... ENCRYPT for each.
The SYSTEM tablespace — encrypting it requires extra steps and is supported only from 12.2 onward; plan carefully.
External tables, BFILE pointers, and OS-level files — TDE only protects what lives inside the database.
Data in flight — use Native Network Encryption or TLS for that.

9.4 Multitenant (CDB/PDB) Notes

In a multitenant deployment:

The CDB has its own master key.
Each PDB has its own master key, isolated from sibling PDBs.
Wallet operations executed in the root affect the CDB; switch to the PDB (ALTER SESSION SET CONTAINER = ...) to manage the PDB's key.
Cloning, plugging in, and unplugging PDBs all interact with TDE — read MOS Note 2253215.1 before performing these operations on encrypted PDBs.

10. Benefits of TDE in Oracle 19c

Transparent encryption/decryption with no application or SQL changes.
Online tablespace encryption that eliminates downtime windows.
Strong AES256 ciphers with hardware-accelerated performance.
Backup protection — RMAN, Data Pump, and archive logs inherit encryption.
Compliance readiness — addresses controls in PCI-DSS, GDPR, HIPAA, SOX, NCA ECC-2, and ISO 27001.
Two-tier key hierarchy that makes master-key rotation a near-zero-cost operation.
Unified WALLET_ROOT parameter that simplifies setup vs. legacy sqlnet.ora configuration.
Multitenant isolation — each PDB owns an independent master key.

11. Conclusion

Transparent Data Encryption in Oracle Database 19c is a critical security capability for protecting enterprise data at rest. Oracle 19c modernizes TDE deployment via WALLET_ROOT, unified keystore management, and online tablespace encryption, allowing DBAs to encrypt entire databases with minimal operational disruption.

By following this guide, database administrators can confidently configure:

✅ TDE wallets in ASM
✅ Software keystores (ewallet.p12)
✅ Auto-login wallets (cwallet.sso)
✅ Master encryption keys with WITH BACKUP
✅ Online tablespace encryption with AES256
✅ Routine key rotation and verified wallet backups

Implementing TDE significantly strengthens an organization's database security posture and is foundational to satisfying modern regulatory and compliance requirements — including Saudi Arabia's NCA ECC-2:2024 and CCC-2:2024 controls, and the encryption mandates common across PCI-DSS, GDPR, and HIPAA programs.

Final reminder: TDE is only as strong as your wallet backup discipline. Encrypt your data — but never forget to back up the keys that unlock it. Test wallet recovery at least quarterly; an untested backup is a hope, not a control.

Thnaks for reading :)

BR,

ZAHEER