Posts

Showing posts from June, 2026

DEMO TIME: Oracle "Split TDE" for easier on-prem to cloud migration (and repatriation)

Image
This video explains "split TDE", which was introduced in Oracle Database 19.16 and simplifies on-prem to cloud migration (and repatriation) for customers who do not have an on-prem TDE license but are subject to an encryption mandate for their Oracle cloud databases (The encryption mandate applies to all Oracle databases that are manged by OCI, regardless of the cloud provider, unless you choose to manually install your databases in a cloud compute node).

Upgrade encrypted databases to 26ai

  Oracle AI Database 26ai has been made available to all customers (on-prem or any cloud). With this, the "upgrade" question will come sooner rather than later. Upgrading to Oracle AI Database 26ai  is only possible from 19c and 21c , older releases cannot be directly upgraded to 26ai. If your 19c or 21c databases are encrypted, and TDE is set up with the old (desupported) sqlnet.ora parameters (ENCRYPTION_WALLET_LOCATION), upgrades will be blocked and pre-upgrade checks will fail with 'TDE_WALLET_ROOT_NOT_IN_USE'. You need to have WALLET_ROOT and TDE_CONFIGURATION set before the upgrade. Also, the GOST and ARIA encryption algorithms are desupported in 26ai; before upgrading, online-rekey those tablespaces to AES with XTS cipher mode; for upgrades via database links to 26ai CDBs, we have introduced the "rekey using" parameter: SQL> create pluggable database "FINANCE" from FINANCE@dblink rekey using 'AES256' MODE 'XTS'; ...
TDE_HEALTHCHECK  The TDE health-check was planned to give Oracle Support personnel a quick overview about your TDE setup, but eventually it was decided to include it in recent Oracle Database RUs in 19c and 26ai. In Oracle database 19c before 19.30, you need to apply patch 38486044 . It is very easy to use: First, compile it with: SQL> @$ORACLE_HOME/rdbms/admin/tde_healthcheck.sql To get the complete results, simply execute: SQL> execute tde_healthcheck.get_tde_healthcheck_report; Individual checks allow for a more targeted validation: SQL> exec tde_healthcheck.get_wallet_root; Display WALLET_ROOT from gv$parameter.  SQL> exec tde_healthcheck.get_wallet_ location; Where are my TDE wallets? Usually in WALLET_ROOT/tde   SQL> exec tde_healthcheck.get_tde_config; Shows the value of the parameter TDE_CONFIGURATION. SQL> exec tde_healthcheck.get_props_ details; Read the TDE configuration from internal tables.  SQL> exec tde_healthcheck.valida...

Copy TDE wallets out of and into ASM with kscopy

  As organizations continue to strengthen their database security posture, centralizing encryption key management has become an increasingly important operational and compliance requirement. Oracle Key Vault (OKV) provides a secure, scalable platform for managing Transparent Data Encryption (TDE) master keys across enterprise database environments. When migrating existing encrypted Oracle RAC databases from traditional wallet-based key management to OKV, careful planning can help ensure a smooth transition while preserving access to both current and historical encryption keys.  Before migrating an encrypted, RAC-enabled database from a shared local TDE wallet to OKV, it is recommended to leverage OKV's unique capability and upload the current and all retired TDE keys to OKV. In Oracle RAC, only shared wallets (for example stored in ACFS or directly in ASM) that can be accessed by all RAC instances are supported. Using individual TDE wallets for each RAC node is ...