45 Software Maintenance Best Practices

Oracle Maximum Availability Architecture (MAA) provides a comprehensive, proven framework to maintain Oracle software, designed to minimize disruption while safeguarding business operations.

Regular software maintenance is essential to:

  • Strengthen software security and address newly discovered vulnerabilities
  • Improve stability and reliability through tested and supported releases
  • Maintain compatibility with newer database, infrastructure, and operating system components
  • Ensure access to the most effective Oracle Support diagnostic and resolution tools
  • Remain eligible for the latest fixes and enhancements

This document describes MAA software maintenance best practices for:

  • Oracle Database
  • Oracle Grid Infrastructure (GI)
  • Oracle Exadata Database Machine

The guidelines address the entire maintenance lifecycle, including detecting when updates are needed, selecting the recommended target version, obtaining the required software, and applying updates with minimal service disruption.

Software maintenance consists of three high-level phases, which are addressed in detail in the topics that follow:

  1. Detect When Software Needs To Be Updated
  2. Obtain Recommendation Software
  3. Apply Software Update

By following the MAA software maintenance best practices described here, you can ensure your database environments remain secure, resilient, and highly available, while minimizing disruption to your business operations.

Detect When Software Needs To Be Updated

Defining a software maintenance policy that aligns with your organization’s business requirements, and proactively detecting when software is outdated, are critical for maintaining security, stability, and compliance. Oracle recommends automating detection and alerting by using both Oracle tooling and curated My Oracle Support (MOS) resources.

Key Practices

  • Define your organization’s software maintenance policy to align with business requirements for compliance, risk tolerance, and update frequency.
  • Leverage Oracle tools to determine software health that dictates when software maintenance is required or recommended to meet Oracle’s official recommendation that aligns with your software maintenance policy. Automate health checks with DBCA or FPP integrated with OUA to drive consistent, policy-aware recommendations and status.
  • Establish notification thresholds for critical and important advisories that trigger interim fixes.
  • Monitor feature-specific recommendations for components that matter to your business (for example, Data Guard).

Define a Software Maintenance Policy

Establish a documented software maintenance policy that reflects compliance requirements, risk tolerance, and service level agreements (SLAs). Review your maintenance policy whenever business or operational requirements change.

A comprehensive software update policy should define directives such as:

  • Apply Frequency: How often proactive software updates are applied (for example, monthly, quarterly, semiannually, or annually). Oracle typically releases proactive updates monthly or quarterly.

  • Update Lag: Whether to apply the most recent proactive update (N) or a previous one (N-1 or N-2). For example, N means installing the latest available proactive update; N-1 means installing one before the latest proactive update.

  • Notification Level: The severity of newly published issues that trigger applying interim fixes before the next proactive update. Levels include Critical and Important. The choice between Critical and Important monitoring depends on business risk tolerance and operational priorities.

    • Critical: Address only critical issues immediately. Examples are listed in MOS note 1270094.1.

    • Important: Address both critical and important issues immediately. Examples for Oracle Database are listed in MOS note 555.1.

  • Recommendation Area: The specific Oracle product components or features for which software recommendations will be monitored. Identify recommendation areas that are critical to business success. Recommendation area expands the software recommendations beyond that of the base software being evaluated. For example, Data Guard is a recommendation area that expands the base Oracle Database recommendations.

Oracle Database and Grid Infrastructure Software

Oracle Database and Oracle Grid Infrastructure require a defined, repeatable software maintenance policy that balances security, stability, and change rate. The policy should specify how often you apply proactive updates (Apply Frequency), how far behind the latest release you allow yourself to operate (Update Lag), and what severity of missing recommended fixes triggers interim action.

Oracle recommends using out-of-place, gold image-based updates orchestrated by DBCA for single-instance systems and FPP for clustered environments, with Oracle Update Advisor supplying policy-aware recommendations and ready-to-deploy images. This approach standardizes software baselines, reduces risk and downtime, and simplifies rollbacks while aligning with MAA high availability principles.

