Oracle EBS 12.2.10 October 2026 CPU on a TEST Environment: Online Patching, FMW/WLS Overlays and DB RU 19.33, Step by Step

Alhamdulillah, the October 2026 CPU cycle on our TEST Oracle E-Business Suite 12.2.10 environment is complete, apart from the Java updates listed at the end. This post records the steps in the order they were run, the commands, and what the checkers reported, including the one that is not clean. It is a record of one cycle on one environment, not a universal procedure. Always follow the README of each patch and the current CPU note (KA923) for your own system.

What this post covers

• Ten EBS patches applied online with adop (prepare, apply, finalize, cutover)
• Fusion Middleware and WebLogic patches applied on the patch file system during the same adop session
• Database tier: combo patch 40121635 (RU 19.33 plus OJVM) with OPatch and datapatch in a single-instance CDB
• AutoConfig on both tiers, checker validation (ETCC, ECPUC, EJCPUC) and fs_clone
• What was not done and what is left as follow-up

Environment and baseline

Item	Value
Environment	TEST (non-production), Linux, one application node and one database node
EBS	12.2.10, AD/TXK C.Delta.17, run and patch file systems (fs1/fs2) plus fs_ne
Database	Oracle Database 19c, single-instance CDB with one PDB, in NOARCHIVELOG mode
DB baseline before the cycle	RU 19.32 with OJVM patch 39222882 (datapatch rolled that OJVM patch back and applied the new one)
Target	October 2026 CPU: DB RU 19.33, EBS CPU level 2026.10

What was applied

Tier	Patches
EBS (one adop session, 10 patches)	40022426, 40118871, 40119100, 40132913, 40133533, 40119303, 40035952, 40012730, 39399187, 39815908
FMW Web Tier home	39966770 (applied with napply), 32287205, 34067016
FMW Oracle Common home	39966770 (applied with napply), 39959053, 40090834
WebLogic (BSU)	PG6B was already in place as the baseline and was only verified; overlays KP5S and 4HID were applied this cycle on top of it
Database (combo 40121635)	RU 39915792 and OJVM 39803650

Not applied in this cycle: Forms patch 29949547 (ETCC marks it as needed only when connecting to Oracle Database 23ai), the database JDK patch 39902051, and the app-tier JDK 7 update. These are listed as follow-ups at the end.

Timeline

Phase	Duration
adop fs_clone (before prepare)	56 min
adop prepare	6 min
adop apply (all patches, plus FMW/WLS work in the same phase)	about 21.5 hours
adop finalize	7 min
adop cutover (mtrestart=no)	12 min
DB: OPatch RU and OJVM, then datapatch	datapatch 14 min
adop fs_clone (after the cycle)	57 min

Step 1: Pre-checks and backups

Before you start: read the current CPU note (KA923) and the README of every patch, including its prerequisites and known-issue notes. Confirm the OPatch version each README requires, agree the downtime window, and define and verify a recovery plan before starting.

Run the checkers before you change anything and keep the output: ETCC on the application tier and the database tier, and ECPUC as APPS. Take an invalid-object baseline in the PDB so you can compare afterwards.

SQL> alter session set container=<PDB_NAME>;
SQL> col owner for a20
SQL> col object_type for a25
SQL> select rpad(nvl(owner,'-'),20) owner, rpad(nvl(object_type,'-'),25) object_type, count(*) cnt
     from dba_objects where status='INVALID'
     group by owner, object_type order by 1,2;

Back up the database home, oraInventory and FMW_Home. Run long tar jobs under nohup or screen so a dropped session does not kill them:

$ cd <DB_BASE>
$ nohup tar -cvzf /backup/db_home_<date>.tar.gz 19.1.0 &
$ nohup tar -cvzf /backup/oraInventory_<date>.tar.gz <oraInventory> &
$ nohup tar -cvzf /backup/fmw_home_<date>.tar.gz $FMW_HOME &

Because this test database runs in NOARCHIVELOG mode, a home tarball does not protect the data files, and there is no archived redo to roll forward from. The only backup I took in this cycle was the set of home and inventory tarballs above. A consistent cold backup of the database files, or another recovery method supported in your environment, and a restore test were not part of this cycle, so I cannot say how long a restore would take or whether it would work. Confirm the exact backup method against your own DBA procedures, and plan the backup and the restore test before you start. Also copy the network admin directories and context files on both tiers before AutoConfig runs later.

