Oracle Database Patching – Complete Interview Preparation Guide

Quick Summary

Oracle database patching is a critical DBA responsibility involving applying updates to fix bugs, security vulnerabilities, and add new features.
This guide covers patch types, strategies, procedures, and best practices for Oracle 19c.

1. PATCHING FUNDAMENTALS

What is Patching?

Definition:
Patching is the process of applying software updates to Oracle Database to fix bugs, security vulnerabilities, or add minor enhancements.

Why Patching is Critical

• Security: Fix critical vulnerabilities
• Stability: Resolve known bugs
• Performance: Improve database performance
• Support: Stay within Oracle support policies
• Compliance: Meet regulatory requirements

Simple Analogy

Think of patching like updating your phone’s operating system.
You get bug fixes, security updates, and sometimes new features, without changing the core version.

Patch vs Upgrade

2. TYPES OF PATCHES (Oracle 19c)

A. Release Update (RU)

Most Common

What it is

• Cumulative patch including all previous fixes
• Released quarterly (Jan, Apr, Jul, Oct)
• Contains bug fixes and security fixes
• Replaces old PSU (Patch Set Update)

Naming Convention

Database Release Update 19.21.0.0.0

        ↓           ↓
   Base Version   RU Number

Characteristics

• Cumulative (includes all previous RUs)
• Proactive patching strategy
• Requires database downtime
• Recommended for most environments

Release Schedule

• January RU: 19.22
• April RU: 19.23
• July RU: 19.24
• October RU: 19.25

Apply Method

• Download from My Oracle Support (MOS)
• Apply using OPatch utility
• Database restart required

B. Release Update Revision (RUR)

What it is

• Emergency patch on top of RU
• Released between quarterly RUs if critical issue found
• Contains minimal fixes

Example

19.21.0.0.0 (RU) → 19.21.0.1.0 (RUR)

When to use

• Critical bug found after RU release
• Cannot wait for next quarterly RU
• Rare, used only for urgent fixes

C. One-Off Patch (Individual Bug Fix)

What it is

• Single patch for a specific bug
• Not cumulative
• Applied on top of RU/RUR

Characteristics

• Targets one or few related bugs
• Small size (few MB)
• Quick to apply
• Can cause conflicts with other patches

Use Case

• Issue: Specific bug affecting your application
• Solution: Apply one-off patch for that bug only

Important Note

• Always apply on top of latest RU
• Check for conflicts before applying
• May need to reapply after next RU

D. Critical Patch Update (CPU)

Legacy

What it is

• Security-only patch
• Released quarterly (same schedule as RU)
• Deprecated in favor of RU

Why Deprecated

• RU now includes all security fixes
• Simpler to maintain a single patch stream
• CPU still available but not recommended

Migration Path

• Old: CPU (security only)
• New: RU (security + bug fixes)

E. Patch Set Update (PSU)

Legacy

What it is

• Old cumulative patch (before 12.2)
• Replaced by RU in 18c+

Historical Context

• 11g / 12.1: PSU (old term)
• 18c+: RU (new term, same concept)

F. Bundle Patch

What it is

• Platform-specific cumulative patch
• Used for Exadata, RAC, etc.
• Includes multiple components

Examples

• Grid Infrastructure Release Update (GI RU)
• Exadata Bundle Patch
• Database Bundle Patch

G. Interim Patch

What it is

• Temporary fix before official patch
• Provided by Oracle Support for urgent issues
• Should be replaced by official patch when available

3. OPATCH UTILITY

What is OPatch?

Definition:
OPatch is Oracle’s utility for applying and managing patches to Oracle Home.

Location

$ORACLE_HOME/OPatch/opatch

Key Features

• Apply patches
• Rollback patches
• Query patch information
• Conflict detection
• Prerequisite checking

OPatch Versions

Important

OPatch version must be compatible with Oracle version

Check OPatch Version

$ORACLE_HOME/OPatch/opatch version

Update OPatch

# Download latest OPatch from MOS (Patch 6880880)
cd $ORACLE_HOME
mv OPatch OPatch.old
unzip p6880880_190000_Linux-x86-64.zip

Recommended OPatch Version for 19c

• Minimum: 12.2.0.1.0 or higher
• Always use latest available

Common OPatch Commands