Policy Scenarios

The tables below show examples of software maintenance goals and the Apply Frequency and Update Lag policy directives used to achieve the goal.

Apply Frequency Description
Quarterly Update quarterly
Semiannually Update twice per year
Annually Update once per year
Monthly Update monthly
Monthly Long Term RU Update monthly staying on a Long Term RU
Update Lag Description
N Install latest RU
N-1 Install prior (N-1) RU
N-2 Install prior (N-2) RU
Apply Frequency Update Lag N Update Lag N-1 Update Lag N-2
Quarterly Supported Supported Supported
Semiannually Supported Supported Supported
Annually Supported Not supported1 Not supported1
Monthly Supported Supported Not supported2
Monthly Long Term RU Supported Supported Not supported3

Footnotes:

1Not supported because it can lead to operating with software >= 1 year old.

2Not supported because monthly updates extend to only one prior RU.

3Not supported because monthly updates extend to only one prior Long Term RU.

Policy Examples

The following policy examples cover the most common customer goals.

  • Policy Example 1 : Apply Frequency = Quarterly, Update Lag = N
  • Policy Example 2 : Apply Frequency = Quarterly, Update Lag = N-1
  • Policy Example 3 : Apply Frequency = Monthly, Update Lag = N-1
  • Policy Example 4 : Apply Frequency = Monthly Long Term RU, Update Lag = N-1

Policy Example 1 : Apply Frequency = Quarterly, Update Lag = N

This is the default, most common policy. Adopt the latest Release Update (RU) each quarter as it is released, operate on that RU for roughly three months, and repeat. This approach keeps security and stability fixes current with no lag.

Policy summary:

  • Stay on the latest RU for 3 months
  • When a new RU is released every quarter (January, April, July, and October), install the new RU
Date Released RU Installed RU
     
25-Jul 19.28 19.28
25-Aug   19.28
25-Sep   19.28
25-Oct 19.29 19.28 ➞ 19.29
25-Nov   19.29
25-Dec   19.29
26-Jan 19.30 19.29 ➞ 19.30
26-Feb   19.30
26-Mar   19.30
26-Apr 19.31 19.30 ➞ 19.31
26-May   19.31
26-Jun   19.31
26-Jul 19.32 19.31 ➞ 19.32
     
     

The following for policy example 1 shows Oracle Database 19c quarterly RU releases and their release month over 28 months. It depicts the quarterly, no‑lag policy, where you adopt each newly released RU that quarter, operate on it for about three months, and then advance to the next RU on release.


Graph of quarterly updates with update lag = N

Policy Example 2 : Apply Frequency = Quarterly, Update Lag = N-1

Choose this policy when you prefer a conservative cadence. Stay one RU behind the latest by installing the previous quarter’s RU each cycle, operating on that RU for approximately three months before advancing to the next previous RU. This reduces early-adoption risk while maintaining a predictable quarterly cadence.

Policy summary::

  • Stay on the N-1 RU for 3 months
  • When a new RU is released every quarter (January, April, July, and October), install the next N-1 RU
Date Released RU Installed RU
25-Jul 19.28 19.27
25-Aug   19.27
25-Sep   19.27
25-Oct 19.29 19.27 ➞ 19.28
25-Nov   19.28
25-Dec   19.28
26-Jan 19.30 19.28 ➞ 19.29
26-Feb   19.29
26-Mar   19.29
26-Apr 19.31 19.29 ➞ 19.30
26-May   19.30
26-Jun   19.30
26-Jul 19.32 19.30 ➞ 19.31

Policy Example 3 : Apply Frequency = Monthly, Update Lag = N-1

This policy minimizes potential exposure to new issues brought about by updating to the latest RU by lagging one RU (N-1), while still applying the latest recommended MRPs monthly between quarters. Operate on a given RU for roughly one quarter, and each month apply the current MRP for that RU. When a new quarterly RU is released, move to the prior (N-1) RU for the next quarter, then continue monthly MRPs on that RU.

