Database Upgrade Planning, Compatibility Parameters, Prechecks, Deprecated Features, and Validation

Learning outcomes

A team installs 26ai binaries and immediately raises COMPATIBLE because “the upgrade is finished.” A critical application regression then appears, but the one-way compatibility gate removed the clean downgrade/restore-point fallback they expected. A software upgrade, database dictionary upgrade, and COMPATIBLE feature/disk-format adoption are related but distinct lifecycle steps.

1. Upgrade software first; adopt incompatible formats later

Oracle AI Database 26ai can run an upgraded database with a lower compatible setting so you can test the new software while delaying features that would write newer on-disk structures. For direct upgrade into 26ai the supported source baseline is Oracle Database 19c or later and the source COMPATIBLE must be at least 19.0.0.

SELECT banner_fullFROM v$versionWHERE banner_full LIKE 'Oracle%';SHOW PARAMETER compatibleSELECT  version,  version_fullFROM v$instance;

2. Only supported 26ai upgrade engines

For upgrading to 26ai, Oracle documents AutoUpgrade and Replay Upgrade as the supported methods. Database Upgrade Assistant (DBUA), dbupgrade/catctl.pl, and manual upgrade-script methods are desupported for 26ai.

3. AutoUpgrade Analyze is the first executable gate

java -jar autoupgrade.jar   -config servicehub26.cfg   -mode analyze

Analyze mode runs readiness checks and generates reports without performing the database upgrade. Oracle recommends using the latest AutoUpgrade from the supported distribution/MOS rather than assuming the copy bundled in an old home is current enough.

java -jar autoupgrade.jar   -config servicehub26.cfg   -mode fixupsjava -jar autoupgrade.jar   -config servicehub26.cfg   -mode deploy

Fixups can change source state, so back up before running them. Deploy performs the actual end-to-end upgrade and includes downtime while the database is opened in upgrade mode.

4. A minimal configuration keeps COMPATIBLE unchanged

global.autoupg_log_dir=/u01/app/oracle/cfgtoollogs/autoupgradeservicehub.sid=FREEservicehub.source_home=/u01/app/oracle/product/19c/dbhome_1servicehub.target_home=/u01/app/oracle/product/26ai/dbhome_1servicehub.target_version=23servicehub.raise_compatible=no

raise_compatible defaults to N. Keep it that way until the new release has passed application, restore, performance and operational acceptance and you intentionally choose the higher feature gate.

5. Free local readiness snapshot

SELECT name,valueFROM v$parameterWHERE name IN (  'compatible',  'db_block_size',  'cluster_database')ORDER BY name;SELECT comp_id,comp_name,version,statusFROM dba_registryORDER BY comp_id;SELECT owner,object_type,COUNT(*) invalid_countFROM dba_objectsWHERE status='INVALID'GROUP BY owner,object_typeORDER BY invalid_count DESC;SELECT * FROM v$timezone_file;SELECT patch_id,patch_type,action,status,target_versionFROM dba_registry_sqlpatchORDER BY action_time DESC;

These queries are not AutoUpgrade replacements. They teach what readiness means: software components, invalid objects, time-zone files, patch level and compatibility all affect an upgrade and application behavior.

6. Deprecation/desupport review is application work

26ai changes defaults and removes/deprecates features and parameters. Review the current desupport/deprecation list, not an old certification checklist. Map each finding to an owner, remediation, test and deadline. Also re-certify JDBC/ODP.NET/Python/Node clients, ORMs, backup agents, monitoring, OS/kernel, wallets and external libraries against the target.

SELECT name,value,isdeprecated,isbasicFROM v$parameterWHERE isdeprecated='TRUE'ORDER BY name;

A parameter being deprecated is not an instruction to delete it blindly; determine the replacement/default behavior and test the application's dependency.

7. COMPATIBLE is a one-way disk-format/feature gate

