With Oracle AI Database 26ai, AES256 is the new default algorithm for Transparent Data Encryption (TDE). This shift reflects stronger security requirements, including alignment with emerging quantum-resistant practices. As a result, most databases that are upgraded to 26ai from prior releases will run rekey operations, and must do so without disrupting availability or Data Guard recovery.

Online vs. offline rekey: the choice is yours.

Before getting into the problem, it helps to be clear on the two ways to encrypt or rekey tablespaces with TDE.

Offline encryption/rekey

  • Requires the database to be mounted
  • No user activity allowed
  • Typically done on a standby first, then switchover
  • Keeps the primary running, but adds operational steps

Online encryption/rekey

  • Database stays open and active
  • Encryption happens while workloads continue
  • Simple to execute
  • Preferred in most environments

Online encryption is the easiest and most convenient, but in Data Guard environments it has a hidden cost.

By default, online encryption pauses the recovery

When you run:

ALTER TABLESPACE ... ENCRYPTION ONLINE REKEY;

This is what happens:

  • Primary starts online encryption or rekey
  • Redo is shipped to the standby
  • Standby recovery process encrypts the datafiles → recovery is paused
  • Once encryption is completed, the recovery resumes

There is no separate parallel worker: if the tablespace is large (hundreds of TB), encryption can take hours or days.

During that time:

  • Redo keeps arriving → RPO is safe
  • Redo is not applied → apply lag grows
  • Failover requires catch-up → RTO increases

What changes in 26ai

Oracle Database 26ai introduces a new parameter:

DB_RECOVERY_AUTO_REKEY

Set it to OFF on the standby:

ALTER SYSTEM SET DB_RECOVERY_AUTO_REKEY=OFF;

Now the behavior changes:

  • Primary performs online encrypt/rekey
  • Standby does not encrypt automatically
  • Recovery continues → no apply lag
  • The standby tablespace status becomes REKEYING (or ENCRYPTING, depending on the operation)
  • DBA completes encryption later in a foreground session

There’s no need to open the PDB. Opening the CDB$ROOT is enough.

Why this matters

With post-quantum considerations, many databases are moving from AES128 → AES256.

That means more frequent online rekey operations.

You need to do them:

  • Without downtime
  • Without lag
  • Without increasing RTO

26ai makes that possible.

Example: Online rekey without standby lag

Step 1: Verify TDE setup

SQL> select a.con_id, b.name, a.wrl_type, a.wrl_parameter, a.status, a.wallet_type
     from v$encryption_wallet a, v$containers b
     where a.con_id = b.con_id
     order by a.con_id;

CON_ID  NAME       WRL_TYPE  WRL_PARAMETER                         STATUS  WALLET_TYPE
------  ---------  --------  ------------------------------------  ------  -----------
1       CDB$ROOT   FILE      /.../wallet_root/tde/                   OPEN    AUTOLOGIN
2       PDB$SEED   FILE                                              OPEN    AUTOLOGIN
3       PDB1       FILE                                              OPEN    AUTOLOGIN

Step 2: Disable auto rekey on standby

SQL> ALTER SYSTEM SET DB_RECOVERY_AUTO_REKEY=OFF;

System altered.

Step 3: Create encrypted tablespace with a weaker algorithm on the primary

SQL> alter session set container=pdb1;

Session altered.

SQL> create tablespace users1
     datafile size 100m
     ENCRYPTION USING 'AES128' ENCRYPT;

Tablespace created.
SQL> SELECT TS#, ENCRYPTIONALG, STATUS FROM V$ENCRYPTED_TABLESPACES;

TS#  ENCRYPTIONALG  STATUS
---  -------------- -------
5    AES128         NORMAL

Step 4: Start online rekey on primary

SQL> ALTER TABLESPACE users1 ENCRYPTION ONLINE REKEY;

Tablespace altered.

Step 5: Observe standby behavior

On the standby:

SQL> SELECT TS#, ENCRYPTIONALG, STATUS FROM V$ENCRYPTED_TABLESPACES;

TS#  ENCRYPTIONALG  STATUS
---  -------------- ---------
5    AES128         REKEYING

Notice the behavior:

  • Status is REKEYING
  • Recovery is still applying redo
  • No apply lag accumulates

Step 6: Finish rekey on standby

SQL> alter session set container=pdb1;

Session altered.

SQL> alter tablespace users1 encryption online finish rekey;

Tablespace altered.
SQL> SELECT TS#, ENCRYPTIONALG, STATUS FROM V$ENCRYPTED_TABLESPACES;

TS#  ENCRYPTIONALG  STATUS
---  -------------- -------
5    AES256         NORMAL

The rekey operation is done by the foreground process.

Key takeaways

  • Online encryption is simple, but can block standby recovery
  • Large tablespaces amplify the impact
  • DB_RECOVERY_AUTO_REKEY=OFF avoids apply lag
  • Finish encryption later using a foreground session
  • No Active Data Guard required in 26ai

Oracle Database 26ai lets you rekey large tablespaces online while recovery stays current, preserving RPO and RTO.

Read more

https://docs.oracle.com/en/database/oracle/oracle-database/26/refrn/DB_RECOVERY_AUTO_REKEY.html

https://docs.oracle.com/en/database/oracle/oracle-database/26/dbtde/encryption-conversions-tablespaces-and-databases1.html#GUID-CD29F72C-780F-455C-B2BB-B089F23025E5