1. Check OPatch Version

opatch version

2. List Applied Patches

opatch lspatches

or detailed view

opatch lsinventory

3. Query Specific Patch

opatch query -all /path/to/patch

4. Check for Conflicts

opatch prereq CheckConflictAgainstOHWithDetail -ph /path/to/patch

5. Apply Patch

opatch apply /path/to/patch

6. Rollback Patch

opatch rollback -id <patch_number>

7. Check Patch Applicable

opatch prereq CheckApplicable -ph /path/to/patch

8. List Patch Details

opatch lspatches -all
opatch lsinventory -detail

9. Validate Oracle Home

opatch util cleanup

4. PATCHING STRATEGIES

A. Out-of-Place Patching

Recommended for Production

What it is

• Create new Oracle Home
• Apply patches to new home
• Switch database to new home
• Keep old home as fallback

Process

Old OH: /u01/app/oracle/product/19.0.0/dbhome_1 (19.3)
    ↓
New OH: /u01/app/oracle/product/19.0.0/dbhome_2 (19.21)
    ↓
Switch database from dbhome_1 to dbhome_2
    ↓
Old home available for rollback if needed

Advantages

• Easy rollback (switch back to old home)
• Zero impact if patch fails
• Can test thoroughly before switching
• Minimal downtime
• Best for production

Disadvantages

• Requires more disk space
• More steps involved
• Need to manage multiple homes

Steps

# 1. Create new Oracle Home
mkdir -p /u01/app/oracle/product/19.0.0/dbhome_2

# 2. Install Oracle software to new home
./runInstaller -silent -responseFile /path/to/response.rsp

# 3. Apply patches to new home
export ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_2
opatch apply

# 4. Shutdown database
sqlplus / as sysdba
SHUTDOWN IMMEDIATE;

# 5. Switch ORACLE_HOME
export ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_2
export PATH=$ORACLE_HOME/bin:$PATH

# 6. Startup database and run datapatch
STARTUP;
EXIT;
$ORACLE_HOME/OPatch/datapatch

# 7. Verify
sqlplus / as sysdba
SELECT * FROM dba_registry_sqlpatch;

B. In-Place Patching

(Traditional)

What it is

• Apply patches directly to existing Oracle Home
• Database uses same home before and after

Process

Oracle Home: /u01/app/oracle/product/19.0.0/dbhome_1
    ↓
Apply patch directly to dbhome_1
    ↓
Database continues using dbhome_1

Advantages

• Less disk space needed
• Simpler process
• Fewer steps

Disadvantages

• Difficult rollback (must manually rollback patch)
• Risk if patch fails
• No easy fallback

Steps

# 1. Shutdown database
sqlplus / as sysdba
SHUTDOWN IMMEDIATE;
EXIT;

# 2. Apply patch
cd /path/to/patch
opatch apply

# 3. Startup database
sqlplus / as sysdba
STARTUP;
EXIT;

# 4. Run datapatch
$ORACLE_HOME/OPatch/datapatch

# 5. Verify
sqlplus / as sysdba
SELECT * FROM dba_registry_sqlpatch;

C. Rolling Patching

(RAC / Data Guard)

What it is

• Patch instances one at a time
• Minimal or zero downtime
• Available for RAC and Data Guard

Use Cases

• RAC: Patch one node at a time, services continue on other nodes
• Data Guard: Patch standby first, then switchover, patch old primary

RAC Rolling Patch Process

Node 1 (Patched) + Node 2 (Running) → Services continue
    ↓
Node 1 (Running) + Node 2 (Patched) → Services continue
    ↓
All nodes patched, minimal downtime

Data Guard Rolling Patch Process

Step 1: Patch standby database
Step 2: Verify standby
Step 3: Switchover to standby (now primary)
Step 4: Patch old primary (now standby)
Step 5: Switchover back (optional)

D. Fleet Patching and Provisioning (FPP)

What it is

• Automated patching framework (19c+)
• Centralized patch management
• Zero-downtime patching

Features

• Gold image management
• Automated out-of-place patching
• Minimal downtime
• Centralized control

Use Case

• Large environments (100+ databases)
• Standardized patching
• Enterprise automation

5. PATCHING PROCESS (Step-by-Step)

