Oracle Patching Done Right: Release Updates with OPatch, Datapatch and Zero-Downtime RAC

Unpatched databases are how many breaches and outages start. Yet patching is the task DBAs most often postpone, because a botched patch can take a production system down. It does not have to be scary. Oracle ships security and stability fixes on a predictable quarterly schedule, and there is a well-defined, repeatable process to apply them safely - including on Real Application Clusters with no downtime at all. This guide covers the whole workflow: the terminology, the pre-patch checks that prevent disasters, applying and verifying a Release Update, rolling it through a RAC cluster node by node, and rolling back if something goes wrong.

1. Why Patching Is Not Optional

Every quarter, Oracle publishes fixes for security vulnerabilities and stability bugs. Attackers read those same advisories, so an unpatched database is a known, documented target. Beyond security, many of the bugs fixed are the exact "it randomly hung" or "the optimizer picked a terrible plan" problems that DBAs chase for weeks. Patching is preventive maintenance, and skipping it does not remove risk - it just defers it to a worse moment.

The reason patching gets postponed is fear of breaking production. The cure for that fear is process. A patch applied with proper checks, a backup, and a known rollback path is a low-drama, repeatable task.

2. The Terminology You Need

Oracle's patch vocabulary confuses newcomers, so let's make it concrete:

• Release Update (RU): the main quarterly patch bundle - security plus regression-tested fixes. This is what most sites apply.
• Release Update Revision (RUR): a smaller follow-up to an RU with just additional fixes, for sites that want to stay one step more conservative.
• OPatch: the tool that installs patches into the Oracle Home (the software binaries on disk).
• Datapatch: the tool that applies the SQL-level changes a patch needs inside the database (data dictionary, packages).
• OJVM patch: a separate patch for the in-database Java VM, often applied alongside the RU.

The key mental model: OPatch changes the software, Datapatch changes the database. A patch is only truly applied when both have run.

3. Pre-Patch Preparation - Where Safety Comes From

Almost every patching disaster traces back to a skipped pre-check. Do these every time, without exception.

-- 1. Update OPatch itself first - RUs often need a recent OPatch
$ORACLE_HOME/OPatch/opatch version

-- 2. Record what is currently installed (keep this output)
$ORACLE_HOME/OPatch/opatch lsinventory

-- 3. Check the new patch for conflicts BEFORE applying
cd /stage/patch/PATCH_NUMBER
$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./

-- 4. Confirm free space in the Oracle Home and archive area

And the non-negotiable step: take a backup before you patch. At minimum a fresh RMAN backup of the database, and ideally an OS-level copy or snapshot of the Oracle Home so you can restore the binaries quickly. Read the patch README fully - it lists version-specific steps that generic guides cannot.

4. Applying a Release Update (Single Instance)

With checks passed and a backup in hand, the mechanics are straightforward. Shut down the databases and listeners running from that Oracle Home, then apply.

-- Stop databases and listener using this ORACLE_HOME
srvctl stop database -d ORCL     # or SHUTDOWN IMMEDIATE
lsnrctl stop

-- Apply the Release Update to the Oracle Home
cd /stage/patch/PATCH_NUMBER
$ORACLE_HOME/OPatch/opatch apply

-- Bring the database back up
lsnrctl start
srvctl start database -d ORCL    # or STARTUP

5. Datapatch - The Step People Forget

After the binaries are patched and the database is open, run Datapatch to apply the SQL-level changes into the database. Skipping this is the classic mistake that leaves a database in a half-patched state.

-- With the database open, run from the patched Oracle Home
cd $ORACLE_HOME/OPatch
./datapatch -verbose

-- Verify what actually got applied in the database
SELECT patch_id, action, status, description
FROM   dba_registry_sqlpatch
ORDER  BY action_time;

If DBA_REGISTRY_SQLPATCH shows the RU with a status of SUCCESS, the database side is done. In a multitenant setup, Datapatch applies to the CDB and all open PDBs - so make sure every pluggable database you care about was open when it ran, a detail covered in the multitenant guide.

6. Zero-Downtime Patching on RAC

This is where Real Application Clusters earns its licence. Because the same database runs on multiple nodes, you can patch one node at a time while the others keep serving users - a rolling patch with no service outage.

-- Rolling patch, node by node, using opatchauto (run as root)
-- Node 1: opatchauto relocates services, patches, brings it back
$ORACLE_HOME/OPatch/opatchauto apply /stage/patch/PATCH_NUMBER

-- When node 1 is confirmed healthy, repeat on node 2, then node 3...
-- Datapatch runs once after the last node, against the open database

