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'; 

If the source-PDB is already encrypted with the desired algorithm (for example a local or remote clone of a 26ai PDB that is already encrypted with AES256 in XTS cipher mode), consider using the "NO REKEY" clause. This clause avoids rotating the data encryption keys, which means that incoming tablespaces are not decrypted and re-encrypted with new keys. Turning that off will save some time, especially for bigger PDBs.


Location: San Diego, Kalifornien, USA

Comments

Post a Comment

Popular posts from this blog

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...
Read more

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 ...
Read more