Policy summary:

  • Stay on an RU for 3 months
  • Install the latest MRP for the prior (N-1) RU every month
  • When a new RU is released every quarter (January, April, July, and October), install the prior (N-1) RU and the latest MRP for that RU

MRP details:

  • MRPs are cumulative monthly bundles applied on top of a specific RU and do not change the RU version. MRPs apply only to Linux x86-64.
  • MRP labels in the tables (for example, MRP3, MRP4) denote the third, fourth, and so on monthly cumulative bundles after the RU release.
Date Released RU Installed RU
25-Oct 19.29 19.28 + MRP3
25-Nov 19.28 + MRP3 ➞ 19.28 + MRP4
25-Dec 19.28 + MRP4 ➞ 19.28 + MRP5
26-Jan 19.30 19.28 + MRP5 ➞ 19.29 + MRP3
26-Feb 19.29 + MRP3 ➞ 19.29 + MRP4
26-Mar 19.29 + MRP4 ➞ 19.29 + MRP5
26-Apr 19.31 19.29 + MRP5 ➞ 19.30 + MRP3
26-May 19.30 + MRP3 ➞ 19.30 + MRP4
26-Jun 19.30 + MRP4 ➞ 19.30 + MRP5
26-Jul 19.32 19.30 + MRP5 ➞ 19.31 + MRP3

The following graph for policy example 3 shows Oracle Database 19c quarterly RU and monthly MRP releases and their release month over 28 months. It depicts the monthly, N‑1 policy, where you stay one RU behind, apply the latest monthly MRP to that RU each month, and shift to the next N‑1 RU at the following quarterly release.


Graph of month updates with apply lag n minus one

Policy Example 4 : Apply Frequency = Monthly Long Term RU, Update Lag = N-1

This policy targets customers who prefer a long-lived RU foundation (Long Term RU) while still consuming monthly MRPs. Stay on a designated Long Term RU for approximately 12 months and apply the latest MRP each month. When the next Long Term RU becomes available (annually), move forward to the prior (N-1) Long Term RU during your annual change window, then continue monthly MRPs on that new Long Term RU.

For additional details see MOS Note 3106469.1.

Policy summary:

  • Stay on an Long Term RU for 12 months
  • Install the latest MRP for the prior (N-1) Long Term RU every month
  • Install the prior (N-1) Long Term RU and the latest MRP for that RU every year during your annual change window
Date Released RU Installed RU
26-Jan 19.30 19.28 + MRP5 ➞ 19.28 + MRP6
26-Feb 19.28 + MRP6 ➞ 19.28 + MRP7
26-Mar 19.28 + MRP7 ➞ 19.28 + MRP8
26-Apr 19.31 19.28 + MRP8 ➞ 19.28 + MRP9
26-May 19.28 + MRP9 ➞ 19.28 + MRP10
26-Jun 19.28 + MRP10 ➞ 19.28 + MRP11
26-Jul 19.32 (Long Term RU) 19.28 + MRP11 ➞ 19.28 + MRP12
26-Aug 19.28 + MRP12 ➞ 19.28 + MRP13
26-Sep 19.28 + MRP13 ➞ 19.28 + MRP14
26-Oct 19.33 19.28 + MRP14 ➞ 19.28 + MRP15
26-Nov 19.28 + MRP15 ➞ 19.28 + MRP16
26-Dec 19.28 + MRP16 ➞ 19.28 + MRP17
27-Jan 19.34 19.28 + MRP17 ➞ 19.28 + MRP18
27-Feb 19.28 + MRP18 ➞ 19.32 + MRP7
27-Mar 19.32 + MRP7 ➞ 19.32 + MRP8
27-Apr 19.35 19.32 + MRP8 ➞ 19.32 + MRP9
27-May 19.32 + MRP9 ➞ 19.32 + MRP10
27-Jun 19.32 + MRP10 ➞ 19.32 + MRP11
27-Jul 19.36 (Long Term RU) 19.32 + MRP11 ➞ 19.32 + MRP12
27-Aug 19.32 + MRP12 ➞ 19.32 + MRP13
27-Sep 19.32 + MRP13 ➞ 19.32 + MRP14
27-Oct 19.37 19.32 + MRP14 ➞ 19.32 + MRP15
27-Nov 19.32 + MRP15 ➞ 19.32 + MRP16
27-Dec 19.32 + MRP16 ➞ 19.32 + MRP17
28-Jan 19.38 19.32 + MRP17 ➞ 19.32 + MRP18
28-Feb 19.32 + MRP18 ➞ 19.36 + MRP7

