Oracle Database Patches and Enterprise Patching Policy
Below is a practical review of Oracle Database patch types, followed by a step-by-step patching policy suitable for an enterprise database estate. The approach emphasizes security, availability, rollback capability, audit evidence, RAC/Data Guard coordination, and repeatable automation.
Important: Patch instructions differ by Oracle release, operating system, architecture, and deployment model. The patch README and applicable My Oracle Support, or MOS, notes must remain the final authority for every implementation.
1. Oracle patching concepts
Oracle patch maintenance falls into two broad categories:
Proactive maintenance
Proactive patching applies Oracle-recommended cumulative updates before a known problem affects the environment. For Oracle Database 19c and later, the principal proactive mechanisms are quarterly Release Updates and, where supported, Monthly Recommended Patches.
Reactive maintenance
Reactive patching addresses a particular defect or urgent problem, usually through an interim or one-off patch. These patches are produced for a specific bug, database version, platform, and configuration, and may later be included in an RU.
Recommended policy: Use RUs and supported MRPs as the standard maintenance path. Use one-off patches only when required by Oracle Support, a documented critical defect, or an approved security exception.
2. Oracle Database patch types
2.1 Release Update, or RU
An RU is Oracle’s primary cumulative quarterly database patch bundle for currently supported database releases.
It generally includes:
- Security fixes
- Optimizer and database engine fixes
- Reliability and availability fixes
- Data Guard, RAC, ASM, RMAN, and other component fixes
- Fixes from previous RUs
- SQL changes that may require
datapatch
Oracle no longer delivers traditional patch sets for current releases. Quarterly RUs are the normal proactive maintenance mechanism.
Recommended usage
- Make the RU the baseline patch for all production databases.
- Do not remain indefinitely on the base release, such as 19.3.
- Prefer a recent and internally certified RU.
- Avoid allowing different databases in the same service stack to drift across many RU levels.
- Patch Grid Infrastructure and database homes according to the combination and sequence prescribed in the patch README.
Example version interpretation
For a database showing a version such as:
19 represents the major release family and 28 identifies the RU level.
2.2 Monthly Recommended Patch, or MRP
An MRP provides Oracle-recommended fixes on top of the current RU. Oracle introduced MRPs as a more frequent proactive maintenance option, initially for Oracle Database 19c on Linux x86-64. Availability must therefore be verified for the exact database release and operating-system platform.
Recommended usage
Use MRPs when:
- The platform and release support them.
- The organization can test monthly maintenance.
- A recommended fix is needed before the next quarterly RU.
- Security or operational risk justifies a monthly cadence.
Suggested policy
- Critical internet-facing or high-risk systems: Evaluate each applicable MRP.
- Standard production systems: Quarterly RU as the minimum; use an MRP where risk analysis identifies a need.
- Low-criticality systems: Keep aligned with the approved RU baseline.
MRPs should not be treated as a substitute for moving to the next quarterly RU.
2.3 Critical Patch Update, or CPU
A CPU is Oracle’s security advisory and security-fix delivery program across Oracle products. CPUs normally occur on the third Tuesday of January, April, July, and October. The advisory identifies affected products, vulnerabilities, severity, affected versions, and links to patch availability documentation.
For Oracle Database, the security fixes announced in a CPU are normally delivered through the applicable database patch bundle, commonly the RU, rather than as a completely separate database maintenance strategy.
Policy implication
When a CPU is released:
- Security must review the advisory.
- The DBA team must identify affected versions and components.
- The team must download the relevant Patch Availability Document from MOS.
- Risk must be assessed using:
- CVSS score
- Remote exploitability
- Authentication requirement
- Exposure of the listener or database service
- Usage of affected components
- Availability of mitigation
- Applicable patches must enter expedited testing.
Oracle advises customers to use actively supported releases and apply security patches without delay.
2.4 Security Patch Update, or SPU
SPU is historically associated with the security-only database patch stream and may still appear in MOS references, older releases, and patch-selection documentation. It contains a narrower set of fixes than a full proactive bundle.
Recommended usage
For modern supported databases, an RU should generally be preferred because it provides cumulative security and reliability fixes. Select an SPU only when:
- It is the applicable Oracle-supported delivery method for that release or platform.
- Oracle Support directs the organization to use it.
- An approved exception prevents adoption of the RU.
Do not mix RU, PSU, BP, or SPU streams without checking the README and MOS conflict guidance.
2.5 Patch Set Update, or PSU
PSUs are cumulative patch bundles used primarily with older Oracle release families. They include security fixes and selected high-impact fixes.
For 12.2 and later release families, Oracle moved to the RU model. Older databases may still have PSU or Bundle Patch terminology.
Policy implication
A database that depends on PSUs should be classified as a legacy platform and placed on an upgrade or retirement roadmap.
2.6 Bundle Patch, or BP
A Bundle Patch groups fixes for a specific platform or product configuration. The term is commonly encountered with:
- Older Windows database releases
- Engineered systems
- Grid Infrastructure
- Specific components or products
Bundle Patches are normally cumulative within their patch stream.
Policy implication
Never assume that a BP, PSU, SPU, and RU are interchangeable. The DBA must confirm the correct patch stream for the product, release, and platform in MOS.
2.7 Interim or one-off patch
A one-off patch fixes a particular Oracle bug. It is usually associated with:
- An Oracle Service Request
- A specific bug number
- A particular RU level
- A particular operating-system platform
One-off patches are reactive and may conflict with an RU, MRP, OJVM patch, or another one-off patch. Oracle therefore requires interim patch conflict analysis before maintenance.
Recommended control
Every one-off patch should have:
- Oracle SR number
- Bug number
- Business justification
- Patch ID
- Applicable RU
- Platform
- Conflict-check result
- Expiry or removal plan
- Confirmation whether the fix is included in a later RU
One-offs should not become permanent undocumented dependencies.
2.8 Oracle JavaVM, or OJVM patch
An OJVM patch addresses vulnerabilities and defects in the Java Virtual Machine component installed inside Oracle Database.
Important considerations
- Determine whether OJVM is installed and used.
- Review whether the patch supports rolling or requires non-rolling maintenance.
- Check for Java-dependent applications and invalid objects.
- Run all required SQL patching steps.
- Validate
JAVAVMand related components after patching.
Do not assume a database RU automatically resolves every separately delivered OJVM requirement. Always inspect the RU and OJVM README.
2.9 Grid Infrastructure Release Update
A Grid Infrastructure RU patches components such as:
- Clusterware
- Oracle Restart
- ASM
- ACFS
- Cluster communication components
- GI-managed listeners and resources
For RAC environments, OPatchAuto can orchestrate prerequisite checks, stopping and starting services, patch application, post-checks, and rollback. Oracle recommends Fleet Patching and Provisioning for larger RAC, Exadata, and Data Guard estates.
Key rule
The Grid home and database homes are separate software inventories. Both need to be assessed and patched where applicable.
3. Recommended enterprise patching policy
3.1 Patch cadence
| Environment | Target cadence | Suggested completion target |
|---|---|---|
| Sandbox / laboratory | As soon as patch is available | 3 to 5 business days |
| Development | Every quarterly RU | Within 7 to 10 days |
| Test / SIT | Every quarterly RU | Within 14 days |
| UAT / pre-production | Every quarterly RU | Within 21 days |
| Critical production | Every quarterly RU | Within 30 days |
| Standard production | Every quarterly RU | Within 30 to 45 days |
| Security emergency | Out-of-band | Based on risk, normally 24 hours to 7 days |
| Supported MRP candidates | Monthly assessment | Risk-based |
Oracle’s CPU calendar is quarterly, but Security Alerts can be published outside the normal schedule for particularly critical vulnerabilities or active exploitation.
3.2 Patch currency standard
Use an organizational standard such as:
Production databases must be on the approved current RU or, temporarily, no more than one RU behind. Any database more than one RU behind requires a documented security exception, compensating controls, business-owner approval, and a remediation date.
For highly exposed systems, the organization may adopt a stricter standard:
Internet-facing, regulated, or Tier-0 databases must be moved to the approved current RU within 30 days, or faster when the CPU risk assessment requires it.
3.3 Preferred deployment model
Oracle recommends using a new Oracle home and performing out-of-place patching because this simplifies maintenance and reduces the risk associated with modifying the active home.
Out-of-place patching
- Install or clone a new Oracle home.
- Apply the approved RU and required one-offs.
- Validate the new home.
- Switch the database to the new home.
- Execute
datapatch. - Retain the previous home for an approved fallback period.
Why it is better
- Cleaner rollback
- Reduced risk of corrupting the active home
- Repeatable gold-image deployment
- Easier standardization
- Shorter database outage
- Better separation between preparation and cutover
For a large RAC, Exadata, or Data Guard estate, Oracle recommends Fleet Patching and Provisioning.
4. Step-by-step Oracle Database patching procedure
Phase 1: Discovery and scope definition
Step 1: Build the database inventory
Collect:
- Hostname and operating system
- Database name and DB unique name
- Database release and RU
- Oracle home
- Grid home
- RAC or single instance
- CDB and PDB architecture
- Data Guard configuration
- GoldenGate usage
- ASM and ACFS usage
- OJVM installation status
- One-off patches
- Business owner
- Criticality and RTO/RPO
- Maintenance window
Useful discovery commands:
Database checks:
DBA_REGISTRY_SQLPATCH records SQL patch apply and rollback attempts, status, patch type, time, and log location, and is maintained by datapatch.
Phase 2: Patch selection
Step 2: Select the target RU
Use MOS as the patch source of truth. Search by:
- Product
- Release
- Platform
- Patch type
- Language, if applicable
Download:
- Database RU
- Grid Infrastructure RU
- OJVM patch, if required
- Latest supported OPatch version
- Required one-off or merge patches
- Patch README
- Known-issues notes
Oracle recommends obtaining patches through MOS and reviewing the exact README for downloading, prerequisites, application, and post-patch instructions.
Step 3: Review known issues
Check:
- RU known issues
- Platform-specific defects
- Data Guard and RAC restrictions
- OJVM restrictions
- Optimizer changes
- RMAN issues
- Data Pump issues
- GoldenGate compatibility
- Application certification
- Required post-install fixes
- Superseded one-offs
If a new RU has a serious known issue for your configuration, choose the preceding approved RU plus the required correction, but document the decision.
Phase 3: Conflict and readiness analysis
Step 4: Verify OPatch
Use the OPatch version specified in the patch README. Oracle recommends using the latest applicable OPatch release.
Step 5: Run conflict analysis
For a database home:
For a system patch or GI/RAC patch:
Resolve conflicts by:
- Removing an obsolete one-off
- Obtaining a replacement one-off for the target RU
- Requesting a merge patch
- Raising an Oracle SR
- Moving to a later RU that already includes the fix
Do not proceed with an unresolved conflict.
Step 6: Verify disk space
Check:
- Oracle home
- Grid home
- Central inventory
- Patch stage
/tmp- Database filesystem
- Archive log destination
- FRA
- ASM disk groups
Oracle’s maintenance guidance explicitly requires system dependency and free-space checks before patch application.
Phase 4: Backup and recovery preparation
Step 7: Prepare rollback capability
At minimum:
- Current RMAN backup
- Validated restore capability
- Control-file and SPFILE backup
- Oracle home backup or retained old home
- Grid home backup, where applicable
- Central inventory backup
- Listener and network configuration backup
- Password file backup
- Wallet and TDE keystore backup
- OCR and voting-disk health check for RAC
- Data Guard synchronization check
- Recovery runbook
Oracle strongly recommends backing up Oracle home binaries, Grid home binaries, and the central Oracle inventory before applying an RU or interim patch.
Example RMAN preparation:
A backup is not sufficient unless its restore path has been tested.
Phase 5: Rehearsal and approval
Step 8: Patch non-production first
Follow the promotion sequence:
Test:
- Database startup and shutdown
- Application connectivity
- Critical SQL
- Batch processes
- RMAN backup and restore
- Data Guard transport and apply
- RAC service relocation
- Listener registration
- OEM monitoring
- GoldenGate replication
- Data Pump
- Scheduler jobs
- OJVM applications
- Performance baselines
Step 9: Conduct change review
The change record should contain:
- Patch IDs
- Source and target RU
- Affected systems
- README
- Conflict report
- Test evidence
- Backup evidence
- Implementation plan
- Outage estimate
- Rollback criteria
- Rollback steps
- Business validation plan
- DBA, application, infrastructure, security, and service-owner contacts
Phase 6: Production implementation
Step 10: Complete pre-patch health checks
Check for:
- Invalid database components
- Invalid objects
- Failed scheduler jobs
- Tablespace issues
- FRA pressure
- Archive destinations
- Data Guard lag
- RAC resource state
- Blocking transactions
- Backup failures
- Existing alert-log errors
Example queries:
Record existing faults so they are not incorrectly attributed to the patch.
Step 11: Stop or relocate services
Coordinate:
- Application connections
- Connection pools
- Database services
- GoldenGate
- Monitoring
- Backup jobs
- Batch jobs
- Data Guard Broker
- RAC services
When GoldenGate is used, Oracle’s patch-maintenance guidance says its processes must be shut down before patching the database.
Step 12: Apply the binary patch
The exact command must come from the patch README.
Typical single-instance in-place pattern:
Typical GI/RAC pattern:
OPatch applies and rolls back patches in an Oracle home. OPatchAuto can perform prechecks, stop and start resources, apply patches, conduct post-checks, and perform rollback orchestration.
Step 13: Run datapatch
After the database and required PDBs are open in the mode prescribed by the README:
When OPatch is used for database maintenance, datapatch must be run to load applicable SQL changes into the database.
For multitenant environments:
- Confirm all required PDBs are open.
- Confirm each PDB receives the SQL patch.
- Check for PDBs that were closed or unavailable during
datapatch. - Rerun
datapatchif directed after opening missed PDBs.
Phase 7: Validation
Step 14: Validate binary inventory
In RAC, validate every node and every relevant home.
Step 15: Validate SQL patch registry
The expected result is normally:
Any WITH ERRORS status requires log review and remediation.
Step 16: Validate database health
Also review:
- Alert log
- Listener log
- Patch logs
- CRS resources
- ASM state
- Data Guard transport and apply lag
- Application smoke tests
- Critical execution plans
- Backup operation
- Monitoring alerts
- Performance compared with baseline
5. Data Guard patching best practices
For Data Guard:
- Confirm zero or acceptable transport and apply lag.
- Validate broker configuration.
- Patch the standby side first where supported.
- Restart and validate standby apply.
- Perform switchover if the chosen strategy requires it.
- Patch the former primary.
- Validate both directions of the configuration.
- Run
datapatchin accordance with the README and the selected Data Guard procedure. - Test failover and service behavior where possible.
Oracle prefers out-of-place maintenance using a new Oracle home and recommends Fleet Patching and Provisioning for Data Guard estates. OPatchAuto remains an available alternative for relevant configurations.
Do not independently activate standby databases merely to run SQL patching unless the documented procedure specifically requires it.
6. RAC patching best practices
For RAC:
- Use rolling patching only if the patch is explicitly certified as rolling.
- Run conflict checks against both Grid and database homes.
- Check
opatch lsinventoryon every node. - Confirm CRS resources before and after each node.
- Drain or relocate services before stopping an instance.
- Validate SCAN listeners and local listeners.
- Review service failover and connection-pool behavior.
- Verify the patch inventory is consistent across all nodes.
- Run SQL patching once according to the README, not separately and blindly from every node.
Oracle recommends FPP to simplify RAC maintenance, while OPatchAuto remains an orchestration option. Out-of-place patching with a new home is the preferred maintenance model.
7. Rollback policy
Rollback must be defined before entering the maintenance window.
Typical rollback triggers
- Database cannot start
- RAC resource remains unstable
- Data Guard transport or apply cannot be restored
datapatchfails and cannot be corrected- Critical application smoke test fails
- Severe performance regression
- Data corruption symptoms
- Maintenance window is exceeded
- Oracle Support recommends rollback
Preferred rollback sequence for out-of-place patching
- Stop application access.
- Return the database configuration to the previous Oracle home.
- Restart the database from the old home.
- Roll back SQL changes if they were applied and the README requires it.
- Validate services and application operation.
- Record all commands and errors.
- Raise or update the Oracle SR.
Typical in-place binary rollback may use:
System patch rollback may use:
Exact rollback commands and SQL sequencing must come from the applicable README.
8. Governance, evidence, and KPIs
Required patch evidence
Retain:
- Before-and-after
opatch lsinventory - Before-and-after
opatch lspatches datapatchlogsDBA_REGISTRY_SQLPATCHresults- Database component status
- Invalid-object comparison
- Backup record
- Conflict-check output
- Change approval
- Test results
- Application-owner validation
- Alert-log review
- Data Guard or RAC validation
- Rollback decision record
- Updated CMDB
Recommended KPIs
- Percentage of databases on approved RU
- Percentage more than one RU behind
- Median days from RU release to production
- Critical-patch SLA compliance
- Patch success rate
- Rollback rate
datapatchfailure rate- Inventory mismatch count
- Number of undocumented one-offs
- Number of unsupported database releases
- Number of outstanding security exceptions
- Percentage of restore tests completed
9. Recommended policy statement
A concise organization-level policy could be:
Oracle Database environments shall be maintained on an actively supported Oracle release and an approved recent Release Update. Quarterly RUs shall be assessed immediately after release, tested through the defined environment sequence, and deployed to critical production systems within 30 days and standard production systems within 45 days. Critical security vulnerabilities, Security Alerts, and actively exploited issues shall follow the emergency patching process. Out-of-place patching shall be the preferred deployment method. Every patch implementation shall include conflict analysis, current recovery capability, non-production testing, documented rollback criteria, binary and SQL patch validation, application-owner sign-off, and retention of audit evidence.
10. Practical recommendation for your database estate
As a Database Architect, I recommend structuring the program around five controls:
- One approved RU baseline per database release and platform
- Out-of-place gold-image patching as the default
- Quarterly release train with monthly security review
- Central register for one-offs, conflicts, and exceptions
- Automated evidence collection for SOX and operational audits
The most important architectural improvement is to move away from individually patching every Oracle home manually. Maintain certified gold images containing:
- Required RU
- Approved OJVM patch
- Required one-offs
- Correct OPatch release
- Standard configuration
- Antivirus exclusions, if applicable
- Verification manifest and checksum
- Test and approval reference
This reduces configuration drift, patch conflicts, execution errors, and outage duration while producing stronger audit evidence. Oracle’s current maintenance guidance similarly favors out-of-place patching and recommends FPP for large RAC, Exadata, and Data Guard deployments.
Review summary
This framework separates proactive, reactive, security, and component-specific patches, then ties each category to a controlled lifecycle. The most important best-practice improvements are adopting quarterly RUs as the standard, preferring out-of-place patching, validating both binary and SQL registries, and treating backup verification and rollback as mandatory entry criteria rather than optional DBA activities.
