opatchauto

# Log in as root
su - root
# Execute opatchauto against the unzipped patch directory
/u01/app/19.0.0/grid/OPatch/opatchauto apply /tmp/patches/36225301Parent Dir 
(staged patches for both GI/DB) :- /tmp/patches/36225301/

Sub Dir:-

├── 36225410/     <-- GI / Clusterware Patch

├── 36225418/     <-- RDBMS Engine Patch

├── 36225425/     <-- OJVM (Oracle Java Virtual Machine) Patch  <--- [OJVM IS HERE]

├── 36225430/     <-- ACFS / Drivers Patch

├── bundle.xml    <-- Metadata

└── README.html

(JDK Patch)       <-- [NOT HERE] Must download separate JDK tar/zip overlay 

Yes, you are 100% right. Running opatchauto apply /tmp/patches/36225301/ will patch both your Grid Infrastructure (GI) Home and your Oracle Database (RDBMS) Homes at the exact same time in a single execution.

Here is what opatchauto does automatically with that staged directory:

Grid Infrastructure Home: Applies 36225410 (GI RU) and 36225430 (ACFS/Drivers).

Database Homes: Applies 36225418 (RDBMS Engine RU) to every DB home registered with the Grid Infrastructure.

Cluster Management: Handles draining database connections, shutting down the local CRS stack/instances on the node, applying binary changes, restarting the stack, and running datapatch.

Key Caveats for the Other Components in that Folder

36225425 (OJVM Sub-patch): opatchauto skips this sub-patch during rolling operations. You must apply OJVM separately using standard opatch as the oracle user (cd /tmp/patches/36225301/36225425 && opatch apply) while instances are down or in non-rolling mode, followed by datapatch.

JDK: Since the JDK overlay is not in this directory, it won't be touched. If you need to update JDK in $ORACLE_HOME/jdk, extract the separate JDK patch zip over the existing jdk directory manually while services are stopped.