Every time Oracle releases a major version, DBAs carefully review new SQL features and optimizer changes — and then quietly forget to review backup and recovery changes until something breaks in production. Oracle AI Database 26ai brings some of the most significant RMAN and security changes since the introduction of the Multitenant architecture. Some of these changes are additive and excellent. Others are breaking changes that will silently invalidate your existing backup procedures if you migrate from 19c without reviewing them. This post is the review you need to do before you upgrade.

The Biggest Breaking Change: Data Recovery Advisor is Gone

If you’ve been using RMAN’s Data Recovery Advisor (DRA) as part of your standard operational runbook — and many shops do — this is the change that will hurt most.

Starting in Oracle AI Database 26ai, the Data Recovery Advisor feature is desupported. The desupport of DRA includes desupporting the following RMAN commands: LIST FAILURE, ADVISE FAILURE, REPAIR FAILURE, and CHANGE FAILURE. Database administrators will no longer have access to these commands. There is no replacement feature for DRA. Dsp

Let that sink in. No replacement. These commands simply no longer exist in 26ai.

In Oracle 19c, DRA was already deprecated — Oracle had been signaling this removal for years. But “deprecated” means it still works. “Desupported” means it doesn’t. If your runbooks, monitoring scripts, or junior DBA training documents include any of these commands, they need to be updated before you touch production with 26ai.

# These commands work in Oracle 19c:
RMAN> LIST FAILURE;
RMAN> ADVISE FAILURE;
RMAN> REPAIR FAILURE;
# In Oracle AI Database 26ai:
# RMAN-00558: error encountered while parsing input commands
# RMAN-01009: syntax error: found "failure": expecting one of: ...
# These commands no longer exist.

What do you use instead?

Oracle’s guidance is to use standard RMAN diagnostics: VALIDATE DATABASE, CROSSCHECK BACKUP, and the V$DATABASE_BLOCK_CORRUPTION view for identifying and resolving failures. For block-level corruption, BLOCKRECOVER remains available. For media failures, standard RESTORE and RECOVER sequences apply. The DRA was a guided workflow layered on top of these — it’s the guided workflow that’s gone, not the underlying capabilities.

Review every script, runbook, and monitoring tool that references DRA commands. On 26ai, they will fail.

RECOVER…SNAPSHOT TIME Is Also Desupported

The RECOVER…SNAPSHOT TIME method of recovering a database to a point in time using a particular snapshot is desupported in Oracle AI Database 26ai. Instead, Oracle recommends that you use ALTER DATABASE BEGIN/END BACKUP before and after creating the storage snapshot of the data files and then use RECOVER…UNTIL TIME to a specific timestamp or SCN after the END BACKUP completion time. Dsp

This one affects organizations that use storage-level snapshots (NetApp, Pure Storage, EMC, OCI Block Volume snapshots) in combination with RMAN recovery. The old workflow was:

# Old workflow (works in 19c, broken in 26ai):
-- Take a storage snapshot of the database
RMAN> RECOVER DATABASE UNTIL TIME '...' SNAPSHOT TIME '...';

The new workflow in 26ai:

# Correct workflow for 26ai when using storage snapshots:
-- Before taking the snapshot:
SQL> ALTER DATABASE BEGIN BACKUP;
-- Take your storage snapshot here (NetApp, Pure, OCI, etc.)
-- After snapshot is complete:
SQL> ALTER DATABASE END BACKUP;
-- Record the SCN after END BACKUP:
SQL> SELECT current_scn FROM v$database;
-- If you need to recover using the snapshot:
RMAN> RECOVER DATABASE UNTIL SCN <scn_after_end_backup>;

This is a workflow change, not just a syntax change. If your backup procedures rely on storage snapshots without BEGIN/END BACKUP framing, you need to redesign that procedure before going to 26ai.

RMAN Backup Encryption: AES256 XTS is the New Default

This is the change that will most affect organizations migrating from 19c to 26ai with existing encrypted backups.

In Oracle 19c, the default RMAN backup encryption algorithm was AES128 using CBC (Cipher Block Chaining) mode. Starting with Oracle AI Database 26ai, if the COMPATIBLE initialization parameter is set to 23.0.0 or higher, RMAN is preconfigured to use AES256 (XTS) as the default encryption algorithm for new RMAN backups.

Two things changed simultaneously: the algorithm strength (128-bit to 256-bit) and the cipher operating mode (CBC to XTS). XTS (XEX-based Tweakable Block Cipher with Ciphertext Stealing) is specifically designed for disk encryption scenarios and is significantly more secure than CBC for block-level storage.