The following graph for policy example 4 shows Oracle Database 19c quarterly RU and monthly MRP releases and their release month over 38 months. It depicts the monthly Long Term RU, N‑1 policy, where you run on a designated Long Term RU for about a year with monthly MRPs, then move annually to the prior Long Term RU and continue monthly MRPs.


Graph of monthly long term RU updates with apply lag n minus one

Determine Software Health

Once a software maintenance policy is established evaluate the installed software against your policy and Oracle’s official recommendation to determine software health:

  • Determine if installed software is behind Oracle's recommended proactive updates.
  • Determine if critical or important fixes announced by Oracle are missing for the base product software (e.g., Oracle Database).
  • Determine if critical or important fixes announced by Oracle are missing for specific Oracle product components or features (e.g., Data Guard for Oracle Database).

Evaluate software health frequently (e.g., weekly), more frequently than your Apply Frequency, to identify newly recommended critical or important fixes shortly after they are published.

Oracle Database and Grid Infrastructure Software

Oracle recommends using automated tools integrated with Oracle Update Advisor (OUA) to assess software health for Oracle Database and Oracle Grid Infrastructure. This approach reduces manual tracking and improves consistency.

Automated tools such as Database Configuration Assistant (DBCA/DBCACTL) and Fleet Patching and Provisioning (FPP), when integrated with OUA, evaluate the installed software against your defined maintenance policy and Oracle’s official recommendation to determine software health status. Using automated tools integrated with OUA significantly simplifies identifying missing critical or important fixes.

Software Health Status

Status Action
GREEN

No action needed

Installed software meets Oracle’s recommendation based on your policy.
YELLOW

Update is recommended

Installed software is missing important fixes or is behind Oracle’s recommendation by one cycle.
RED

Update is required

Installed software is missing critical fixes or is behind Oracle’s recommendation by more than one cycle.

Examples

In the following examples:

  • Installed software is Oracle Database Release Update 23.8. Oracle Database Release Update 23.9 is the latest version released and recommended. Therefore, the installed RU is one behind the latest RU.
  • When Policy is not specified the default is used (Apply frequency = Quarterly, Update lag = No lag).

DBCA Example using default policy

$ dbca -managePatches -checkPatchStatus -silent
   "softwareHealth" : "YELLOW",
   "comment" : "One cycle behind your policy.",
   "recommendedVersion" : "23.9"

FPP Example (using FPP Server Mode) using default policy

$ rhpctl evaluate patch -image DB238000
Software health status: "YELLOW"
Software health comment: "One cycle behind your policy."
Software Type: "DB"
Current version: "23.8.0.25.4"
Recommended version: "23.9"

DBCACTL Example using semiannual apply frequency

$ dbcactl -managePatches -checkPatchStatus -applyFrequency SEMI_ANNUAL
  "softwareHealth" : "GREEN"

For additional details see Streamlining Your Update Experience with Oracle Update Advisor.

Alternative/Complementary Methods

If automated evaluation tools are not in use, administrators can track recommendations and health status manually by using:

  • Exachk – Run Exachk regularly and review recommended software checks.
  • MOS documents - Proactively monitor prioritized MOS notes for proactive software update release announcements, critical fixes and recommended fixes, and replacement updates.

For additional details see Obtain Recommended Software.

Exadata Software

For Exadata environments, Oracle recommends:

  • Exachk – Run Exachk and review recommended software checks.
  • MOS documents - Proactively monitor prioritized MOS notes for proactive software update release announcements, critical and recommended fixes, or replacement fixes.

