OPatch -optimize: Dependency-Aware Conflict Handling

   A patch conflict is rarely limited to two patch IDs. In a long-lived Oracle Home, an installed one-off may be the base for an overlay, and another patch may depend on that overlay. Replacing the first patch can therefore create a chain of rollback dependencies that OPatch must process in the correct order.

The -optimize option is designed for this situation. When a supported OPatch version detects that an incoming patch conflicts with an installed patch, it can calculate the dependency-aware sequence, roll back the conflicting patch and its installed dependents recursively, and then continue with the incoming patch.

That automation is useful, but it changes more than the patch that originally appeared in the conflict report. The DBA still needs to confirm which fixes were removed, whether replacement overlays are required, and whether the final Oracle Home contains the intended patch level.

Why Ordinary Conflict Handling Can Become Complicated

Consider an example Oracle Home with the following patch relationships:

• Patch A is already installed.
• Overlay patch B depends on patch A.
• Incoming patch C conflicts with patch A.

Patch A cannot simply be removed while patch B still depends on it. A manual approach requires the DBA to identify the dependency chain, roll back B before A, apply C, and then determine whether a version of B exists for the new patch level. Missing one relationship can leave the patch session blocked or, worse, remove a fix without it being noticed during validation.

What OPatch -optimize Actually Does

With opatch apply -optimize, OPatch evaluates the installed patch relationships instead of treating the first conflict as an isolated event. Where the option is supported and applicable, OPatch can:

• Identify the installed patch or patches that conflict with the incoming patch.
• Discover installed patches that depend on those conflicting patches.
• Roll back the dependent patches recursively in a valid order.
• Roll back the original conflicting patches.
• Continue with the application of the incoming patch.

The option resolves the patching sequence; it does not create a merge patch. If a dependent one-off is rolled back and its fix is not included in the incoming patch, that fix may no longer be present in the Oracle Home. A replacement overlay or merge may still need to be obtained from Oracle Support.

Confirm That Your OPatch Build Supports It

OPatch capabilities belong to the OPatch utility installed in the Oracle Home, not simply to the database release. Two Oracle 19c homes can carry different OPatch builds. Before including -optimize in a runbook or automation workflow, verify the exact utility that will execute the patch.

export ORACLE_HOME=/u01/app/oracle/product/19c/dbhome_1
export PATH="$ORACLE_HOME/OPatch:$PATH"

opatch version
opatch apply -help | grep -i optimize
opatch lsinventory -detail > /path/to/evidence/lsinventory.before.txt

If the installed help does not list -optimize, do not assume that the syntax is accepted. Check the minimum OPatch version in the patch README and update OPatch using the release- and platform-appropriate Patch 6880880 package where required.

Analyze the Patch Graph Before Applying

Automation should not make the rollback set a surprise. First run the detailed conflict prerequisite check against the incoming patch. Once the conflicting patch IDs are known, check whether other installed patches depend on them.

# Check the incoming patch against the current Oracle Home
opatch prereq CheckConflictAgainstOHWithDetail \
  -ph /path/to/PATCH_ID

# Run this for each installed patch identified as a rollback candidate
opatch prereq CheckPatchRollbackDependents \
  -id CONFLICTING_PATCH_ID

The first command reports conflicts and supersets between the incoming patch and the current Oracle Home. The second checks whether rolling back an installed candidate affects dependent patches. Save both outputs with the change evidence. They provide the basis for deciding whether -optimize is appropriate or whether Oracle Support should supply a merge or replacement overlay first.

Applying the Patch

After completing the normal patch README prerequisites, stopping the required services, confirming backups or a recoverable Oracle Home, and testing the sequence in a representative environment, the apply operation is straightforward:

cd /path/to/PATCH_ID
opatch apply -optimize

Do not combine -optimize with -force or -force_conflict; these modes are mutually exclusive. Also, do not replace a patch README instruction to use opatchauto with this command. Grid Infrastructure system patches and other orchestrated patch bundles may require OPatchAuto because service control, rolling behavior, and multiple Oracle Homes must be coordinated.

