Oracle Patching, Demystified: CPU, RU, RUR — and What Changed in 2026

Few Oracle topics generate as much confident, contradictory advice as patching. Someone tells you to “apply the CPU,” someone else insists you want “the latest RU,” a third person mentions RURs, and the blog you found while searching describes a proactive-patch program that Oracle deprecated in 2023. The vocabulary has been renamed twice, one whole track has been discontinued, and — as of May 2026 — Oracle added a monthly security cadence on top of the quarterly one. It’s no wonder people are unsure what they’re supposed to be installing.

Here’s the whole map, current as of mid-2026: what each acronym actually means, which ones still matter, which one you apply by default, and how a patch physically goes onto a database without taking the outage everyone’s afraid of.

The short version. Apply the latest Release Update (RU) — the quarterly proactive bundle (security + regression + optimizer/functional fixes). It’s the second digit of your version: 19.26.0.0.0 is RU 26. RUR (the old “security-only” track) is deprecated — don’t plan around it; Monthly Recommended Patches (MRP) replaced it for staying current between RUs. “CPU” is the quarterly date (third Tuesday of Jan/Apr/Jul/Oct), not a database patch you apply separately. New in 2026: CSPUs deliver security fixes monthly, in between the quarterly releases. You install it all with OPatch (the binary side) and then datapatch (the SQL side people forget) — and you avoid downtime with RAC rolling or Data Guard standby-first patching.

The vocabulary got renamed — twice

Most of the confusion is historical. The names changed, but the old names never left people’s mouths (or their runbooks). Here’s the whole lineage in one place:

Two things fall out of that table immediately. First, “CPU” means two different things depending on who’s talking — a legacy patch type and the quarterly date — which is most of why the word causes arguments. Second, RUR is a dead end: if a guide is telling you to weigh “RU vs RUR,” it was written before 2023 and hasn’t been updated. Let’s take the live ones in order.

RU: the one you actually apply

A Release Update is the quarterly proactive patch bundle, and for the overwhelming majority of databases it is the thing you install. An RU is cumulative — the latest one contains every fix from every RU before it — and it carries three kinds of change:

• Security fixes — the vulnerabilities disclosed on the quarterly date.
• Regression / bug fixes — the accumulated, tested defect fixes.
• Optimizer and functional fixes — the reason an RU is more than “just security,” and the reason you test it rather than pushing it blindly to production.

RUs ship quarterly, on the Critical Patch Update dates — the third Tuesday of January, April, July, and October. You can tell your RU level from the version number, because Oracle encodes it there:

19 . 26 . 0 . 0 . 0
│    │    │   │   └─ (optional) release-date stamp
│    │    │   └───── reserved (always 0)
│    │    └───────── RUR level  (0 = no RUR; the RUR track is discontinued)
│    └────────────── RU level   (26 = the 26th quarterly Release Update)
└─────────────────── release    (19 = Oracle Database 19c)

So 19.26.0.0.0 is “19c, Release Update 26.” When someone asks “what patch level are you on,” this is the answer. Check it in one line:

SELECT version_full FROM v$instance;   -- e.g. 19.26.0.0.0  (19c+; use `version` pre-19c)

Oracle’s standing recommendation is blunt and worth internalizing: keep current on the latest RU. An estate three years behind on RUs isn’t “stable” — it’s carrying three years of unpatched vulnerabilities and known-defect exposure, and the eventual jump is harder, not easier.

RUR is gone — read this before you follow an old blog

For years the advice was “RU is the aggressive track, RUR is the conservative one — take RUR if you want security without the functional changes.” That advice is out of date. Oracle deprecated Release Update Revisions and discontinued them after January 2023. The third digit of the version number that used to carry the RUR level now just sits at zero.

If you have an old change-management doc that says “apply the RUR,” that’s the single clearest sign it needs a rewrite. What replaced it is the MRP.

MRP: the monthly top-up between RUs