Pre-Patching Activities

1. Review Patch README

- Download patch from MOS
- Read README.html thoroughly
- Check prerequisites
- Note known issues
- Review rollback procedure

2. Check Compatibility

-- Check Oracle version
SELECT * FROM v$version;

-- Check applied patches
SELECT * FROM dba_registry_sqlpatch ORDER BY action_time DESC;

3. Check OPatch Version

opatch version
# Update if needed

4. Backup

# Full database backup
RMAN> BACKUP DATABASE PLUS ARCHIVELOG;

# Backup Oracle Home
tar -czf $ORACLE_HOME_backup.tar.gz $ORACLE_HOME

# Backup inventory
tar -czf oraInventory_backup.tar.gz $ORACLE_BASE/oraInventory

5. Check Space

# Check disk space
df -h $ORACLE_HOME
df -h /tmp

# Patches usually need 5-10 GB free space

6. Review Applied Patches

opatch lspatches
opatch lsinventory

7. Check for Conflicts

opatch prereq CheckConflictAgainstOHWithDetail -ph /path/to/patch

8. Schedule Downtime

- Inform users
- Schedule maintenance window
- Prepare rollback plan
- Alert monitoring tools

Applying RU Patch (In-Place)

Step 1: Download and Extract Patch

# Download from MOS
# Example: Patch 35037840 (19.21 RU)

cd /staging
unzip p35037840_190000_Linux-x86-64.zip

Step 2: Set Environment

export ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_1
export ORACLE_SID=ORCL
export PATH=$ORACLE_HOME/bin:$PATH

Step 3: Check Prerequisites

cd /staging/35037840
opatch prereq CheckConflictAgainstOHWithDetail -ph ./
opatch prereq CheckSystemSpace

Step 4: Shutdown Database

sqlplus / as sysdba
SHUTDOWN IMMEDIATE;
EXIT;

# Stop listener
lsnrctl stop LISTENER

Step 5: Apply Patch

cd /staging/35037840
opatch apply

# OPatch will:
# - Check prerequisites
# - Backup files
# - Apply patch
# - Update inventory

Output

Do you want to proceed? [y|n]
y

Patching component oracle.rdbms, 19.0.0.0.0...
Verifying the update...
Patch 35037840 successfully applied.
OPatch succeeded.

Step 6: Start Database

# Start listener
lsnrctl start LISTENER

# Start database
sqlplus / as sysdba
STARTUP;
EXIT;

Step 7: Run Datapatch

$ORACLE_HOME/OPatch/datapatch -verbose

# This applies SQL changes to database dictionary

Datapatch Output

SQL Patching tool version 19.21.0.0.0
Database 19.21.0.0.0 Release Update 35037840 : installed

SQL Patching tool complete

Step 8: Verify Patch

sqlplus / as sysdba

-- Check applied patches
SELECT patch_id, patch_uid, action, status, description
FROM dba_registry_sqlpatch
ORDER BY action_time DESC;

-- Check database version
SELECT * FROM v$version;

-- Check registry components
SELECT comp_name, version, status FROM dba_registry;

Step 9: Post-Patch Tasks

-- Compile invalid objects
@?/rdbms/admin/utlrp.sql

-- Check for invalid objects
SELECT COUNT(*) FROM dba_objects WHERE status = 'INVALID';

-- Gather dictionary stats
EXEC dbms_stats.gather_dictionary_stats;

-- Check alert log for errors

Step 10: Application Testing

- Test critical applications
- Run smoke tests
- Monitor performance
- Check for errors

Rollback Procedure

If Patch Fails or Causes Issues

Method 1: Using OPatch Rollback

# Shutdown database
sqlplus / as sysdba
SHUTDOWN IMMEDIATE;
EXIT;

# Rollback patch
cd $ORACLE_HOME/OPatch
opatch rollback -id 35037840

# Start database
sqlplus / as sysdba
STARTUP;
EXIT;

# Run datapatch for rollback
$ORACLE_HOME/OPatch/datapatch -rollback 35037840

# Verify
SELECT * FROM dba_registry_sqlpatch;

Method 2: Restore from Backup (In-Place)

# Shutdown database
sqlplus / as sysdba
SHUTDOWN ABORT;
EXIT;