# Check your current RMAN encryption setting in 19c:
RMAN> SHOW ALL;
# Look for: CONFIGURE ENCRYPTION ALGORITHM 'AES128';
# In 26ai, with COMPATIBLE=23.0.0, the default changes:
RMAN> SHOW ALL;
# CONFIGURE ENCRYPTION ALGORITHM 'AES256' (XTS);
# You can still configure AES128 XTS if needed:
RMAN> CONFIGURE ENCRYPTION ALGORITHM 'AES128';
# But AES256 XTS is the recommended setting going forward

The critical compatibility question: can you restore 19c backups on 26ai?

Yes. Previously encrypted databases that are migrated to Oracle AI Database 26ai retain their original algorithm and mode. Your existing 19c backups with AES128 CBC encryption remain restorable on 26ai. Oracle maintains backward compatibility for decryption. New backups taken after the upgrade will use AES256 XTS by default.

This means your backup retention window is a transition period: older backup sets use AES128 CBC, newer ones use AES256 XTS. Both coexist in your RMAN catalog without any special configuration. The risk is in automated restore scripts that assume a specific encryption configuration — verify that your restore procedures work correctly against both the old and new format backup sets.

Re-Encrypting Old Backups When Moving to OCI

This is new functionality in 26ai that addresses a real operational problem. When you migrate an on-premises 19c database to OCI and want to move your existing RMAN backups to Object Storage, you might want to upgrade the encryption on those backups as part of the transfer.

Starting with Oracle AI Database 26ai, when you backup an existing backupset, you can change the encryption for the new backup based on the encryption algorithm configured in RMAN settings. The primary benefit of this feature is that when you copy your existing on-premise database backups to Oracle Cloud, you can encrypt the new backups using the latest backup encryption practices configured in RMAN settings.

# Re-encrypt an existing AES128 CFB backupset to AES256 XTS
# when copying from on-prem disk to tape or OCI
# For transparent mode backupsets (TDE wallet required):
RMAN> BACKUP BACKUPSET ALL
      DEVICE TYPE SBT
      FORMAT '%U'
      DELETE INPUT;
# The new copy will use AES256 XTS (the configured default)
# For password mode backupsets:
RMAN> SET ENCRYPTION ON IDENTIFIED BY 'old_password' ONLY;
RMAN> SET DECRYPTION IDENTIFIED BY 'old_password';
RMAN> BACKUP BACKUPSET ALL
      DEVICE TYPE SBT;
# New backup uses AES256 XTS with the same password

This is valuable for compliance scenarios where your security policy requires AES256 for all data in OCI, including backup data. Previously, you had no mechanism to upgrade backup encryption without a full database backup from scratch.

TDE Encryption Changes That Affect Backup and Recovery

The encryption changes in 26ai go deeper than just RMAN backup algorithms. Starting with Oracle AI Database 26ai, the default encryption algorithms and encryption modes have changed. The default encryption algorithm for both TDE column encryption and TDE tablespace encryption is now AES256. The previous default for TDE column encryption was AES192. For TDE tablespace encryption, the default was AES128.

Also changed: The column encryption mode is now Galois/Counter mode (GCM) instead of cipher block chaining (CBC), and in tablespace encryption, the new tweakable block ciphertext stealing (XTS) operating mode is the default. The Oracle RMAN integrity check for column encryption keys now uses SHA512 instead of SHA1.

For backup and recovery, these TDE changes have a specific implication: when you RMAN restore a 26ai database to a new host (disaster recovery scenario), the TDE wallet must support the new algorithm set. An old wallet from a 19c database that was migrated to 26ai retains its original keys — but if you create new tablespaces or new column encryptions after the upgrade, those use the new AES256 GCM/XTS defaults. Your DR restore procedure must account for both the migrated keys and the newly generated keys.

-- After upgrading from 19c to 26ai, check your encryption inventory
-- to understand which tablespaces use old vs new algorithms:
SELECT tablespace_name, encrypted, 
       encryption_algorithm
FROM dba_tablespaces
WHERE encrypted = 'YES';
-- For columns, check what's encrypted and with what algorithm:
SELECT owner, table_name, column_name, encryption_alg
FROM dba_encrypted_columns
ORDER BY owner, table_name;

Migrate your encryption to the new standards post-upgrade using key rotation:

-- Rotate TDE master key to use new algorithm (requires ADMINISTER KEY MANAGEMENT privilege)
ADMINISTER KEY MANAGEMENT SET KEY
    USING TAG 'post_26ai_upgrade'
    FORCE KEYSTORE IDENTIFIED BY "wallet_password"
    WITH BACKUP;