Step 2: adgrants.sql

Caution: adgrants.sql must run inside the PDB, not in CDB$ROOT, and the copy on the database home must be the highest version available. Follow the instructions in the EBS patch README that calls for it.

Compare the version of adgrants.sql under APPL_TOP/admin, in the patch directory, and under the database home. Use the highest version, copy it to the database home, and run it inside the PDB.

$ adident Header $APPL_TOP/admin/adgrants.sql
$ strings -a $ORACLE_HOME/appsutil/admin/adgrants.sql | grep -i header
SQL> alter session set container=<PDB_NAME>;
SQL> @$ORACLE_HOME/appsutil/admin/adgrants.sql APPS

In this cycle the application-tier and database-tier copies were already the same version, so no copy was needed. If EBS_SYSTEM is locked, unlock it and reset its password before adop asks for it.

Step 3: fs_clone, prepare and apply

Caution: start from the run edition (echo $FILE_EDITION should print run), confirm adop -status shows no open session, and run the long phases in screen. The apply phase took about 21.5 hours here. Each patch must be unzipped so the driver file sits directly under the patch directory.

$ . <EBS_BASE>/EBSapps.env run
$ adop -status
$ time adop phase=fs_clone        # run in screen, about 56 min; confirm COMPLETED with adop -status
$ time adop phase=prepare
$ time adop phase=apply patches=40022426
$ time adop phase=apply patches=40118871
  ... one patch per command, in the order listed above ...
$ time adop phase=apply patches=39815908

Check after each patch with adop -status and adopscanlog -latest=yes. If adop reports that a patch is not found under PATCH_TOP, the driver file is usually one directory too deep. Move the contents up so the driver sits directly under the patch directory.

Step 4: FMW and WebLogic patches on the patch file system

Caution: edition and home selection. These patches go to the patch file system while the adop session is open. Source the patch environment, then echo ORACLE_HOME before every opatch call and confirm it points at the home you mean (webtier or oracle_common). Read KA988 and the footnotes for each patch, since some have special instructions.

$ . <EBS_BASE>/EBSapps.env patch
$ echo $FILE_EDITION                                  # patch
$ ps -efww | grep <patch FMW_Home> | grep -v grep     # must be empty
$ BUNDLE=<stage>/FMW_CPU_OCT26/39953619/etcc-bundle/LINUX_X86-64    # consolidated bundle, unzipped
$ STAGE=<stage>/fmw_unzipped                           # one directory per patch, unzipped here

# ---- Web Tier (OPatch 11.1.0.12.9) ----
$ cd $FMW_HOME; . ./SetWebtier.env; echo $ORACLE_HOME     # .../webtier
$ WT=$FMW_HOME/webtier

# 39966770 (RDA)
$ unzip -q $BUNDLE/webtier/11.1.1.9.0/p39966770_111190_Generic.zip -d $STAGE/web
$ cd $STAGE/web/39966770
$ $WT/OPatch/opatch napply -oh $WT

# 32287205 (prerequisite for 34067016; OPatch rolled back 31304503 automatically)
$ cd $STAGE/web/32287205
$ $WT/OPatch/opatch apply -oh $WT
$ $WT/OPatch/opatch lspatches -oh $WT | grep -E '32287205|31304503'

# 34067016
$ cd $STAGE/web/34067016
$ $WT/OPatch/opatch apply -oh $WT -jre $WT/jdk/jre    # answer y at the OCM "remain uninformed" prompt
$ $WT/OPatch/opatch lspatches -oh $WT | grep -E '34067016|32287205'

# ---- Oracle Common ----
$ cd $FMW_HOME; . ./SetOracleCommon.env; echo $ORACLE_HOME  # .../oracle_common
$ export PATH=$ORACLE_HOME/OPatch:$PATH

# 39966770 (RDA)
$ unzip -q $BUNDLE/oracle_common/11.1.1.9.0/p39966770_111190_Generic.zip -d $STAGE/common
$ cd $STAGE/common/39966770
$ $FMW_HOME/oracle_common/OPatch/opatch napply -oh $FMW_HOME/oracle_common

# 39959053 first, then 40090834; each from its own unzipped directory
$ cd $STAGE/common/39959053
$ opatch prereq CheckConflictAgainstOHWithDetail -ph ./    # ./ = 39959053
$ opatch apply
$ opatch lspatches | grep 39959053
$ cd $STAGE/common/40090834
$ opatch prereq CheckConflictAgainstOHWithDetail -ph ./    # ./ = 40090834
$ opatch apply
$ opatch lspatches | grep 40090834