# Restore Oracle Home
rm -rf $ORACLE_HOME
tar -xzf $ORACLE_HOME_backup.tar.gz

# Restore inventory
rm -rf $ORACLE_BASE/oraInventory
tar -xzf oraInventory_backup.tar.gz

# Start database
sqlplus / as sysdba
STARTUP;

Method 3: Switch Back (Out-of-Place)

# Shutdown database
SHUTDOWN IMMEDIATE;

# Switch to old Oracle Home
export ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_1

# Start database
STARTUP;

6. DATAPATCH UTILITY

What is Datapatch?

Definition:
Datapatch applies SQL changes to the database dictionary after the binary patch is applied.

Why Needed

OPatch:   Updates Oracle binaries (executables, libraries)
Datapatch: Updates database dictionary (SQL, PL/SQL objects)

When to Run

• After applying RU / RUR
• After applying bundle patches
• After some one-off patches (if README says so)

Datapatch Commands

Run Datapatch

$ORACLE_HOME/OPatch/datapatch

Verbose Mode

$ORACLE_HOME/OPatch/datapatch -verbose

Rollback Datapatch

$ORACLE_HOME/OPatch/datapatch -rollback <patch_id>

Check Status

-- View applied SQL patches
SELECT * FROM dba_registry_sqlpatch
ORDER BY action_time DESC;

-- Check if datapatch needed
SELECT * FROM dba_registry_sqlpatch
WHERE status != 'SUCCESS';

Datapatch Process

What Datapatch Does

1. Analyzes installed binary patches
2. Identifies required SQL changes
3. Applies SQL scripts to database
4. Updates DBA_REGISTRY_SQLPATCH
5. Validates completion

Output

SQL Patching tool version 19.21.0.0.0 Production on Thu Jan 30 10:15:23 2025
Copyright (c) 2012, 2024, Oracle.  All rights reserved.

Connecting to database...OK
Determining current state...done

Currently installed SQL Patches:
  Bundle patch 35037840 (Database Release Update 19.21.0.0.0)

Adding patches to installation queue...
Installing patch 35037840 (Database Release Update 19.21.0.0.0)...

Patch installation complete.  Total patches installed: 1

Validating logfiles...done
SQL Patching tool complete on Thu Jan 30 10:25:45 2025

Common Datapatch Issues

Issue 1: Datapatch Hangs

Cause

• Another datapatch session running
• Database in restricted mode
• Insufficient space

Solution

-- Check for running datapatch
SELECT * FROM dba_registry_sqlpatch
WHERE status = 'INSTALLING';

-- Kill if stuck (use with caution)
-- Find and kill the session

-- Retry
$ORACLE_HOME/OPatch/datapatch

Issue 2: Datapatch Fails

Cause

• Invalid objects before patching
• Insufficient privileges
• Database not in correct state

Solution

-- Compile invalid objects
@?/rdbms/admin/utlrp.sql

-- Check for errors in datapatch log
-- Location: $ORACLE_BASE/cfgtoollogs/sqlpatch/<timestamp>/

-- Retry datapatch
$ORACLE_HOME/OPatch/datapatch

Issue 3: Status Shows “WITH ERRORS”

Check

SELECT patch_id, action, status, description
FROM dba_registry_sqlpatch
WHERE status != 'SUCCESS';

7. PATCHING IN DIFFERENT ENVIRONMENTS

Single Instance Database

Process

1. Backup
2. Shutdown database
3. Apply patch with OPatch
4. Start database
5. Run datapatch
6. Verify

Downtime

30 minutes – 2 hours (depending on database size)

RAC Environment

Rolling Patch (Minimal Downtime)

Prerequisites

• Patch must support rolling apply
• Check README for rolling instructions

Process

Node 1: Shutdown instance 1
Node 1: Apply patch
Node 1: Start instance 1
    ↓ (Services continue on Node 2)
Node 2: Shutdown instance 2
Node 2: Apply patch
Node 2: Start instance 2
    ↓
Run datapatch once (any node)

Commands

# On Node 1
srvctl stop instance -d ORCL -i ORCL1
opatch apply
srvctl start instance -d ORCL -i ORCL1

# On Node 2
srvctl stop instance -d ORCL -i ORCL2
opatch apply
srvctl start instance -d ORCL -i ORCL2

