If you’ve been running Oracle Database long enough, you’ve seen deprecation notices before. Usually they’re a heads-up in the release notes, maybe a year or two to adapt. Oracle 26ai takes a more thorough approach: it’s streamlining the platform by retiring features whose functionality has been superseded by more modern, more capable alternatives. This is Oracle investing in a cleaner, more secure, and more maintainable codebase – and that’s good news for everyone who runs Oracle in production.

In a single release, Oracle is desupporting – and in many cases, consolidating the codebase – dozens of features that have been around for 15 years or more. The Data Recovery Advisor (DRA), introduced in Oracle 11g, has been retired. 3DES encryption – an optional, now-obsolete cipher that was never the default for Transparent Data Encryption – has been transitioned out in FIPS-compliant databases. DBUA, the graphical upgrade assistant most DBAs have relied on since Oracle 9i, is desupported on every platform. And the list keeps going: Traditional Auditing, EM Express, Oracle Wallet Manager, ASMFD (finally!), stored outlines(!), TLS 1.0/1.1, GOST/SEED algorithms, TDE PKI keys, the ENCRYPTION_WALLET_LOCATION parameter, and 32-bit Oracle clients.

Why is Oracle doing this now? Three main reasons:

First, NIST’s FIPS 140-3 transition. FIPS 140-2 moves to the historical list on September 21, 2026, and algorithms like 3DES, DES, RC4, MD2, and MD4 are not part of the new standard. Oracle’s Cryptographic Roadmap tracks these deadlines closely, and 26ai is the release where the rubber meets the road. The EU is moving in the same direction: ENISA guidance, the Cyber Resilience Act, NIS2, and DORA all favor modern, vetted cryptography.

Second, the operational burden of maintaining legacy code paths in the upgrade framework is real. DBUA, catctl.pl, catupgrd.sql, and dbupgrade represent four different upgrade mechanisms that Oracle’s engineering team has to maintain, test, and debug. catcon.pl – a general-purpose parallel execution utility for running scripts across CDB/PDBs – is also desupported, though it’s not an upgrade mechanism per se. Consolidating to Autoupgrade and Replay Upgrade cuts that surface area dramatically.

Third, and perhaps most importantly, Oracle’s shift toward cloud-first and AI-native operations means features like EM Express and DRA – limited to on-premises, single-instance environments – no longer fit the product roadmap.

It’s about a database that has accumulated 25 years of features, many of which have better successors, and finally drawing a line.

Under the Hood – The Big Three and the Long Tail

1. Data Recovery Advisor: Gone Without a Replacement

DRA was one of Oracle 11g’s most visible features. Its removal was announced in July 2023, giving DBAs over two years of advance notice – but if you’ve been relying on it, the deadline is here.

Before you mourn DRA, though, it’s worth remembering just how narrow its scope always was. Even at its peak, DRA was never a general-purpose recovery tool. Oracle’s own documentation constrained it to a small subset of configurations, and for the RAC + Data Guard + multitenant architectures that dominate production today, DRA was never really in the game:

• Single-instance only, no RAC. Oracle’s documentation was blunt: “Data Recovery Advisor only supports single-instance databases. Oracle RAC databases are not supported.” There was one narrow carve-out: if a failure brought down all RAC instances, you could mount the database in single-instance mode and use DRA to detect and repair control file, SYSTEM datafile, and data dictionary failures. But that approach never detected failures local to individual cluster instances – an inaccessible datafile on one node, for example, was invisible to it.

• No Data Guard recovery. In a Data Guard environment, DRA could not diagnose or repair failures on a physical standby database, and it could not use files transferred from the standby to repair the primary. The best it could offer was recommending a failover to a standby when the primary was down – after which you were on your own repairing the old primary.

• No PDB support. DRA only worked on non-CDB databases and on the root of a multitenant container database. It could not diagnose or repair failures inside pluggable databases (PDBs) at all.

In other words, the tool many DBAs remember fondly was, from day one, a single-instance, primary-only, root-only convenience for a specific class of failures. That is worth keeping in mind as you weigh the cost of replacing it.

If you’ve ever run LIST FAILURE in RMAN and gotten a structured diagnosis with repair scripts, you know the convenience it offered. In 26ai, those commands produce parser errors (example output shown below – exact codes may vary by patch level):

RMAN> LIST FAILURE;
RMAN-00558: error encountered while parsing input commands
RMAN-01009: syntax error: found "failure": expecting one of: ...