For additional details see Obtain Recommended Software.

Obtain Recommended Software

Selecting and deploying the correct Oracle software versions and patches is essential for availability, security, and support. Use Oracle’s automated tooling or validated MOS resources to determine the right targets and to obtain secure, policy-compliant software.

Key Practices

  • Use automated tools (DBCA, FPP with Oracle Update Advisor) wherever possible to minimize manual errors.
  • For environments where automation is not feasible, carefully reference Exachk output and relevant MOS notes.
  • Always verify downloaded artifacts using Oracle’s provided digital signatures and checksums.

Database and Grid Infrastructure (On-Premises)

Recommended Approach – DBCA or FPP with Oracle Update Advisor

Obtain recommended software as a Gold Image with Oracle Update Advisor functionality. Use Gold Images to perform updates in the recommended out-of-place, image-based manner.

  1. Generate a Gold Image containing recommended software (which matches your policy and includes all required patches).
  2. Download the recommended Gold Image.

Gold images are automatically tailored:

  • Include Oracle’s recommended Release Update and any necessary interim/critical patches.
  • Automatically resolve patch conflicts and retain or add customer-specific patches if specified.

Examples

DBCA Example

$ dbca -managePatches -generateGoldImage -silent
$ dbca -managePatches -downloadGoldImage -goldImageDownloadLocation /u01/swdepot -silent

FPP Example (using FPP Server Mode)

$ rhpctl evaluate patch -image DB238000 -generateimage -importtoimage DB239000

Feature-Specific Database Recommendations (Manual Process Only)

  • For additional features such as Data Guard or Data Pump, Oracle Update Advisor does not currently provide feature-specific recommendations.
  • Review MOS note 2781612.2 to determine additional recommended interim patches for database features beyond core database functionality, such as Data Guard or Data Pump.

If using manual methods for core database software:

An alternative approach is to review relevant MOS notes, run Exachk, and download either gold images or recommended interim patches.

  • Review relevant MOS notes and identify recommended software.
    • Review MOS note 888.1 for Recommended Release, Release Update (RU), and Monthly Recommended Patch (MRP)
    • Review MOS note 1270094.1 for Recommended critical issue updates
    • Review MOS note 555.1 for Recommended important issue updates
    • Review MOS note 742060.1 for error correction support end dates
  • Run Exachk and review recommended software checks.
    • Review MAA Scorecard section for Recommended Release and Release Update (RU)
    • Review Critical issues section for Recommended critical issue updates
    • Review Important bug fixes check for Recommended important issue updates
  • Adjust recommendation to adhere to your software maintenance policy.
  • Follow MOS Note 2915366.2 to request and download gold images for Database and Grid Infrastructure software homes, supplying your inventory and the recommended software manually identified above as candidate patches.

Exadata (On-Premises)

Review relevant MOS notes, run Exachk, and download recommended updates.

  • Review relevant MOS notes and identify recommended software.
    • Review MOS note 888828.1 for Recommended Exadata software
    • Review MOS note 1270094.1 for Recommended critical issue updates
    • Review MOS note 556.1 for Recommended important issue updates
  • Run Exachk and review recommended software checks.
    • Review MAA Scorecard section for Recommended Release and Release Update (RU)
    • Review Critical issues section for Recommended critical issue patches
    • Review Important bug fixes check for Recommended important issue patches
  • Adjust recommendation to adhere to your software maintenance policy.
  • Follow MOS Note 888828.1 to download recommended updates for Exadata compute nodes, storage servers, and switches directly from MOS.

Apply Software Update

Well-planned, tested, and properly executed software updates are crucial to maximizing uptime and minimizing business disruption. Wherever possible, Oracle recommends out-of-place, gold image-based patching—especially for clustered systems—to ensure safe rollbacks and rapid issue resolution.