A Special Case: Singleton Against Composite

A notable boundary condition occurs when the incoming patch is a singleton and its conflict is with a patch contained inside an installed composite patch. OPatch may skip the incoming singleton instead of dismantling the composite patch.

This is why the final console line is not enough. Review the OPatch log for skipped or inactive patches and compare the post-patch inventory with the approved patch plan. A successful OPatch session does not prove that every requested patch was installed.

-optimize vs  -force  Option

Option	Primary behavior	DBA concern
-optimize	Processes conflicting patches together with their installed dependents recursively.	Confirm that fixes removed with dependent patches are retained or replaced.
-force	Removes conflicting installed patches so the incoming patch can be applied.	It is not a substitute for understanding dependency and fix coverage.
-force_conflict	Overrides conflict behavior for a silent apply and removes conflicting patches.	Oracle documents it as meaningful with -silent; it cannot be combined with -optimize.

Post-Patch Validation Is the Real Completion Point

Validation must answer two separate questions: did the incoming patch install, and did the Oracle Home lose any required fix while OPatch resolved the dependency chain? Capture the new inventory and compare it with the approved before-state.

opatch lsinventory -detail > /path/to/evidence/lsinventory.after.txt
opatch lspatches

# Run only when required by the patch README, after starting the databases
$ORACLE_HOME/OPatch/datapatch -verbose

# Database-side SQL patch verification
sqlplus / as sysdba

SELECT patch_id,
       patch_type,
       action,
       status,
       action_time
FROM dba_registry_sqlpatch
ORDER BY action_time;

Follow the patch README for datapatch requirements and PDB state. Then verify component status, database and listener startup, RAC or Data Guard health where applicable, application smoke tests, and the specific defect or behavior that justified each one-off patch. Inventory consistency is necessary, but service validation proves that the maintenance achieved its operational objective.

When an Out-of-Place Home Is the Better Decision

The more one-offs, overlays, and historical rollbacks an Oracle Home contains, the harder it becomes to reason about in-place mutation. Oracle recommends out-of-place patching for current database maintenance because a prepared and tested target home gives a cleaner fallback and avoids modifying the only working home during the maintenance window.

Use -optimize when an in-place patch must resolve a known dependency chain and the resulting fix set has been reviewed. For a complicated or poorly understood patch history, building and validating a new Oracle Home may reduce operational risk more effectively than automating a large recursive rollback.

Quick Takeaways

• -optimize makes conflict handling aware of installed patch dependencies.
• Dependent patches can be rolled back recursively before the original conflicting patch.
• A rolled-back dependent fix is not automatically replaced unless the incoming patch includes it or a compatible overlay is applied.
• The option cannot be combined with -force or -force_conflict.
• Verify support using opatch apply -help from the exact Oracle Home.
• Treat skipped patches, final inventory, SQL patch status, and application behavior as separate validation checks.

Conclusion

The value of opatch apply -optimize is not that it makes patch conflicts harmless. Its value is that it understands the dependency chain that can make a manual rollback sequence difficult and error-prone. By recursively removing installed dependents before their conflicting base patches, OPatch can prepare the Oracle Home for the incoming patch with less manual sequencing.

The DBA still owns the outcome. Record the pre-patch inventory, examine the conflict and rollback-dependency checks, confirm which fixes will disappear, and obtain replacement overlays where necessary. After the apply, validate both the binary and SQL inventories and test the services that rely on the removed fixes. If the Oracle Home has accumulated a complex patch history, use the conflict analysis as a signal to consider an out-of-place, gold-image-based maintenance approach instead.

Official References 

• Oracle OPatch Syntax and Commands
• Oracle AI Database Patch Maintenance Guidelines
• Database Patch Conflict Resolution (My Oracle Support Doc ID 1321267.1)