A Monthly Recommended Patch is Oracle’s mechanism for staying current between the quarterly RUs. It took over RUR’s job starting with RU 19.17 in October 2022. The characteristics that matter:

• Cumulative, released monthly for up to six months following each RU.
• It does not change your release number. Your version stays 19.26.0.0.0; the MRP is tracked separately. (This trips people up — after an MRP, version_full looks unchanged.)
• 19c, Linux x86-64 only — it’s not a universal program.

That leaves you two sane strategies, and picking between them is a real decision:

If you do nothing else, do RU-only, on time. MRP is an upgrade to that discipline, not a substitute for it.

”CPU” is a date, not a database patch

This is the one that ends arguments. In the modern model, you do not download and apply a thing called “the CPU” to your database. Critical Patch Update is the name of the quarterly security event — the third Tuesday of January, April, July, and October — on which Oracle publishes its security advisory across all its products. For the database, that quarter’s security content is delivered inside the RU. So “apply the July CPU” and “apply the July RU” are, for a DBA, describing the same action from two different vocabularies. When someone hands you “the CPU,” what they mean is the RU for that quarter.

New in 2026: monthly CSPUs

Here’s what most existing write-ups don’t have yet. Beginning May 28, 2026, Oracle added a monthly security release called the Critical Security Patch Update (CSPU), delivered on the third Tuesday of each month. The point is speed: instead of waiting up to three months for the next quarterly date, you can pick up a smaller, security-focused set of fixes for the most serious vulnerabilities as they’re addressed. Oracle’s first CSPU, in May 2026, covered dozens of CVEs across its product line.

The relationship to the old cadence is the part to get right:

• CSPUs complement the quarterly program — they do not replace it.
• The quarterly Critical Patch Update continues, and each quarterly release rolls up the CSPUs issued since the last one.
• So the security cadence effectively went from quarterly to monthly, for shops that want to move that fast.

flowchart LR
RUq[Quarterly RU<br/>Jan · Apr · Jul · Oct<br/>full proactive bundle] --> C1[Monthly CSPU<br/>security-only]
C1 --> C2[Monthly CSPU<br/>security-only]
C2 --> RUn[Next quarterly RU<br/>rolls up prior CSPUs]
RUn --> C3[Monthly CSPU...]

The practical read: RU is still your proactive backbone — you take it quarterly and it carries the functional/regression fixes. CSPU is the fast lane for security, for teams whose risk posture (or auditors) won’t tolerate waiting a quarter to close a critical CVE. Most estates will keep taking RUs quarterly and reach for a CSPU only when a specific high-severity vulnerability lands mid-quarter.

How a patch actually goes on: OPatch, then datapatch

A Release Update is applied in two stages, and the second one is the step that gets skipped and causes 2 a.m. confusion.

Stage 1 — the binary patch, with OPatch. OPatch (and OPatchAuto for Grid Infrastructure/RAC) patches the Oracle home — the software on disk. Oracle now recommends out-of-place patching: install the new RU into a fresh Oracle home and move the database to it, rather than patching the home in place. It’s safer to roll back (you still have the old home) and it shortens the downtime window. For larger fleets — RAC, Exadata, Data Guard — Oracle points you at Fleet Patching and Provisioning (FPP) to do this at scale.

Stage 2 — the SQL side, with datapatch. Patching the binaries is only half the job. Many patches also carry SQL changes to the data dictionary, and those are applied by datapatch, which you run against the running database after the binary patch. Skipping it is the classic mistake: the software is patched, but the database’s SQL registry isn’t, and you’re in an inconsistent, unsupported state. datapatch records what it did in DBA_REGISTRY_SQLPATCH — which is exactly where you look to prove a patch’s SQL actions actually ran:

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

If the RU you think you applied isn’t in that view with status = SUCCESS, you have not finished patching — you’ve done stage 1 and forgotten stage 2.

