What you will learn
The bundle-patch notes contain obsolete patch IDs and release-specific outage scripts. The reusable 19c process is inventory, conflict analysis, recovery preparation, the exact patch README, and independent postchecks. A historical patch number must not become a current deployment target.
Before you begin
Use an isolated Oracle Database 19c Linux lab with a certified patch level. Names host1.sample.com and host2.sample.com identify distinct lab hosts; replace them consistently with your own addresses. Use oracle for database software and grid for Grid Infrastructure where ownership is separated. Connect through local operating-system authentication or a configured wallet; no example includes a password. Preserve a tested backup and record the database identity before changes. Obtain the approved patch and README for the exact platform, home, and topology. Separate database, Grid Infrastructure, and Exadata system-software changes. Confirm OPatch version, free space, backups, and rollback instructions.
1. Capture baselines
"$ORACLE_HOME/OPatch/opatch" version
"$ORACLE_HOME/OPatch/opatch" lsinventory
SELECT comp_id,version,status FROM dba_registry ORDER BY comp_id;
SELECT patch_id,action,status,action_time FROM dba_registry_sqlpatch ORDER BY action_time;
Repeat for each relevant home and node. Review SQL patch state in every intended CDB container. Binary registration and database-side SQL state are different evidence.
2. Resolve conflicts before the outage
Stage the extracted patch outside the active home, verify its integrity, and run README prerequisites. A typical database-home check is:
"$ORACLE_HOME/OPatch/opatch" prereq CheckConflictAgainstOHWithDetail -phBaseDir /u02/stage/patch
Confirm the directory layout expected by that patch. Resolve conflicts through supported replacements or merges, not arbitrary force options.
3. Rehearse and apply the exact workflow
Follow the README for drain, shutdown, binary installation, startup, and SQL changes. Rolling eligibility depends on patch and topology. For a database RU requiring datapatch, run from the patched database home with the required databases and PDBs open:
"$ORACLE_HOME/OPatch/datapatch" -verbose
This is the SQL phase, not a binary-patch command. Do not run it on a physical standby or substitute it for the documented Data Guard sequence.
4. Compare the postpatch evidence
Repeat inventories, review latest required APPLY records and logs, and test services and application transactions. End blackouts only after acceptance. Historical catbundle.sql commands are not interchangeable with a 19c workflow.
5. Read the example output
The following is illustrative, normalized output, not a transcript from a customer system. Values depend on your release and lab state.
Expected binary patch: present on intended homes
Latest required SQL APPLY: SUCCESS
Required containers: checked
Application probe and backup: passed
Record actual patch IDs and logs in the private change evidence.
Verify the result
Verify agreement across nodes, homes, and containers and complete an application smoke test and backup. Compare component status with the baseline to distinguish preexisting findings from regressions.
Troubleshooting
Inventory mismatches may mean the command used the wrong home. SQL APPLY failures require datapatch log review. A closed PDB can still need its SQL phase after opening.
Recovery and next steps
Use the patch-specific rollback instructions, including SQL rollback where required. Retain a tested old home for out-of-place strategies. Switching the home path alone does not reverse dictionary changes.