# On any node (once)
$ORACLE_HOME/OPatch/datapatch

Downtime

Near-zero (services relocate to other nodes)

Non-Rolling Patch

Process

1. Shutdown all instances
2. Apply patch on all nodes
3. Start all instances
4. Run datapatch

Commands

# Shutdown cluster database
srvctl stop database -d ORCL

# On each node
opatch apply

# Start cluster database
srvctl start database -d ORCL

# Run datapatch (once, any node)
$ORACLE_HOME/OPatch/datapatch

Data Guard Environment

Rolling Patch Process

Step 1: Patch Standby

# On Standby
# Stop MRP
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

# Apply patch
opatch apply

# Run datapatch
SQL> STARTUP;
SQL> EXIT;

$ORACLE_HOME/OPatch/datapatch

# Restart MRP
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

Step 2: Verify Standby

SELECT * FROM dba_registry_sqlpatch;
SELECT * FROM v$version;

Step 3: Switchover to Standby

# Using Broker
DGMGRL> SWITCHOVER TO standby_db;

# Or manual switchover

Step 4: Patch Old Primary (Now Standby)

# Stop MRP
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

# Apply patch
opatch apply

# Run datapatch
$ORACLE_HOME/OPatch/datapatch

# Restart MRP
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

Step 5: Switchover Back (Optional)

DGMGRL> SWITCHOVER TO original_primary;

Total Downtime

Only during switchover (few minutes)

8. BEST PRACTICES

1. Always Read README

• Every patch has specific instructions
• Note prerequisites and known issues
• Follow Oracle’s recommended steps

2. Test in Non-Production First

Development → QA → UAT → Production

3. Always Take Backups

# Full database backup
RMAN> BACKUP DATABASE PLUS ARCHIVELOG;

# Oracle Home backup
tar -czf $ORACLE_HOME_backup.tar.gz $ORACLE_HOME

4. Use Out-of-Place for Production

• Easy rollback
• Zero risk to existing home
• Can test thoroughly

5. Schedule Regular Patching

- Quarterly RU application
- Critical security patches immediately
- Plan patching calendar

6. Maintain Patch Inventory

- Document applied patches
- Track patch levels across environments
- Use centralized tracking

7. Monitor After Patching

- Check alert logs
- Monitor performance
- Watch for errors
- Test critical applications

8. Keep OPatch Updated

# Always use latest OPatch version
opatch version

# Update from MOS Patch 6880880

9. Plan Rollback Strategy

- Document rollback steps
- Test rollback in non-prod
- Keep backups until stable

10. Compile Invalid Objects

@?/rdbms/admin/utlrp.sql

9. COMMON PATCHING ERRORS

Error 1: OPatch failed with error code 73

Cause

• Insufficient space in ORACLE_HOME
• /tmp full

Solution

# Check space
df -h $ORACLE_HOME
df -h /tmp

# Clean up space
opatch util cleanup

# Or set different temp directory
export TMP=/path/to/large/tmp
export TMPDIR=/path/to/large/tmp

Error 2: Prerequisite check failed

Cause

• OPatch version too old
• Conflict with existing patch

Solution

# Update OPatch
cd $ORACLE_HOME
mv OPatch OPatch.old
unzip p6880880_190000_Linux-x86-64.zip

# Check conflicts
opatch prereq CheckConflictAgainstOHWithDetail -ph /path/to/patch

Error 3: Database not in correct state

Cause

• Database not shutdown
• Listener still running

Solution

# Shutdown everything
sqlplus / as sysdba
SHUTDOWN IMMEDIATE;
EXIT;

lsnrctl stop LISTENER

# Then apply patch

Error 4: Datapatch fails

Cause

• Invalid objects
• Insufficient privileges
• Database in restricted mode

Solution

-- Compile invalid objects first
@?/rdbms/admin/utlrp.sql

-- Check database mode
SELECT logins FROM v$instance;

-- If RESTRICTED, allow all
ALTER SYSTEM DISABLE RESTRICTED SESSION;

-- Retry datapatch

Error 5: Inventory corruption

Cause

• Multiple patch attempts failed
• Inventory not updated correctly

Solution

# Verify inventory
opatch lsinventory -detail