# ---- WebLogic overlays ----
$ cd $FMW_HOME/utils/bsu
$ ./bsu.sh -install -patchlist=KP5S -prod_dir=$FMW_HOME/wlserver_10.3
$ ./bsu.sh -install -patchlist=4HID -prod_dir=$FMW_HOME/wlserver_10.3
$ ./bsu.sh -view -status=applied -prod_dir=$FMW_HOME/wlserver_10.3 | egrep 'PG6B|KP5S|4HID'

Points from this part of the cycle: 39966770 is applied with napply -oh to each home, and ORACLE_HOME must not point at oracle_common while you apply it to the Web Tier. 32287205 must be in the Web Tier before 34067016, and OPatch removed the older 31304503 itself when it applied 32287205. In Oracle Common I applied 39959053 before 40090834. Answer the Oracle Configuration Manager prompt as your own policy requires; I chose to remain uninformed. Run opatch lspatches in each home afterwards, and follow the README of each patch for its own prerequisites.

A note on checker timing: if you run the MT ETCC against the run edition before cutover, it reads the old file system and lists the new FMW patches as missing. That is expected. Run it against the patch edition before cutover, and against the run edition after.

Step 5: Finalize and cutover

Caution: downtime. Cutover is the outage window. Get approval from the application owner first, make sure nothing is still running from adop, opatch or bsu, and source the run edition before you start.

$ ps -ef | egrep 'adop|opatch|bsu|adpatch' | grep -v grep     # nothing running
$ . <EBS_BASE>/EBSapps.env run
$ time adop phase=finalize
$ adop -status
$ time adop phase=cutover mtrestart=no
$ adop -status

After cutover the run file system switches to fs2.

Step 6: Database tier, OPatch and datapatch

Caution: downtime and home selection. The database, its listener and anything else using this ORACLE_HOME must be down before opatch apply. Confirm OPatch is 12.2.0.1.52 or later (the minimum in both READMEs), run the conflict check first, and apply each component of the combo patch from its own README. Datapatch only patches PDBs that are open, so check show pdbs first.

$ $ORACLE_HOME/OPatch/opatch version
$ cd 39915792
$ $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./
$ $ORACLE_HOME/OPatch/opatch apply
$ cd ../39803650
$ $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./
$ $ORACLE_HOME/OPatch/opatch apply
$ $ORACLE_HOME/OPatch/opatch lsinventory | egrep '39915792|39803650'

OPatch finished with “Patch 39915792 successfully applied” and reported the earlier RU 39472050 as a subset patch that became inactive. During the apply it also printed two messages that I could not explain from the documentation I had: “prior crypto-provider patch state exists; refusing to overwrite it” and “Post-patch processing completed; new library payloads were preferred over MES backups”. The apply, datapatch and checkers were all clean afterwards, so I recorded the messages and did not treat them as a failure. If they matter to you, an SR is the way to get them explained.

Start the database, confirm the PDB is READ WRITE and not restricted, start the listener, then run datapatch:

SQL> startup
SQL> show pdbs
$ cd $ORACLE_HOME/OPatch
$ ./datapatch -verbose

Datapatch rolled back the old OJVM patch 39222882, applied RU 39915792 and OJVM 39803650, and reported SUCCESS with no errors in CDB$ROOT, PDB$SEED and the PDB. Then recompile and verify:

SQL> @?/rdbms/admin/utlrp.sql
SQL> col patch_id for 99999999999
SQL> col action for a10
SQL> col status for a12
SQL> col action_time for a30
SQL> select patch_id, rpad(action,10) action, rpad(status,12) status, to_char(action_time,'DD-MON-YYYY HH24:MI:SS') action_time
     from dba_registry_sqlpatch order by action_time;
SQL> col comp_id for a12
SQL> col comp_name for a44
SQL> col version for a17
SQL> select comp_id, comp_name, version, status from dba_registry;

All 15 registry components showed VALID (RAC is shown as OPTION OFF on a single instance, which is normal). After utlrp, the invalid count in the PDB went from 135 objects to a short list of custom APPS objects plus one SYS.AD_ZD_SYS package body. I treated those as follow-up items, not as patch failures. I did not compare them against a pre-patch baseline object by object, so check your own baseline.

Step 7: AutoConfig on both tiers