Key Practices

  • Before updating software run Exachk/Orachk and correct configuration that does not follow recommended best practices.
  • Follow client failover best practices to reduce application-level impact during rolling updates that disrupt database instance connectivity. See Continuous Availability for Applications for details.
  • Test the update and rollback process in a non-production environment with production-like workload and configuration.
  • Use Data Guard Standby-First Patch Apply approach to minimize risk and primary database impact when updating mission critical systems. See MOS note 1265700.1 for details.
  • Take system and database backups immediately before software changes.
  • Always validate, backup, and have a proven rollback plan before making software changes.
  • Use Fleet Patching and Provisioning (FPP) or Database Configuration Assistant (DBCA) automation to ensure consistency and reduce manual errors.
  • Use DBCA for out-of-place, gold image-based Database updates on standalone/non-clustered systems.
  • Use FPP for coordinated, out-of-place, rolling, gold image-based Database and Grid Infrastructure updates on clustered environments such as Oracle RAC and Exadata.
  • Apply online/in-place updates only for specific patch types or situations where minimal disruption is required. See MOS note 761111.1 for details.

Software Update Method Selection: Benefits and Tradeoffs

Table 45-1 Database Software on Non-Clustered Systems (Standalone Hosts)

Method Benefits/Tradeoffs

Out-of-place (gold image) with DBCA

(Recommended)
  • Fast, simple, easy rollback
  • Requires extra disk space
$ dbca -moveDatabase -sourceDB <dbname> -silent
In-place (patch) with OPatch
  • Minimal extra disk space
  • Higher risk, patch conflicts, slower apply/rollback
Online in-place (patch) with OPatch
  • No database downtime or database connection disruption
  • Limited to supported patches (MRP/interim)

Table 45-2 Database Software on Clustered Systems (Oracle RAC/Exadata)

Method Benefits/Tradeoffs

Out-of-place (gold image), RAC rolling with FPP

(Recommended)
  • Fast, simple, full cluster orchestration, easy rollback
  • Requires extra disk space
$ rhpctl move database –sourcewc <src> –patchedwc <dest>
In-place (patch), RAC rolling with OPatch/OPatchAuto
  • Minimal extra disk space, no database downtime
  • Higher risk, patch conflicts, slower apply/rollback, complex rollback
Online in-place (patch) with FPP
  • No database downtime or database connection disruption
  • Limited to supported patches (MRP/interim)
Non-rolling with FPP
  • All updates applied at once, reduced planned maintenance time
  • Full database downtime

Table 45-3 Grid Infrastructure Software on Clustered Systems (Oracle RAC/Exadata)

Method Benefits/Tradeoffs

Out-of-place (gold image), RAC rolling with FPP

(Recommended)
  • Fast, simple, full cluster orchestration, easy rollback
  • Requires extra disk space
$ rhpctl move gihome –sourcewc <src> –destwc <dest>
Zero-downtime out-of-place (gold image), RAC rolling with FPP
  • No database connection disruption
  • Requires extra disk space
\
$ rhpctl move gihome –sourcewc <src> –destwc <dest> -tgip
In-place (patch), RAC rolling with OPatch/OPatchAuto
  • Minimal extra disk space
  • Higher risk, patch conflicts, slower apply/rollback, complex rollback

Table 45-4 Exadata System Software

Method Benefits/Tradeoffs

Rolling update with patchmgr or FPP

(Recommended)

  • Storage servers
  • Database servers
  • Network fabric switches
  • No database downtime, simple, full system orchestration
$ patchmgr --dbnodes <group_file> --repo <repo>
 --upgrade --target_version <version> --rolling

Live update with patchmgr or FPP

  • Database servers
  • No database connection disruption, supports partial updates to address security issues
  • Outstanding work update items cannot be completed online and require a system reboot
$ patchmgr --dbnodes <group_file> --repo <repo> --upgrade
 --target_version <version> --rolling --live-update-target full

Non-rolling with patchmgr or FPP

  • Storage servers
  • Database servers
  • Network fabric switches
  • All updates applied at once, reduced planned maintenance time
  • Full system downtime