The commands affected are LIST FAILURE, ADVISE FAILURE, REPAIR FAILURE, and CHANGE FAILURE. All four have been retired. Oracle’s Upgrade Guide is explicit: there is no replacement feature.

The implicit migration path – pieced together from Oracle’s documentation on RMAN diagnostics and community testing – is to fall back on the underlying mechanisms DRA was built on top of:

-- Corruption detection (replaces LIST FAILURE)
RMAN> VALIDATE DATABASE;
-- Review corruption details
SELECT file#, block#, blocks, corruption_type, corrupt_description
FROM V$DATABASE_BLOCK_CORRUPTION
ORDER BY file#, block#;
-- Block-level repair (replaces REPAIR FAILURE for block corruption)
RMAN> BLOCKRECOVER DATAFILE 4 BLOCK 128;
-- Catalog consistency (replaces CHANGE FAILURE)
RMAN> CROSSCHECK BACKUP;
-- Media recovery (replaces REPAIR FAILURE for file-level issues)
RMAN> RESTORE DATAFILE 4;
RMAN> RECOVER DATAFILE 4;

The gap isn’t technical – it’s procedural. DRA automated the decision tree: detect, classify, advise, repair. Without it, junior DBAs need to understand the RMAN recovery workflow at a level that DRA previously abstracted away. If your team has DBAs who’ve never had to manually diagnose a media failure because DRA always handled it, this is the deprecation that will bite you first.

2. 3DES Removal: The FIPS 140-3 Deadline

This isn’t Oracle’s decision – it’s NIST’s. FIPS 140-3, the current standard, does not include 3DES as an approved algorithm. When FIPS 140-2 moves to the historical list on September 21, 2026, any organization running FIPS-compliant Oracle databases that still uses 3DES will be non-compliant.

Before we go further, a reality check that keeps the impact in perspective: 3DES was never the default for Transparent Data Encryption, and the vast majority of Oracle installations I know never used it. From the moment TDE shipped, the default for column encryption has been AES192, and the default for tablespace encryption has been AES128. 3DES was always opt-in: a DBA had to write ENCRYPT USING '3DES168' explicitly in their DDL. Oracle’s defaults have always favored AES, and most DBAs never changed them. 3DES existed primarily to satisfy legacy compatibility requirements, and any deployment still using it today made a deliberate choice at some point – one that is now an inconvenient one.

3DES is already desupported in 26ai when the database runs in FIPS 140-3 mode, and Release Update 19.32 (scheduled for 2026) will transition away from 3DES in 19c FIPS mode as well. In FIPS 140-2 mode on 19c, 3DES continues to work in CBC and ECB modes but breaks in CFB and OFB modes.

Where 3DES does appear, it touches several subsystems: Transparent Data Encryption (both column-level and tablespace-level), Native Network Encryption, the DBMS_CRYPTO package, and Oracle Wallets created before version 19.22. Oracle’s 26ai defaults shift to AES256 with stronger modes (XTS, GCM), so the migration path is clear: re-encrypt with AES256 and transition to the new wallet parameter WALLET_ROOT.

3. AutoUpgrade-Only Mandate: No More DBUA, No More Manual Scripts

This is great news for your mental health. If you’ve ever run dbua from the command line or manually executed catupgrd.sql, those paths are closed in 26ai. Oracle desupports:

• Database Upgrade Assistant (DBUA) – on all platforms, including Windows
• Manual upgrade scripts: catupgrd.sql, dbupgrade, catctl.pl
• catcon.pl – general-purpose parallel execution utility (not an upgrade mechanism, but desupported anyway)

The only supported upgrade methods are AutoUpgrade (the Java-based autoupgrade.jar) and Replay Upgrade. Replay Upgrade records the upgrade actions on a test or staging copy and replays them against the target, so the upgrade path is validated before production is touched. For mission-critical systems, pair either method with a guaranteed restore point so you can flash back in minutes if something goes wrong. See Oracle’s Replay Upgrade documentation for setup details.

These scripts are desupported in 26ai, meaning Oracle will not fix bugs or provide support if issues arise.

Here’s the three-phase AutoUpgrade workflow:

# Phase 1: Analyze - runs pre-upgrade checks and generates a report
java -jar $ORACLE_BASE/product/26.0.0/dbhome_1/rdbms/admin/autoupgrade.jar \
  -config /tmp/autoupgrade_config.txt -mode analyze
