Oracle 26ai came out. I deployed it, went to run my RMAN workflows, and immediately noticed things had changed. After an hour of reading through the 26ai Backup and Recovery documentation and testing against a live instance I found enough worth writing down.

This post is part change log, part lab journal for what’s different in RMAN on 26ai. Here’s the short version:

Encryption defaults moved from AES128 CFB to AES256 XTS, but the instance metadata doesn’t quite agree with the documentation
You can now re-encrypt existing backups without restoring them
SBT libraries ship inside Oracle Home, and BACKUP BACKUPSET can move backups between device types
Data Recovery Advisor is gone, no replacement
RECOVER…SNAPSHOT TIME is documented as de-supported but the parser still accepts it

Read on if you dare.

Contents hide

1 Encryption defaults

2 Re-encrypting backups on copy

3 Backup mobility

4 Recovery catalog

5 Removed features

6 Database incarnations

Encryption defaults

RMAN’s default encryption algorithm is now AES256 in XTS block cipher mode, up from AES128 in CFB mode. XTS was designed for encrypting data at rest. CFB was designed for streaming data. The key size doubles.

The default activates when COMPATIBLE is set to 23.0.0 or higher. No configuration needed.

RMAN> SHOW ENCRYPTION ALGORITHM;

CONFIGURE ENCRYPTION ALGORITHM 'AES256'; # default

That output is from a fresh 26ai install, lets call it bench-01. AES256 with no mode qualifier. You’d expect it to be XTS based on the documentation, but RMAN doesn’t tell you which mode it’s actually using. So I checked the view that does.

SELECT ALGORITHM_ID, ALGORITHM_NAME, ALGORITHM_DESCRIPTION,
       IS_DEFAULT, IS_RECOMMENDED
FROM V$RMAN_ENCRYPTION_ALGORITHMS;

ALGORITHM_ID  ALGORITHM_NAME  ALGORITHM_DESCRIPTION        IS_DEFAULT  IS_RECOMMENDED
------------  --------------  ---------------------------  ----------  --------------
           1  AES128          AES 128-bit key CFB mode     NO          NO
           2  AES192          AES 192-bit key CFB mode     NO          NO
           3  AES256          AES 256-bit key CFB mode     YES         NO
           4  AES128          AES 128-bit key XTS mode     NO          NO
           6  AES256          AES 256-bit key XTS mode     NO          YES

ALGORITHM_ID 3 (AES256 CFB) shows IS_DEFAULT=YES. ALGORITHM_ID 6 (AES256 XTS) shows IS_RECOMMENDED=YES. The documentation says XTS is the default. The view says CFB is the default and XTS is merely recommended.

Whether CONFIGURE ENCRYPTION ALGORITHM 'AES256' internally maps to XTS when COMPATIBLE >= 23.0.0 is unclear. Oracle may have updated the runtime behaviour without updating the view metadata, or the view may be accurate and the documentation wrong. Run the query on your instance. If IS_DEFAULT=YES sits on ALGORITHM_ID 6, they’ve fixed it. If it’s on 3, you have the same discrepancy I found. V$BACKUP_PIECE has an ENCRYPTED column but doesn’t expose which algorithm was used, so there’s no way to verify the actual cipher from the backup metadata alone.

ALGORITHM_ID 5 is missing from the output. That’s not a bug. AES192 is not supported in XTS mode. The XTS specification only defines 128-bit and 256-bit keys, so Oracle skipped the ID.

Note: the pre-26ai default is documented inconsistently. The CONFIGURE command reference says AES128 CFB. The Backup Concepts guide implies AES256 CFB. Verifying this requires a pre-26ai instance, which I don’t have in this lab.

Re-encrypting backups on copy

Before 26ai, changing a backup’s encryption meant restoring it and backing it up again. 26ai adds BACKUP BACKUPSET with re-encryption support, which encrypts during a copy operation. The original stays untouched.

I tested this on bench-01 with an unencrypted tablespace backup.

-- Create an unencrypted backup
BACKUP TABLESPACE USERS TAG 'UNENCRYPTED_FOR_REENC'
  FORMAT '/tmp/rman_reenc_src_%U';

-- Verify it's unencrypted
SELECT BS_KEY, ENCRYPTED FROM V$BACKUP_PIECE
WHERE TAG='UNENCRYPTED_FOR_REENC';

BS_KEY  ENCRYPTED
------  ---------
    22  NO

-- Re-encrypt using password mode
SET ENCRYPTION ON IDENTIFIED BY "TestPass123" ONLY;
BACKUP BACKUPSET 22 FORMAT '/tmp/rman_reenc_dst_%U'
  TAG 'REENCRYPTED_TEST';