Practice reading patch state. The no-Docker patching forensics lab hands you six real opatch lspatches / DBA_REGISTRY_SQLPATCH transcripts to diagnose — the datapatch gap above, a stale RU, a RAC node mismatch, a WITH ERRORS status, and the “apply the RUR” trap — with a grade.sh self-check. Just text and bash; no database required.

Patching without an outage

“We can’t take the downtime” is the reason patches get deferred until they become a security incident. But for any serious configuration, Oracle already gives you a way to patch with little or no service interruption — and it reuses the high-availability architecture you (should) already have.

• RAC — rolling patching. In a Real Application Clusters database, you patch one node at a time: drain and stop an instance, patch its home, bring it back, move to the next. The service stays up on the surviving nodes throughout. (This is one of the quieter arguments for RAC — see where it fits against Data Guard in The Oracle HA Decision Tree.)
• Data Guard — standby-first patching. With a physical standby you patch the standby’s Oracle home first, then perform a switchover so the patched home becomes primary, then patch the old primary’s home and switch back if you like. Your only user-visible interruption is the switchover itself — seconds, not an outage.

Two details on the Data Guard path that catch people out: you cannot run datapatch on a physical standby (even an open, Active Data Guard one) — the SQL actions run on the primary and ship through redo — so datapatch happens after the switchover, against the new primary. And the sequence is specifically: restart the standby(s) in the patched home → switch over → restart the former primary in the patched home → run datapatch.

flowchart TD
A{Which configuration?}
A -- "Single instance" --> B[Out-of-place RU<br/>then datapatch<br/>in a maintenance window]
A -- "RAC" --> C[Rolling patch<br/>one node at a time<br/>service stays up]
A -- "Data Guard" --> D[Standby-first:<br/>patch standby home,<br/>switchover,<br/>patch old primary,<br/>datapatch on new primary]
A -- "Large fleet / Exadata" --> E[Fleet Patching and<br/>Provisioning FPP]

What teams get wrong

• Forgetting datapatch. The binaries are patched, the SQL registry isn’t, and the database is in an unsupported half-patched state. Always verify DBA_REGISTRY_SQLPATCH.
• Planning around RUR. It’s been discontinued since January 2023. If your process references it, your process is stale.
• Treating “CPU” as a separate database patch. For the database, the quarter’s security content is in the RU. There’s no extra “CPU” to apply on top.
• Sitting years behind “for stability.” Old RUs aren’t stable, they’re exposed. The longer you wait, the bigger and riskier the eventual jump.
• In-place patching by default. Out-of-place is Oracle’s recommendation — easier rollback, shorter downtime. Reserve in-place for when you truly can’t spare the disk.
• Owning no cadence. “We patch when we get to it” is how a critical CVE stays open for a year. Decide RU-only vs RU+MRP, decide whether CSPUs are in scope, and put it on a calendar.

The one-paragraph version

Apply the latest Release Update — it’s the second digit of your version (19.26.0.0.0 = RU 26), it’s cumulative, and it ships quarterly on the third Tuesday of Jan/Apr/Jul/Oct. RUR is discontinued; MRP is the monthly way to stay current between RUs (19c/Linux). “CPU” is the quarterly date, not a database patch — its DB content is in the RU. CSPUs (new in May 2026) add a monthly security cadence between the quarters. Install with OPatch (out-of-place), then never skip datapatch, and prove it landed in DBA_REGISTRY_SQLPATCH. Avoid downtime with RAC rolling or Data Guard standby-first patching. Then do it on a schedule — the patch you defer is the vulnerability you keep.

Patching is where the Security & Ops discipline is most visible — and most deferred. Get the vocabulary straight, pick a cadence, and lean on your HA architecture to remove the downtime excuse. For where RAC and Data Guard fit in the first place, start with The Oracle HA Decision Tree; for the switchover that makes standby-first patching a seconds-long event, see Switchover vs Failover.