# If corrupted, restore from backup
rm -rf $ORACLE_BASE/oraInventory
tar -xzf oraInventory_backup.tar.gz

# Or run opatch util cleanup
opatch util cleanup

10. INTERVIEW QUESTIONS

Q1: What is the difference between RU and CPU?

A:

RU (Release Update):

• Cumulative patch with bug fixes + security fixes
• Recommended for all environments
• Proactive patching
• Current standard (18c+)

CPU (Critical Patch Update):

• Security fixes only
• Legacy patching model
• Deprecated in favor of RU
• Still available but not recommended

Best Practice:
Always use RU as it includes all security fixes plus additional bug fixes.

Q2: What is OPatch and what does it do?

A:
OPatch is Oracle’s utility for applying patches to Oracle Home. It:

• Applies binary patches to Oracle software
• Updates Oracle inventory
• Checks prerequisites and conflicts
• Provides rollback capability
• Manages patch lifecycle

Key Operations:

opatch apply      # Apply patch
opatch rollback   # Rollback patch
opatch lspatches  # List applied patches
opatch version    # Check OPatch version

Q3: What is datapatch and when do you run it?

A:
Datapatch is a utility that applies SQL changes to the database dictionary after binary patches are applied.

Why Needed:

• OPatch updates binaries (executables)
• Datapatch updates database objects (SQL, PL/SQL)

When to Run:

• After applying RU / RUR
• After applying bundle patches
• After some one-off patches (check README)

Command:

$ORACLE_HOME/OPatch/datapatch

Verification:

SELECT * FROM dba_registry_sqlpatch;

Q4: Explain in-place vs out-of-place patching.

A:

In-Place Patching:

• Apply patch directly to existing Oracle Home
• Simpler but risky
• Difficult rollback
• Less disk space needed

Out-of-Place Patching:

• Create new Oracle Home with patches
• Switch database to new home
• Easy rollback (switch back to old home)
• Requires more disk space
• Recommended for production

Example:

Out-of-Place:
Old OH: /dbhome_1 (19.3)
New OH: /dbhome_2 (19.21 patched)
Switch database from dbhome_1 to dbhome_2

Q5: How do you apply patches in a RAC environment?

A: Two methods:

1. Rolling Patch (Minimal Downtime):

- Patch one node at a time
- Services continue on other nodes
- Requires patch to support rolling
- Near-zero downtime

Process:

Node 1: Stop instance → Apply patch → Start instance
Node 2: Stop instance → Apply patch → Start instance
Any node: Run datapatch (once)

2. Non-Rolling (All Nodes Down):

- Stop all instances
- Apply patch on all nodes
- Start all instances
- Run datapatch

Best Practice:
Use rolling patches when supported for minimal downtime.

Q6: What is a one-off patch?

A:
A one-off patch is a single patch for a specific bug.

Characteristics:

• Targets one or few related bugs
• Not cumulative
• Applied on top of RU
• Small size
• Can cause conflicts

Use Case:

You encounter Bug 12345678
Oracle provides one-off patch for that bug
Apply on top of latest RU

Important:

• Always apply on current RU
• May need to reapply after next RU
• Check for conflicts before applying

Q7: How do you rollback a patch?

A: Three methods:

Method 1: OPatch Rollback (In-Place)

# Shutdown database
SHUTDOWN IMMEDIATE;

# Rollback patch
opatch rollback -id <patch_number>

# Start database
STARTUP;

# Rollback datapatch
$ORACLE_HOME/OPatch/datapatch -rollback <patch_id>

Method 2: Restore from Backup (In-Place)

# Shutdown database
# Restore Oracle Home from backup
# Restore inventory from backup
# Start database

Method 3: Switch to Old Home (Out-of-Place)

# Shutdown database
# Switch ORACLE_HOME to old home
# Start database

Easiest:
Out-of-place patching with switch back to old home.

Q8: What prerequisites should you check before patching?

A:

1. OPatch Version:

opatch version
# Update if needed

2. Conflicts:

opatch prereq CheckConflictAgainstOHWithDetail -ph ./

3. Disk Space:

df -h $ORACLE_HOME
df -h /tmp
# Need 5-10 GB free

4. Backups:

# Full database backup
# Oracle Home backup
# Inventory backup

5. Applied Patches:

