Oracle patching is becoming more frequent. With quarterly Release Updates (RUs) complemented by Monthly Recommended Patches (MRPs) and CSPUs, the traditional model of patching a few times a year is becoming harder to sustain.
That makes one question increasingly important: should Oracle Database and Grid Infrastructure be patched in-place or out-of-place?
The two approaches are technically supported, but they represent very different operating models.
In-place
In-place patching modifies the existing Oracle Home directly. The primary advantage is simplicity. There is no second Oracle Home to build, no additional storage requirement, and no home-switching process. For certain environments, and particularly for supported online/hot patches, this can be a practical approach. Oracle continues to support OPatch and OPatchAuto for these scenarios.
The concern is that production software is being changed before the new state has been fully proven.
Rollback can also become more complicated as the Oracle Home accumulates RUs, MRPs, OJVM updates, merge patches, and application-specific one-offs. As an example, the MRP/CSPU is made up of individual patches that may need to be rolled back separately, followed by datapatch execution.
There is another issue: patch conflicts. When a home contains multiple one-offs and MRPs, applying the next RU can require conflict analysis and merge patch requests.
Over time, the result can be a highly customized Oracle Home that is difficult to standardize and automate.
Out-of-place
Out-of-place patching takes a different approach. The existing Oracle Home remains untouched while the new home is prepared and validated.
This creates significant advantages.
Risk isolation. A failed patch doesn’t immediately alter the production software.
Rollback. Instead of reconstructing the previous software state, the instance can be returned to the retained Oracle Home.
Standardization. The new Oracle Home can become a controlled gold image and be reused across many systems.
Oracle recommends out-of-place patching as the preferred approach for Database and Grid Infrastructure, with gold-image workflows and Database Lifecycle Management or Fleet Patching and Provisioning (FPP) recommended for RAC, Data Guard, and Exadata environments automation. There’s also Exadata Fleet Update for Oracle Cloud environments.
Throw monthly security updates in the picture
The difference becomes much larger as patch frequency increases. Oracle’s current recommendation is essentially to stay on the current RU and apply the latest available MRP/CSPU, rather than relying on a long-running n-1 strategy.
That makes the ability to repeatedly create, test, and deploy a known software image increasingly valuable.
Out-of-place patching reduces production risk by building, patching, and validating a new Oracle Database or Grid Infrastructure home before moving workloads to it, while preserving the existing home as a controlled fallback. It simplifies rollback, identifies patch conflicts before the maintenance window, and reduces downtime by completing most preparation and validation in advance.
Testing time can also be significantly reduced by creating standardized, pre-patched gold images that are qualified once and then promoted consistently across development, test, and production environments, rather than rebuilding and retesting different patch combinations for every Oracle Home.
This approach prevents the complexity that accumulates when RUs, MRPs, OJVM patches, and one-offs are repeatedly layered onto existing homes, while enabling greater automation, rolling maintenance, fleet-wide consistency, and auditability making it particularly well suited to today’s more frequent security patching cadence.
In-place can still be appropriate when:
- a supported online/hot patch is available
- storage is highly constrained
- a legacy application requires it
- or a specific technical limitation prevents an out-of-place workflow.
The key is to make those intentional exceptions, rather than making in-place the default simply because it has always been the process.
Thanks,
Alfredo