# Phase 2: Fixups - applies recommended fixes (optional but recommended)
java -jar $ORACLE_BASE/product/26.0.0/dbhome_1/rdbms/admin/autoupgrade.jar \
  -config /tmp/autoupgrade_config.txt -mode fixups
# Phase 3: Deploy - performs the actual upgrade
java -jar $ORACLE_BASE/product/26.0.0/dbhome_1/rdbms/admin/autoupgrade.jar \
  -config /tmp/autoupgrade_config.txt -mode deploy

Sample configuration file (autoupgrade_config.txt):

global.global_log_dir=/tmp/upgrade_logs
upg1.sid=cdb1
upg1.source_home=/u01/app/oracle/product/19.0.0/dbhome_1
upg1.target_home=/u01/app/oracle/product/26.0.0/dbhome_1
upg1.log_dir=/u01/app/oracle/admin/CDB1/upgrade_logs
upg1.start_time=NOW
upg1.run_utlrp=yes
upg1.timezone_upg=yes
upg1.target_version=26

Two changes inside AutoUpgrade that affect post-upgrade behavior:

First, AutoUpgrade recompiles invalid objects automatically as part of its post-upgrade steps. If any user-schema objects remain invalid afterward, run the standard recompilation script manually:

-- Post-upgrade: recompile invalid user objects
@?/rdbms/admin/utlrp.sql

Second, AutoUpgrade is designed to be scripted and automated end to end. If you manage dozens of databases, this is the upgrade story Oracle actually wants you to use.

20+ Other Desupports

Here’s what else is going away:

Traditional Auditing -> Unified Auditing is mandatory

Traditional auditing – the AUDIT statement plus parameter-driven configuration scattered across AUDIT_TRAIL, AUDIT_SYS_OPERATIONS, and AUDIT_FILE_DEST – is gone in 26ai. Unified Auditing is now the only option, and the two are fundamentally different models:

• Where policy lives. Traditional auditing configured much of its behavior through instance parameters and a set of individual AUDIT statements. Unified Auditing is policy-based: you create a named audit policy that bundles together the actions to track, the objects they apply to, and the conditions under which they fire.

• Where records go. Traditional auditing wrote to one of a few destinations (DB, OS, XML) selected by a single AUDIT_TRAIL parameter. Unified Auditing routes everything into a single unified audit trail, which captures richer context – session metadata, application context, SQL text and bind values – and is queried through one UNIFIED_AUDIT_TRAIL view instead of several fragmented ones.

• Granularity. Traditional auditing had a fixed set of statement, privilege, and object clauses. Unified Auditing lets you combine multiple action types in a single policy and scope them with WHEN conditions, so one policy can express rules that would have required many separate traditional statements.

The practical implication is not just a syntax change – it’s a migration. Every traditional audit rule has to be re-expressed as a unified audit policy before you upgrade, because the old statements simply stop working. If you already adopted Unified Auditing (Oracle’s recommended path for years), you’re ahead of the game. If you haven’t, plan a mapping exercise: inventory your current AUDIT statements and parameters, translate each one into a CREATE AUDIT POLICY definition, and verify the unified audit trail captures what you expect before go-live. One caveat worth noting: unified audit records are written to the SYSAUX tablespace, so busy environments should size and monitor it accordingly.

EM Express – Desupported