For current 26ai new installations, default compatibility is in the 23.x compatibility family (current documentation describes 23.9.0 as the default for RU 23.9 and later new installs). After an upgrade from 19c/21c, the prior compatible level can remain until you raise it deliberately. Once raised, it cannot be decreased, database downgrade is no longer available, and earlier restore-point downgrade expectations are invalidated.

8. 26ai can increase COMPATIBLE dynamically—but the decision remains irreversible

Starting with 26ai RU 23.9, Oracle supports increasing compatibility within 26ai without an instance restart using a database command. The change must be issued in CDB$ROOT, cannot be performed inside a PDB, must be coordinated with standbys (standbys first), and the SPFILE/init setting must also be made persistent. Dynamic does not mean reversible.

SHOW PARAMETER compatibleSELECT  SYS_CONTEXT('USERENV','CON_NAME') AS con_name,  database_role,  open_modeFROM v$database;

This course deliberately does not execute a COMPATIBLE increase.

9. Deliberately wrong: raise compatibility immediately after first successful login

The database starts, so an operator raises COMPATIBLE before application regression testing and restore rehearsal. Two hours later the ORM/driver workload fails on a behavior change. The binary/dictionary upgrade may have been reversible using the planned fallback, but the compatibility gate is not.

CREATE TABLE sh28_upgrade_gate (  gate_name VARCHAR2(60) PRIMARY KEY,  pass_flag CHAR(1) CHECK (pass_flag IN ('Y','N')),  evidence VARCHAR2(500));INSERT INTO sh28_upgrade_gate VALUES(  'AUTOUPGRADE_ANALYZE','Y','all blocking checks resolved');INSERT INTO sh28_upgrade_gate VALUES(  'RESTORE_REHEARSAL','Y','restore and open verified');INSERT INTO sh28_upgrade_gate VALUES(  'APP_REGRESSION','N','ORM batch workload still failing');INSERT INTO sh28_upgrade_gate VALUES(  'RAISE_COMPATIBLE','N','blocked until all acceptance gates pass');COMMIT;SELECT *FROM sh28_upgrade_gateWHERE pass_flag='N';

The safe repair is to keep COMPATIBLE unchanged, fix the application regression, repeat acceptance, and only then make a separate approved feature-adoption change.

10. Post-upgrade validation is broader than INVALID=0

• AutoUpgrade postupgrade/fixup status and logs.
• Oracle component registry and invalid objects investigated/recompiled.
• Application schema object counts, grants, synonyms, jobs, services and DB links.
• Critical SQL plans and representative runtime behavior.
• Backup/recovery job success in the new home.
• Driver/ORM/session-pool behavior and TLS/wallet integrations.
• Alert log/ADR and OS resource baseline.

SELECT comp_id,status,versionFROM dba_registryORDER BY comp_id;SELECT owner,COUNT(*) invalid_objectsFROM dba_objectsWHERE status='INVALID'GROUP BY ownerORDER BY invalid_objects DESC;

11. Cleanup and production judgment

DROP TABLE sh28_upgrade_gate PURGE;

Upgrade with AutoUpgrade/Replay Upgrade, preserve fallback, and separate the irreversible COMPATIBLE decision from software installation. Review deprecations/desupports and certify application clients before production cutover. Do not adopt new features merely because the new binaries expose them.

No mandatory lab upgrades the already-26ai Free instance. The direct-upgrade minimum is 19c, and COMPATIBLE must be at least 19.0.0 before that upgrade. Lesson 3 moves into logical/transportable migration, which can upgrade and relocate data without performing an in-place database upgrade.

Authoritative references

• Oracle AI Database 26ai Upgrade Guide — current August 2026 upgrade lifecycle
• AutoUpgrade Processing Modes — analyze/fixups/deploy/upgrade
• 26ai Desupports and Deprecations — release-specific application review
• COMPATIBLE — one-way/dynamic 26ai compatibility semantics
• What Is Oracle Database Compatibility? — upgrade/default/minimum compatibility guidance