opatch lspatches

6. Database Version:

SELECT * FROM v$version;

7. Read README:

• Prerequisites
• Known issues
• Special instructions

Q9: How do you verify a patch was applied successfully?

A:

1. Check OPatch Inventory:

opatch lspatches
opatch lsinventory | grep <patch_number>

2. Check Database Registry:

SELECT * FROM dba_registry_sqlpatch ORDER BY action_time DESC;

3. Check Version:

SELECT * FROM v$version;

4. Check Component Status:

SELECT comp_name, version, status FROM dba_registry;

5. Check for Invalid Objects:

SELECT COUNT(*) FROM dba_objects WHERE status = 'INVALID';

6. Check Alert Log:

tail -100 alert_<SID>.log
# Look for errors

7. Application Testing:

• Test critical applications
• Run smoke tests
• Monitor for errors

Q10: What is the Oracle patching schedule?

A: Oracle releases patches on a quarterly schedule:

Release Update (RU) Schedule:

January   - 3rd Tuesday
April     - 3rd Tuesday
July      - 3rd Tuesday
October   - 3rd Tuesday

Example:

Jan 2025: 19.22 RU
Apr 2025: 19.23 RU
Jul 2025: 19.24 RU
Oct 2025: 19.25 RU

Critical Patch Updates (CPU):

• Same schedule as RU (deprecated)
• Security-only patches

Best Practice:

• Apply quarterly RUs within 1–2 months
• Test in non-prod first
• Critical security patches: Immediate

Q11: How do you patch a Data Guard environment?

A: Rolling patch process:

Step 1: Patch Standby Database

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
opatch apply
datapatch
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

Step 2: Switchover to Standby

DGMGRL> SWITCHOVER TO standby_db;

Step 3: Patch Old Primary (Now Standby)

Step 4: Switchover Back (Optional)

DGMGRL> SWITCHOVER TO original_primary;

Benefits:

• Minimal downtime
• Test patch on standby first
• Easy rollback

Total Downtime: 2–5 minutes

Q12: What is the difference between opatch apply and opatch napply?

A:

opatch apply:

• Apply single patch
• Interactive mode
• Standard method

opatch napply:

• Apply multiple patches
• Non-interactive
• Faster for bundles

Usage:

opatch apply
opatch napply /path/to/patches

Q13: What should you do if datapatch fails?

A:

Step 1: Check Logs

$ORACLE_BASE/cfgtoollogs/sqlpatch/<timestamp>/

Step 2: Common Fixes

@?/rdbms/admin/utlrp.sql
ALTER SYSTEM DISABLE RESTRICTED SESSION;

Step 3: Retry

$ORACLE_HOME/OPatch/datapatch -verbose

Step 4: Manual Fix / Oracle Support

Q14: How do you check if a patch is already applied?

A:

opatch lspatches | grep <patch_number>
opatch lsinventory | grep <patch_number>

SELECT patch_id, status FROM dba_registry_sqlpatch;

Q15: What is the impact of not patching regularly?

A:

• Security risks
• Stability issues
• Performance degradation
• Oracle Support limitations

Balance:

• Don’t patch blindly
• Don’t delay excessively
• Plan, test, and document

11. QUICK REFERENCE

Common Patch Types

• RU – Quarterly, cumulative
• RUR – Emergency fix
• One-Off – Single bug fix
• CPU – Security only (legacy)
• PSU – Old term (legacy)

Essential Commands

opatch version
opatch lspatches
opatch apply
opatch rollback -id <patch_id>
$ORACLE_HOME/OPatch/datapatch
SELECT * FROM dba_registry_sqlpatch;

Patching Checklist

☐ Read README
☐ Check OPatch version
☐ Check conflicts
☐ Take full backup
☐ Check disk space
☐ Schedule downtime
☐ Shutdown database
☐ Apply patch
☐ Start database
☐ Run datapatch
☐ Verify patch
☐ Compile invalid objects
☐ Test applications
☐ Monitor alert logs

You’re now ready for patching questions in your interview!

Focus on:

• RU vs CPU difference
• OPatch and datapatch usage
• In-place vs out-of-place patching
• RAC/Data Guard rolling patches
• Common errors and troubleshooting

Good luck with your interview! 🚀