The principle: at no point are all nodes down together. Application connections drain from the node being patched to the surviving nodes, then return. Done carefully, users never notice. This is one of the strongest arguments for RAC in the first place, as discussed in the Oracle RAC guide. Always verify each node is fully back and services have relocated before moving to the next.

7. Rollback - Always Know the Way Back

A patch that misbehaves can be removed. Never start a patch without knowing this path.

-- Roll the software patch out of the Oracle Home
$ORACLE_HOME/OPatch/opatch rollback -id PATCH_NUMBER

-- Then reverse the database changes with Datapatch
cd $ORACLE_HOME/OPatch
./datapatch -verbose

For a whole-database "something is deeply wrong" situation immediately after patching, a guaranteed restore point taken before the patch lets you rewind the entire database in minutes. Layering both - patch rollback for the ordinary case, Flashback for the worst case - is what makes patching low-risk.

8. Common Errors and How to Handle Them

• OPatch conflict detected: a previously applied one-off patch overlaps the RU. The prereq check catches this beforehand; resolve it with the patch's SQL merge or by rolling the conflicting patch, guided by the README.
• OPatch version too old: RUs frequently need a newer OPatch than the base install ships with. Update OPatch first - this is step one for a reason.
• Datapatch reports nothing to do, but the RU is installed: usually the database was not open, or you ran Datapatch from the wrong Oracle Home. Re-run from the patched home with the database open.
• Space failure mid-patch: the Oracle Home filled up. Confirm free space in the pre-checks so this never happens live.

9. How Often Should You Actually Patch?

Applying every Release Update the day it is published is not the goal - staying reasonably current and predictable is. A sane cadence for most production sites is to apply an RU within one to two quarters of its release, once it has spent a little time in the field. Sites that want extra conservatism wait for the Release Update Revision instead, which layers only additional fixes on top of a proven RU.

Whatever cadence you choose, the sequence matters more than the speed. Patch a non-production copy first - dev, then UAT - and let it soak under real workload before production goes anywhere near it. A genuinely critical security fix can justify moving faster, but even then a quick pass through a test environment catches the conflicts that would otherwise surface at the worst time.

Two consistency rules save a lot of pain. Keep every Oracle Home at the same patch level - mismatched RAC nodes or a standby on a different level than its primary is asking for trouble. And with Data Guard, patch the standby first, verify it, then switch over and patch the old primary, so you always have a patched, healthy database to fall back to.

10. A Real Quarter: Patching a Bank Core With No Outage

A banking client on a three-node RAC cluster needed to stay current on quarterly security RUs, but the core system could not take a maintenance outage. The approach was a disciplined rolling patch: update OPatch, run conflict and prerequisite checks against a staging copy, take an RMAN backup plus a guaranteed restore point, then apply the RU one node at a time with opatchauto, confirming service relocation and node health at each step. Datapatch ran once after the final node, and DBA_REGISTRY_SQLPATCH confirmed success. Users transacted throughout; the only visible sign was a brief connection rebalance. That is patching as it should be - routine, evidence-based, and invisible to the business. It pairs naturally with a regular health check and a hardened security baseline.

Frequently Asked Questions

What is the difference between OPatch and Datapatch?

OPatch installs the patch into the Oracle Home - it changes the software binaries on disk. Datapatch applies the matching SQL-level changes inside the database, such as data dictionary and package updates. A Release Update is only fully applied when both have run; running OPatch alone leaves the database half-patched.

What is an Oracle Release Update (RU)?

A Release Update is Oracle's main quarterly patch bundle, containing security fixes and regression-tested stability fixes for a release. Most sites apply RUs to stay current. A Release Update Revision (RUR) is a smaller, more conservative follow-up with only additional fixes on top of a given RU.

Can I patch Oracle RAC without downtime?

Yes. Because RAC runs the same database on multiple nodes, you apply the patch one node at a time - a rolling patch - so the surviving nodes keep serving users throughout. Tools like opatchauto relocate services off the node being patched and back afterwards, and Datapatch runs once against the open database at the end.

How do I verify a patch actually applied to the database?

Query DBA_REGISTRY_SQLPATCH after running Datapatch. It lists each patch, the action, and whether the status is SUCCESS. On the software side, opatch lsinventory shows the patch installed in the Oracle Home. Both together confirm a complete apply.

What should I do before applying any Oracle patch?

Update OPatch, record the current inventory with opatch lsinventory, run the conflict and prerequisite checks against the new patch, confirm free space, and take a backup - an RMAN backup and ideally a copy of the Oracle Home, plus a guaranteed restore point. Read the patch README fully for version-specific steps.