Detect When Software Needs To Be Updated

Defining a software maintenance policy and proactively detecting outdated software are critical for security, stability, availability, and compliance. Oracle recommends automating detection and alerting by using Oracle tools and selected My Oracle Support resources.

Key Practices

Define a Software Maintenance Policy

Establish a documented software maintenance policy that reflects compliance requirements, risk tolerance, service level agreements, and maintenance-window constraints. Review the policy whenever business or operational requirements change.

A comprehensive policy should define the following directives:

Security Target CVSS Range

| — | — |

SecurityCritical CVSS 9.0 - 10.0
SecurityHigh+ CVSS 7.0 - 10.0 (Default)
SecurityMedium+ CVSS 4.0 - 10.0
SecurityLow+ CVSS 0.1 - 10.0

Oracle Database and Grid Infrastructure Software

Oracle Database and Oracle Grid Infrastructure require a defined, repeatable software maintenance policy that balances security, stability, availability, and change rate. The policy should specify how often proactive updates are applied, how far behind the latest recommended update the environment is allowed to operate, and what severity of missing 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 rollback, and aligns with MAA high availability principles.

Policy Scenarios

The following tables show examples of software maintenance goals and the policy directives used to achieve them.

Apply Frequency Description
Quarterly Update quarterly
Semiannually Update twice 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
Monthly Supported Supported Not supported1
Monthly Long Term RU Supported Supported Not supported2

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

2Not 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

This is the default and most common policy. Adopt the latest RU each quarter as it is released, operate on that RU for approximately three months, and advance to the next RU at the next quarterly release. This keeps security and stability fixes current with no intentional lag.

Policy summary:

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 graph 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.

Description of image follows

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

Choose this policy when a conservative cadence is required. 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::

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 reduces early-adoption risk by staying one RU behind while still applying the latest monthly recommended patches (MRPs) for that RU. Operate on a given RU for approximately one quarter, and apply the current MRP for that RU each month. When a new quarterly RU is released, move to the prior RU for the next quarter and continue monthly patching on that RU.

Policy summary:

MRP details:

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.

Description of image follows

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 Long Term Support Model for 19c Database Release Updates (RU) (KB625385)

Policy summary:

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.

Description of image follows

Determine Software Health

After a software maintenance policy is established, evaluate installed software against that policy and Oracle’s current recommendations to determine software health.

Evaluate whether:

Evaluate software health frequently, such as weekly, and more frequently than the planned apply frequency. This helps 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 DBCA/DBCACTL, and FPP can integrate with Oracle Update Advisor to evaluate installed software against the defined policy and Oracle’s current recommendation to determine software health status. Customers can also integrate Oracle Update Advisor with their own custom software maintenance orchestration by using the Oracle Update Advisor API, as described in My Oracle Support article KB886700. Using automation simplifies the identification of missing critical or important fixes and helps drive consistent, policy-aware maintenance decisions.

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:

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:

For additional details see Obtain Recommended Software.

Exadata Software

For Exadata environments, Oracle recommends:

For additional details see Obtain Recommended Software.