-- Verify the copy is encrypted
SELECT BS_KEY, ENCRYPTED FROM V$BACKUP_PIECE
WHERE TAG='REENCRYPTED_TEST';

BS_KEY  ENCRYPTED
------  ---------
    23  YES

BS_KEY 22 is still ENCRYPTED=NO. BS_KEY 23 is ENCRYPTED=YES. RMAN copies the blocks and applies encryption to the output. The data is never decrypted during the operation.

For transparent mode (which uses the TDE keystore instead of a password):

SET ENCRYPTION ON FOR BACKUP BACKUPSET;
BACKUP DEVICE TYPE sbt BACKUPSET ALL DELETE INPUT;

That re-encrypts everything during a copy to tape and deletes the disk originals. Transparent mode requires an open keystore with a master key configured. If the keystore is open but the master key isn’t set, you get ORA-19914 then ORA-28361. I hit this on bench-01 when V$ENCRYPTION_WALLET showed STATUS=OPEN_NO_MASTER_KEY. Password mode (IDENTIFIED BY "password" ONLY) works without a keystore entirely, which is how I ran the test above.

When COMPATIBLE >= 23.0.0, re-encryption converts from CFB to XTS. Below 23.0.0, it stays within CFB. The mode upgrade follows the COMPATIBLE parameter automatically.

Backup mobility

Two related changes make it easier to move backups around.

First, Oracle Home now ships with SBT libraries for four backup destinations. No separate downloads, no version compatibility hunting.

Alias	Target	Library
oracle.oci	OCI Object Storage	libosbws.so
oracle.zdlra	Zero Data Loss Recovery Appliance	(bundled)
oracle.osbws	Amazon S3	libosbws.so
oracle.azure	Azure Blob Storage	libaz.so

Available from Release Update 23.8 onward. On bench-01, SHOW ALL had SBT_TAPE pre-configured with oracle.oci at parallelism 8 out of the box. Anyone who’s spent time matching SBT library versions to Oracle homes will appreciate this. Mismatched versions caused backup failures that were annoying to diagnose because the error messages pointed at the wrong thing.

Second, BACKUP BACKUPSET can now read from one device type and write to another using the INPUT DEVICE PARMS clause. OCI Object Storage to local disk:

RUN {
  ALLOCATE CHANNEL t1 DEVICE TYPE DISK
    INPUT DEVICE PARMS = 'SBT_LIBRARY=oracle.oci';
  BACKUP BACKUPSET ALL;
}

OCI Object Storage to ZDLRA:

RUN {
  ALLOCATE CHANNEL t1 DEVICE TYPE sbt
    PARMS = 'SBT_LIBRARY=oracle.zdlra'
    INPUT DEVICE PARMS = 'SBT_LIBRARY=oracle.oci';
  BACKUP BACKUPSET ALL;
}

Pair this with re-encryption and you migrate storage target and upgrade encryption in one pass. Read from old OCI backups in CFB, write to ZDLRA in XTS with a new password.

Recovery catalog

Four changes to catalog operations. I didn’t test these in the lab, but they address real operational pain points.

Standby registration without a primary. REGISTER DATABASE now works when connected to a physical standby as TARGET. RMAN resynchronizes using the standby control file. For Data Guard setups where the primary is in a different network zone, this removes a dependency that was mostly just irritating.

Resync savepoints. A failure at minute 19 of a 20-minute catalog resync used to roll back the entire transaction. Now it rolls back to the nearest savepoint. The improvement is proportional to how large your catalog is.

Auto-disconnect during backup. RMAN disconnects from the catalog before backup operations begin, reducing lock contention on the catalog schema. Matters when you’re running many concurrent RMAN jobs against a shared catalog.

TERMINATE command. TERMINATE BLOCKING CONNECTED USERS and TERMINATE WAITING CONNECTED USERS forcibly close catalog schema connections during upgrades. Requires SET CATALOG MAINTENANCE ON first. Previously you had to find and kill those sessions yourself.

Removed features

Data Recovery Advisor. LIST FAILURE, ADVISE FAILURE, REPAIR FAILURE, CHANGE FAILURE. All four commands are desupported. No replacement. If you have monitoring scripts or runbooks that call these, they’ll break on 26ai. Oracle’s desupport page doesn’t suggest an alternative.

RECOVER…SNAPSHOT TIME. Deprecated in 19c, documented as desupported in 26ai. But I tested the syntax on bench-02 and it was accepted without a desupport error:

