Release Update Patching, OPatch/Datapatch Concepts, Fleet Consistency, and Rollback Planning

Learning outcomes

A DBA updates an Oracle Home and restarts successfully, so the change ticket is closed. Days later one PDB still has old SQL patch state because it was closed when datapatch ran. Another node has a different one-off inventory. The lesson begins from the mechanism: a Release Update can change Oracle Home binaries and can also contain database SQL actions; both states must converge.

1. RU, Oracle Home, and SQL patch state are different facts

Release Updates (RUs) are Oracle's quarterly maintenance train for 26ai. The current chapter reference is RU 23.26.3, July 2026. An Oracle Home is the software directory containing database executables/libraries. OPatch inventory describes binary patches in that home; DBA_REGISTRY_SQLPATCH describes SQL patch actions that datapatch applied inside a database.

SELECT banner_fullFROM v$versionWHERE banner_full LIKE 'Oracle%';SELECT  instance_name,  version,  version_fullFROM v$instance;

Version output tells you which binaries the running instance reports; it does not prove every patch SQL action succeeded in every PDB.

2. Oracle's 26ai patching direction is Gold Image out-of-place

For single-instance on-premises databases Oracle recommends out-of-place Gold Image RUs deployed with Database Configuration Assistant (DBCA). For advanced RAC/Data Guard/fleet topologies Oracle recommends out-of-place Gold Images with Fleet Patching and Provisioning (FPP). OPatch and OPatchAuto remain available for in-place maintenance; their use for out-of-place patching is deprecated.

3. Inventory the Oracle Home

export ORACLE_HOME=/opt/oracle/product/23ai/dbhomeFree"$ORACLE_HOME/OPatch/opatch" lsinventory

Record Oracle Home path, platform, RU/one-off patch IDs and OPatch version. On a fleet, collect the same evidence from every home/node; do not assume shared automation means identical inventory.

SET LONG 200000SELECT DBMS_QOPATCH.GET_OPATCH_LSINVENTORY()FROM dual;

DBMS_QOPATCH exposes the Oracle Home inventory from SQL. It does not replace OS-level inventory/readme checks, but it lets database-side validation correlate binary and SQL state.

4. Inventory SQL patch state in the database

SELECT  install_id,  patch_id,  patch_type,  action,  status,  action_time,  source_version,  target_version,  logfileFROM dba_registry_sqlpatchORDER BY action_time DESC, patch_id;

STATUS='SUCCESS' on the latest APPLY is the relevant registry evidence for that database. A row with WITH ERRORS, a missing expected RU action, or a stale PDB means binary patch success alone is not enough.

5. Datapatch is the post-binary SQL phase

For supported patched databases, open the CDB/PDBs that must receive SQL changes and run datapatch from the target Oracle Home. Oracle highly recommends its sanity checks first.

sqlplus / as sysdba <<'SQL'startup;alter pluggable database all open;exitSQLcd "$ORACLE_HOME/OPatch"./datapatch -sanity_checks./datapatch -verbose

Datapatch updates DBA_REGISTRY_SQLPATCH. Only the CDB and open PDBs are processed; a closed PDB must be opened and datapatch run later. The log path from datapatch is part of the change evidence.

6. Deliberately incomplete patch: binaries new, PDB SQL state old

Because Free cannot receive a supported RU, model the failure without modifying its Oracle Home.