-- Re-key tablespace encryption to AES256 XTS
ALTER TABLESPACE users ENCRYPTION ONLINE
    ENCRYPT USING AES256;

Traditional Auditing: Gone in 26ai, Affects Backup Audit Trails

Starting with Oracle AI Database 26ai, traditional auditing is desupported

If you use traditional auditing to track RMAN backup operations — AUDIT EXECUTE ON DBMS_BACKUP_RESTORE or similar — those audit trails are gone in 26ai. You must migrate to Unified Auditing.

-- In 19c: traditional audit policy for backup operations
AUDIT EXECUTE ON SYS.DBMS_BACKUP_RESTORE;
-- In 26ai: use Unified Auditing instead
CREATE AUDIT POLICY rman_operations
    ACTIONS EXECUTE ON DBMS_BACKUP_RESTORE
    WHEN 'SYS_CONTEXT(''USERENV'',''SESSION_USER'') = ''RMAN'''
    EVALUATE PER SESSION;
AUDIT POLICY rman_operations;
-- Verify audit trail
SELECT event_timestamp, db_username, object_name, action_name
FROM unified_audit_trail
WHERE object_name = 'DBMS_BACKUP_RESTORE'
ORDER BY event_timestamp DESC;

Case-Insensitive Passwords: A Hidden Backup Risk

Starting with Oracle AI Database 26ai, case-insensitive passwords are no longer supported. Users whose passwords are case-insensitive will be unable to log in to the database after upgrading to Oracle AI Database 26ai.

This directly impacts RMAN catalog connections and any backup scripts that connect using credentials. If your RMAN catalog user or backup script credentials use case-insensitive passwords, those connections will fail after upgrading to 26ai.

-- Before upgrading: identify users with case-insensitive passwords
SELECT username, password_versions
FROM dba_users
WHERE password_versions LIKE '%10G%'  -- 10G format = case insensitive
ORDER BY username;
-- These users MUST change their passwords before upgrade to 26ai
-- Check specifically for RMAN catalog users and backup operation users

Make this part of your pre-upgrade checklist. It’s an easy check that prevents a silent backup failure post-upgrade.

AutoUpgrade: Now the Only Supported Upgrade Method

AutoUpgrade and Replay Upgrade are the only supported methods for upgrading to Oracle AI Database 26ai. All other methods, including Database Upgrade Assistant (DBUA) and the Parallel Upgrade Utility (dbupgrade or catctl.pl), are desupported.

This affects backup strategy during the upgrade itself. The recommended approach for upgrade fallback with large databases:

# Option 1: Data Guard fallback (preferred for large databases)
# Keep standby at 19c, upgrade primary, keep standby as fallback
# Option 2: RMAN backup before upgrade (for smaller databases)
RMAN> BACKUP DATABASE PLUS ARCHIVELOG
      TAG 'PRE_26AI_UPGRADE'
      FORMAT '/backup/pre_upgrade/%U';
# Record the SCN before upgrade begins
SQL> SELECT current_scn, to_char(sysdate,'YYYY-MM-DD HH24:MI:SS') 
     upgrade_start FROM v$database;
# AutoUpgrade with fallback option
java -jar autoupgrade.jar -config upgrade.cfg -mode deploy
# If upgrade fails: restore from pre-upgrade backup
RMAN> SHUTDOWN ABORT;
RMAN> STARTUP MOUNT;
RMAN> RESTORE DATABASE FROM TAG 'PRE_26AI_UPGRADE';
RMAN> RECOVER DATABASE;
RMAN> ALTER DATABASE OPEN RESETLOGS;

Your Pre-Upgrade Backup Checklist for 26ai

Before upgrading from 19c to 26ai, verify these backup-related items:

1. Remove or replace all DRA commands (LIST FAILURE, ADVISE FAILURE, REPAIR FAILURE, CHANGE FAILURE) from all scripts and runbooks
2. Update snapshot-based recovery procedures to use BEGIN/END BACKUP framing instead of RECOVER...SNAPSHOT TIME
3. Identify and remediate all case-insensitive passwords, especially RMAN catalog and backup service accounts
4. Audit existing RMAN encryption configuration — document what you have before the upgrade
5. Verify your TDE wallet is current and accessible from the new Oracle Home
6. Migrate traditional audit policies for backup operations to Unified Auditing
7. Take a full RMAN backup immediately before upgrade — tag it clearly, document the SCN
8. Verify your RMAN catalog database version (if using a catalog) is compatible with 26ai target databases
9. Test a restore from your most recent backup in a test environment before upgrading production