RMAN> RECOVER DATABASE UNTIL TIME "TO_DATE('2026-04-03 15:00:00',
        'YYYY-MM-DD HH24:MI:SS')"
      SNAPSHOT TIME "TO_DATE('2026-04-03 14:30:00',
        'YYYY-MM-DD HH24:MI:SS')";

RMAN-20207: UNTIL TIME or RECOVERY WINDOW is before RESETLOGS time

RMAN-20207 is a logical error (the specified times fell before the incarnation’s RESETLOGS boundary from the incomplete recovery test I describe below). It is not a desupport error. The parser accepted SNAPSHOT TIME without complaint.

I couldn’t test with a valid time window because bench-02 had just been reset. It’s possible that a desupport error only fires when the syntax would otherwise succeed. It’s also possible that Oracle documented the desupport before enforcing it and 23.26.1 is in a transition state. Either way, if your backup process uses SNAPSHOT TIME for third-party storage snapshots, plan the migration now. The replacement pattern uses BEGIN/END BACKUP:

ALTER DATABASE BEGIN BACKUP;
-- Take your storage snapshot
ALTER DATABASE END BACKUP;
-- Back up archived redo logs separately
RECOVER DATABASE UNTIL TIME 'timestamp';

RMAN’s own backups never needed SNAPSHOT TIME. It handles fractured blocks internally. This clause was specifically for recovery from third-party storage snapshots. The syntax works today. Relying on it going forward is a risk.

Database incarnations

Incarnations aren’t new to 26ai. They’ve been part of RMAN since Oracle 8, when RMAN itself was introduced. Every time you open a database with ALTER DATABASE OPEN RESETLOGS, Oracle creates a new incarnation to disambiguate redo streams that would otherwise share the same SCN range. The previous incarnation becomes PARENT, the new one becomes CURRENT.

This was my first real encounter with them, and incarnations got me excited. The SNAPSHOT TIME test above happened on bench-02 right after an incomplete recovery and RESETLOGS, so I had the perfect opportunity to walk through the full incarnation lifecycle.

Before doing anything, bench-02 had a single incarnation from its initial creation:

SELECT INCARNATION#, RESETLOGS_CHANGE#, RESETLOGS_TIME, STATUS
FROM V$DATABASE_INCARNATION ORDER BY INCARNATION#;

INCARNATION#  RESETLOGS_CHANGE#  RESETLOGS_TIME  STATUS
------------  -----------------  --------------  -------
           1                  1  07-FEB-26       CURRENT

I took a full backup with archived logs, then performed an incomplete recovery to a specific SCN:

-- Full backup
RMAN> BACKUP DATABASE FORMAT '/tmp/rman_bench02_pre_%U'
        TAG 'PRE_RESETLOGS';
RMAN> BACKUP ARCHIVELOG ALL FORMAT '/tmp/rman_bench02_arch_%U';

-- Incomplete recovery
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
RMAN> RUN {
  SET UNTIL SCN 122348500;
  RESTORE DATABASE;
  RECOVER DATABASE;
}

Recovery took about 7 minutes (bench-02 has a large TPC-C datafile). Then the RESETLOGS:

ALTER DATABASE OPEN RESETLOGS;

Now the incarnation view shows the fork:

SELECT INCARNATION#, RESETLOGS_CHANGE#, RESETLOGS_TIME, STATUS
FROM V$DATABASE_INCARNATION ORDER BY INCARNATION#;

INCARNATION#  RESETLOGS_CHANGE#  RESETLOGS_TIME  STATUS
------------  -----------------  --------------  -------
           1                  1  07-FEB-26       PARENT
           2          122348501  03-APR-26       CURRENT

RMAN’s LIST INCARNATION gives the same information with DB Key and Inc Key columns for catalog reference:

RMAN> LIST INCARNATION OF DATABASE;

DB Key  Inc Key  DB Name   DB ID        STATUS   Reset SCN    Reset Time
------  -------  --------  -----------  -------  -----------  ----------
     1        1  ORCLCDB   2995684945   PARENT   1            07-FEB-26
     2        2  ORCLCDB   2995684945   CURRENT  122348501    03-APR-26

To recover to a point before the RESETLOGS (into a previous incarnation’s timeline), you need RESET DATABASE TO INCARNATION. It requires MOUNT mode. I tried it with the database OPEN and got ORA-19910:

RMAN> RESET DATABASE TO INCARNATION 1;

RMAN-00571: ===========================================================
ORA-19910: cannot change recovery target incarnation in control file

Mounted, it works. RMAN can then restore and recover using backups from the previous incarnation, provided the archived logs from the backup through the RESETLOGS SCN are available.

The ability to recover transparently across incarnation boundaries is one of those things that seems like it should be complicated but just works.