BEGIN EXECUTE IMMEDIATE 'DROP TABLE sh28_patch_manifest PURGE';EXCEPTION WHEN OTHERS THEN IF SQLCODE != -942 THEN RAISE; END IF; END;/CREATE TABLE sh28_patch_manifest (  component_scope VARCHAR2(40) PRIMARY KEY,  home_or_pdb     VARCHAR2(80) NOT NULL,  binary_ru       VARCHAR2(20),  sql_ru          VARCHAR2(20),  status_code     VARCHAR2(20) NOT NULL);INSERT INTO sh28_patch_manifestVALUES('HOME_1','/u01/app/oracle/product/26ai/dbhome_1',       '23.26.3',NULL,'BINARY_READY');INSERT INTO sh28_patch_manifestVALUES('CDB_ROOT','FREE:CDB$ROOT',       '23.26.3','23.26.3','CONSISTENT');INSERT INTO sh28_patch_manifestVALUES('APP_PDB','FREE:FREEPDB1',       '23.26.3','23.26.2','MISMATCH');COMMIT;SELECT *FROM sh28_patch_manifestWHERE NVL(binary_ru,'?') <> NVL(sql_ru,binary_ru)   OR status_code <> 'CONSISTENT';

The APP_PDB row is the modeled failure: the home is at 23.26.3 while that PDB's SQL layer is not. Production repair is to open the missing PDB in the patched home, run datapatch according to the RU procedure, inspect logs, and confirm a SUCCESS registry entry—not to update a tracking table.

7. Patch acceptance is a fleet gate

Declare a home/database patch complete only after all of these align:

• Every intended Oracle Home has the approved RU/one-offs and correct OPatch inventory.
• Every intended CDB/PDB has successful SQL patch state.
• Services/listeners return from the intended new home.
• Invalid Oracle-owned/application objects are investigated, not ignored.
• Application smoke tests, critical plans, backups and alert/ADR review pass.

SELECT con_id,name,open_modeFROM v$pdbsORDER BY con_id;SELECT owner,object_type,COUNT(*) invalid_objectsFROM cdb_objectsWHERE status='INVALID'GROUP BY owner,object_typeORDER BY invalid_objects DESC;

8. Rollback is not one command

Out-of-place patching makes software rollback easier because the prior Oracle Home can be retained, but database SQL actions, one-offs, application behavior and data changes still require a tested plan. Before maintenance preserve:

• RMAN backup/restore validation and control/SPFILE backups.
• Old Oracle Home and exact inventory.
• Listener/network config, wallets/keystores and external library/config inventory.
• RU README rollback prerequisites and one-off conflict plan.
• Application rollback binaries and service/pool drain plan.

Never promise that switching ORACLE_HOME alone reverses every patch effect.

9. Rollback decision points

CREATE TABLE sh28_patch_gate (  gate_name VARCHAR2(60) PRIMARY KEY,  pass_flag CHAR(1) CHECK (pass_flag IN ('Y','N')),  evidence VARCHAR2(500));INSERT INTO sh28_patch_gate VALUES(  'BINARY_INVENTORY_MATCH','Y','opatch inventory captured');INSERT INTO sh28_patch_gate VALUES(  'SQLPATCH_ALL_PDBS','N','FREEPDB1 simulated old SQL RU');INSERT INTO sh28_patch_gate VALUES(  'APPLICATION_SMOKE','Y','read-only smoke test passed');COMMIT;SELECT *FROM sh28_patch_gateWHERE pass_flag='N';

A failed gate prevents promotion. Production rollback thresholds should be written before the outage, not negotiated after symptoms appear.

10. Cleanup and production judgment

DROP TABLE sh28_patch_gate PURGE;DROP TABLE sh28_patch_manifest PURGE;

Patch by evidence: home inventory + SQL patch registry + service/PDB/app validation. Prefer current Gold Image out-of-place guidance; use OPatch/OPatchAuto in-place only where the exact supported procedure calls for them. Free cannot be maintained with supported RUs, so do not treat it as a production patching target.

RU 23.26.3 is the current chapter reference. Patching does not automatically mean raising COMPATIBLE. Lesson 2 separates software release upgrade from that compatibility gate and from feature adoption.

Authoritative references

• Oracle AI Database 26ai Patching — Gold Image/out-of-place recommendations
• Single-Instance Maintenance with OPatch — datapatch sanity/verbose workflow
• DBA_REGISTRY_SQLPATCH — database SQL patch evidence
• DBMS_QOPATCH — database-side Oracle Home inventory
• Release Update Patches — RU formats and Free patching restriction