Caution: back up the context files and network admin directories on both tiers first. On the database node, set ORACLE_PDB_SID and source the correct environment file before running AutoConfig, and have the right APPS password ready. A wrong password stops the run with ORA-01017.

$ . <EBS_BASE>/EBSapps.env run
$ perl $AD_TOP/bin/admkappsutil.pl                 # creates appsutil.zip

# DB node
$ cd $ORACLE_HOME
$ mv appsutil.zip appsutil.zip_<date>; cp -rp appsutil appsutil_<date>
$ unzip -o appsutil.zip
$ export ORACLE_PDB_SID=<PDB_NAME>
$ sh $ORACLE_HOME/appsutil/scripts/<CONTEXT_NAME>/adautocfg.sh

# Application node
$ sh $INST_TOP/admin/scripts/adautocfg.sh
$ ./adstrtal.sh apps/<password>

My first database-tier AutoConfig run failed with ORA-01017 because I typed the wrong APPS password. The rerun succeeded. On the application tier, grepping adconfig.log for “error|fail|exception” returned only the JDBC URL line and the “Change reason” text that AutoConfig prints next to updated JVM arguments. Afterwards, compare tnsnames.ora and listener.ora with the copies you took before.

Step 8: Validation

Check	Result
ETCC, database tier	No missing patches reported
ETCC, application tier (run edition)	Only 29949547 listed, which applies to 23ai connectivity only
ECPUC	No rows returned, which means the checker reported no missing EBS CPU patches; EBS CPU level 2026.10
EJCPUC, application tier	Not clean: all four JDK 7 homes are at 1.7.0_513, and the checker requires 1.7.0_521. The update is still pending.
EJCPUC, database tier	Pending at the time of writing; the database JDK patch 39902051 has not been applied either

Step 9: fs_clone after the cycle

Caution: fs_clone runs for a long time, so use screen. Start it from the run edition after the cycle has been verified.

$ screen -S fsclone
$ time adop phase=fs_clone

This was the second fs_clone of the cycle; the first ran before prepare (Step 3). It completed in 57 minutes and adop -status showed it COMPLETED, so the patch file system was back in sync with the run file system for the next cycle. If fs_clone fails on nzosSetCredential error 43084, see KB269661 for the credential workaround before retrying.

Fallback planning

I did not roll anything back, so this is the plan I had, not something I executed. For the database software, the READMEs of 39915792 and 39803650 give the supported rollback for each component and the datapatch step that follows. For the application and FMW homes, the tarballs from Step 1 were the fallback for the software only. None of these tarballs is a database recovery backup: they do not cover the data files, and with the database in NOARCHIVELOG mode there was no other recovery path in this cycle (see Step 1). Check the READMEs before relying on any generic rollback command.

Open items after this cycle

• Database JDK patch 39902051 in a short downtime, then refresh the appsutil JRE copy and rerun AutoConfig.
• Application-tier JDK 7 update to 1.7.0_521 following KA1058, which needs a new adop cycle.
• Custom invalid objects and SYS.AD_ZD_SYS for follow-up with the owner or Oracle Support.
• Renew the wallet certificate before it expires.

Lessons learned

• Use nohup or screen for every long job. I lost time to a tar that was not protected.
• Check which edition a checker is reading before you trust its output.
• Get approval from the application owner before stopping or killing anything that is still running.
• Keep each checker log as evidence: the ETCC logs, the ECPUC listing and the adop session logs.
• Do not call a cycle clean until every checker has been read. Here the Java checker still flags the JDK 7 update on the application tier.
• ما شاء الله, the RU, OJVM, FMW and EBS patches all went in without a rollback, and the database-tier and EBS CPU checkers came back with nothing missing. The application-tier JDK 7 update (1.7.0_521) and the database JDK patch 39902051 are still open.

My Oracle Support references

Document	Used for
KA923	The October 2026 CPU note: patch list and prerequisites
KA988	ETCC special instructions and footnotes, the note the app-tier ETCC output points to
KA1058	Java (JDK) update for EBS, including the scenario for an existing JDK 7 install (still open, see above)
KB269661	fs_clone failure with nzosSetCredential error 43084

Check each note for its latest revision before you rely on it, because Oracle updates them between cycles.

Disclaimer: this post describes one test environment. Hostnames, paths and organisation details have been removed. Test every step in a non-production system and follow the current Oracle documentation before applying anything to production.