If you’ve been using EM Express (https://host:5500/em) for lightweight database monitoring, it’s gone. Alternatives: Oracle Enterprise Manager Cloud Control, SQL Developer Web, or OCI Database Management.

Oracle Wallet Manager (OWM) -> orapki CLI

The GUI-based Oracle Wallet Manager is desupported. All wallet operations must use orapki:

# Create wallet with auto-login
orapki wallet create -wallet /u01/app/oracle/admin/CDB1/wallet -auto_login
# Add certificate
orapki wallet add -wallet /u01/app/oracle/admin/CDB1/wallet \
    -dn "CN=mydb.example.com" -keysize 2048
# Display wallet contents
orapki wallet display -wallet /u01/app/oracle/admin/CDB1/wallet

ENCRYPTION_WALLET_LOCATION -> WALLET_ROOT

The old sqlnet.ora parameter is desupported. Use WALLET_ROOT instead:

ALTER SYSTEM SET WALLET_ROOT = '/u01/app/oracle/admin/CDB1/wallet' SCOPE=SPFILE;
-- Restart the database for WALLET_ROOT to take effect

If TDE is enabled and WALLET_ROOT is not set, the upgrade is blocked.

TLS 1.0 and TLS 1.1 – Desupported

Use TLS 1.2 or TLS 1.3.

RECOVER...SNAPSHOT TIME – Desupported

-- OLD (desupported in 26ai):
RMAN> RECOVER DATABASE UNTIL TIME "TO_DATE('2026-08-01','YYYY-MM-DD')" SNAPSHOT TIME "TO_DATE('2026-08-01','YYYY-MM-DD')";
-- NEW (26ai workflow for snapshot-based recovery):
SQL> ALTER DATABASE BEGIN BACKUP;
-- Take storage snapshot here (outside RMAN)
SQL> ALTER DATABASE END BACKUP;
SQL> SELECT current_scn FROM v$database;
RMAN> RECOVER DATABASE UNTIL SCN <scn_after_end_backup>;

Community testing confirms the parser still accepts RECOVER...SNAPSHOT TIME in 26ai – it doesn’t throw an error – but the functionality is desupported, meaning bugs won’t be fixed and it may be removed in future releases. Don’t rely on it.

ASMFD (Oracle ASM Filter Driver) – Desupported on Linux and Solaris

Migrate to ASMlib v3 on Linux kernel 5.14+. ASMlib was always solid. If you’re running ASMFD, the migration involves re-discovering disks through the ASMlib driver:

# Scan disks with ASMlib
/usr/sbin/oracleasm scandisks
/usr/sbin/oracleasm listdisks
# Verify ASM visibility
sqlplus / as sysasm
SQL> SELECT name, path, mount_status, header_status FROM v$asm_disk;

GOST and SEED TDE algorithms – Desupported

The encryption libraries have been transitioned out. If you have data encrypted with GOST or SEED, you must re-encrypt before upgrading. Note: on HP Itanium, the libraries are still present but deprecated.

TDE PKI keys – Desupported

The upgrade script actively blocks if PKI-based TDE keys are detected. You must rekey to standard TDE keys before proceeding.

Stored Outlines – Terminal Release

26ai is the last release that supports stored outlines!!! Migrate to SQL Plan Baselines:

-- Migrate stored outlines to SQL Plan Baselines (all outlines)
SET SERVEROUTPUT ON
DECLARE
  v_report CLOB;
BEGIN
  v_report := DBMS_SPM.MIGRATE_STORED_OUTLINE(attribute_name => 'all', attribute_value => NULL);
  DBMS_OUTPUT.PUT_LINE(SUBSTR(v_report, 1, 4000));
END;
/
-- Verify conversion
SELECT sql_handle, plan_name, enabled, accepted, origin
FROM dba_sql_plan_baselines
WHERE origin = 'STORED-OUTLINE'
ORDER BY created;

32-bit Oracle Clients – Desupported

They can still connect to 26ai, but Oracle won’t provide support. If you have legacy 32-bit applications, plan the migration.

Transition Timelines

Wrapping up

Oracle 26ai represents the most significant platform cleanup in Oracle Database history. Here is what each area means for your organization:

Recovery tooling. The Data Recovery Advisor, a guided repair assistant introduced over a decade ago, has been retired with no direct replacement. Teams that relied on its automated diagnosis will need to re-establish hands-on recovery procedures using Oracle’s underlying backup and recovery engine, which remains fully supported and unchanged.

Encryption. Older encryption standards are being phased out to keep pace with the industry-wide FIPS 140-3 transition. FIPS 140-2 moves to the historical list on September 21, 2026, and 3DES is not part of the new standard; the EU’s ENISA guidance, the Cyber Resilience Act, NIS2, and DORA push in the same direction. The impact reaches beyond encryption-at-rest into network encryption and legacy credential stores. Oracle’s defaults now favor AES256 with stronger, more modern modes.

Upgrade tooling. Oracle is consolidating multiple upgrade paths into a single, modernized set of tools, simplifying both the product and the operational process. The new approach is built for automation at scale.

A broad cleanup. More than twenty additional legacy capabilities are being retired, including older auditing mechanisms (now unified under a single, stronger framework), lightweight monitoring tools, and legacy client support. Each has a modern, more capable successor already available.

The bottom line: Oracle 26ai is streamlining the platform by retiring legacy features whose functionality has been superseded by more modern, more capable alternatives. This is Oracle investing in a cleaner, more secure, and more maintainable codebase. The changes are driven by three converging forces: the industry-wide FIPS 140-3 cryptographic transition, the operational burden of maintaining multiple upgrade mechanisms, and Oracle’s shift toward cloud-first and AI-native operations.