Oracle Database 19c Security Hardening – Part 13

By | | ,

Oracle Patch Management: RU, CPU, OPatch, and Security Lifecycle

A secure Oracle database is not only about configuration. It is also about maintaining the software itself.

Every quarter, Oracle publishes security fixes through Critical Patch Updates (CPU) and Release Updates (RU). These patches address vulnerabilities discovered internally and by the security community.

During database security assessments, one of the first questions I ask is:

“What is your current Oracle Database Release Update level?”

Surprisingly often, the answer is unknown.

Many production databases continue running for years without applying security patches, increasing exposure to known vulnerabilities.

In this article, we will review Oracle 19c patch management, how to verify the current version, how to apply Release Updates safely, and how to build a repeatable patching process.

Understanding Oracle 19c Patch Terminology

Before managing patches, it is important to understand Oracle terminology.

Release Update (RU)

A Release Update is Oracle’s recommended cumulative patch bundle.

It contains:

  • Security fixes
  • Bug fixes
  • Stability improvements
  • Optimizer fixes
  • General database improvements

Example:

Oracle Database 19c Release Update 19.29.0.0.0

Oracle recommends staying current with recent RUs.

Critical Patch Update (CPU)

CPU patches contain security vulnerability fixes.

They are released quarterly:

  • January
  • April
  • July
  • October

Security fixes are often included inside Release Updates.

One-Off Patch

A one-off patch addresses a specific issue.

Examples:

  • Specific database bug
  • Performance regression
  • Platform-specific issue

One-off patches should be applied only when required.

Step 1 – Check Current Oracle Database Version

Start by checking the database version.

SELECT banner_full FROM   v$version;

Example:

For detailed information:

SELECT * FROM product_component_version;

Step 2 – Check Installed Database Patches

Oracle stores patch information inside the database.

Run:

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

Example output:

A healthy environment should show successful patch applications.

Step 3 – Check Oracle Home Patches with OPatch

Database patching involves both:

  • Oracle Home binaries
  • SQL changes inside the database

Check Oracle Home patches:

$ORACLE_HOME/OPatch/opatch lsinventory

Example:

...
Interim patches (2) :

Patch  29585399     : applied on Thu Apr 18 08:21:33 CET 2019
Unique Patch ID:  22840393
Patch description:  "OCW RELEASE UPDATE 19.3.0.0.0 (29585399)"
   Created on 9 Apr 2019, 19:12:47 hrs PST8PDT
...
Patch  29517242     : applied on Thu Apr 18 08:21:17 CET 2019
Unique Patch ID:  22862832
Patch description:  "Database Release Update : 19.3.0.0.190416 (29517242)"
   Created on 17 Apr 2019, 23:27:10 hrs PST8PDT
...

Review:

  • Missing patches
  • Failed patches
  • Conflicting patches

Step 4 – Check OPatch Version

Before applying patches, verify OPatch itself.

$ORACLE_HOME/OPatch/opatch version

Example:

OPatch Version: 12.2.0.1.17

OPatch succeeded.

Always use the OPatch version recommended by Oracle for your database release.

An outdated OPatch utility can cause patch failures.

Step 5 – Check Database Compatibility

Before applying an RU, review:

  • Database version
  • Operating system
  • Grid Infrastructure version (for RAC)
  • Application compatibility
  • Backup availability

For RAC environments (run the command on all nodes):

opatch lsinventory

Verify that:

  • All nodes are healthy.
  • Cluster services are running.
  • ASM is operational.

Step 6 – Prepare a Patching Plan

A professional patching process includes:

Before Patch

Checklist:

✓ Confirm current backup
✓ Validate database health
✓ Check filesystem space
✓ Review Oracle documentation
✓ Test patch in non-production
✓ Schedule maintenance window

During Patch

Actions:

  • Stop required services.
  • Apply Oracle Home patches.
  • Execute datapatch.
  • Validate status.

After Patch

Verify:

  • Database opens normally.
  • Applications connect.
  • Invalid objects are checked.
  • Patch registry shows success.

Step 7 – Apply an Oracle Release Update

Typical workflow:

Stop Database Services

Example:

srvctl stop database -db PROD

(for RAC environments)

Apply Binary Patch

Example:

opatch apply

or for RAC:

opatchauto apply

Start Database

srvctl start database -db PROD

Run Datapatch

Connect:

sqlplus / as sysdba
startup

Execute:

$ORACLE_HOME/OPatch/datapatch -verbose

Example:

SQL Patching tool completed successfully

Step 8 – Validate After Patching

Check SQL patch status:

SELECT patch_id, status, description FROM dba_registry_sqlpatch;

Expected:

SUCCESS

Check invalid objects:

SELECT owner, object_name, object_type FROM dba_objects WHERE status='INVALID';

Recompile if required:

@$ORACLE_HOME/rdbms/admin/utlrp.sql

Step 9 – Review Security Fixes

Oracle provides security advisories through Critical Patch Updates.

Security teams should review:

  • CVE vulnerabilities
  • Database vulnerabilities
  • Client vulnerabilities
  • Grid Infrastructure vulnerabilities

The objective is not only applying patches but understanding what risks are being addressed.

Step 10 – Automate Patch Compliance Reporting

For large environments, manual verification is difficult.

Create a simple compliance report:

SELECT instance_name, version FROM v$instance;

Combine with:

SELECT patch_id, description, status FROM dba_registry_sqlpatch;

Generate periodic reports showing:

  • Database version
  • RU level
  • Patch status
  • Missing security updates

RAC Specific Considerations

For Oracle RAC environments:

Before patching:

crsctl check cluster

Verify:

  • Cluster health
  • Voting disks
  • ASM
  • SCAN listeners

For RAC databases, Oracle recommends using:

opatchauto

because it manages:

  • Grid Infrastructure
  • Database Home
  • Cluster coordination

Data Guard Considerations

For Data Guard environments:

Recommended approach:

  1. Patch standby first.
  2. Validate standby.
  3. Switchover.
  4. Patch former primary.

This reduces downtime.

Check Data Guard status:

SELECT database_role, open_mode FROM v$database;

Security Checklist

Before considering patch management mature:

✓ Oracle RU level documented
✓ OPatch inventory reviewed
✓ Quarterly patch process defined
✓ Security advisories monitored
✓ Test environment available
✓ Backup completed before patching
✓ Post-patch validation performed
✓ Patch compliance reports generated

Common Mistakes

Running Old Release Updates

Many companies remain several years behind and expose themselves to known vulnerabilities.

Applying Patches Without Testing

A security patch should never be applied blindly to critical production systems.

Forgetting Datapatch

Installing the binary patch is not enough.

Always execute:

datapatch -verbose

No Rollback Plan

Every production patch must have:

  • Backup
  • Recovery procedure
  • Maintenance plan

Ignoring Grid Infrastructure

In RAC environments, patching only the database home is incomplete.

Conclusion

Patch management is one of the foundations of Oracle security.

A database protected by encryption, auditing, and strong privileges can still be compromised if it runs vulnerable software.

A mature Oracle security program combines:

  • Secure configuration
  • Regular patching
  • Monitoring
  • Documentation
  • Recovery planning

Security is not a project with an end date—it is an operational discipline.

Bookmark the permalink.
Loading Facebook Comments ...

Leave a Reply