\n\ud83d\udcce MOS Doc ID 2694520.1<\/strong> \u2014 Oracle Database 19c Proactive Patch \u2014 lists all current recommended patches in one place. Always start here.<\/p>\n<\/blockquote>\n\n\n\n# After downloading \u2014 verify the patch zip is complete\nls -lh \/stage\/patches\/p<PATCHNUM>_190000_Linux-x86-64.zip\n\n# Verify checksum against MOS download page\nsha256sum \/stage\/patches\/p<PATCHNUM>_190000_Linux-x86-64.zip\n\n# Unzip the patch to staging area\nmkdir -p \/stage\/patches\/unzipped\nunzip -q \/stage\/patches\/p<PATCHNUM>_190000_Linux-x86-64.zip \\\n -d \/stage\/patches\/unzipped\n\n# List what was extracted \u2014 should see a numbered folder (the patch ID)\nls -l \/stage\/patches\/unzipped\/<\/code><\/pre>\n\n\n\n
\n\n\n\n4.4 \u2014 Read the Patch README<\/h4>\n\n\n\n\nWhy?<\/strong> Every patch ships with a README file that contains patch-specific instructions, known issues, pre-requisites, and sometimes special steps that differ from the standard process. Not reading the README is the most common cause of patching mistakes.<\/p>\n<\/blockquote>\n\n\n\n# The README is inside the extracted patch directory\nls \/stage\/patches\/unzipped\/<PATCHNUM>\/\n\n# Read it fully before proceeding\n# Key things to look for:\n# - Minimum OPatch version required\n# - Any pre-install steps specific to this patch\n# - Any post-install steps beyond standard datapatch\n# - Known issues or conflicts\nless \/stage\/patches\/unzipped\/<PATCHNUM>\/README.html\n# OR\nless \/stage\/patches\/unzipped\/<PATCHNUM>\/README.txt<\/code><\/pre>\n\n\n\n
\n\n\n\n4.5 \u2014 Check Disk Space for Patching<\/h4>\n\n\n\n\nWhy?<\/strong> OPatch takes a backup of all files it will replace before applying the patch. This backup goes into $ORACLE_HOME\/.patch_storage<\/code>. If there is not enough space, OPatch will fail mid-patch which is a dangerous situation.<\/p>\n<\/blockquote>\n\n\n\nbash<\/p>\n\n\n\n
# Check ORACLE_HOME filesystem \u2014 need at least 2-3 GB free\ndf -hP $ORACLE_HOME\n\n# Check \/tmp \u2014 OPatch uses \/tmp during operations\ndf -hP \/tmp\n\n# Check current size of patch_storage (existing backups from previous patches)\ndu -sh $ORACLE_HOME\/.patch_storage 2<\/strong>>\/dev\/null || echo \"No previous patch storage found\"<\/code><\/pre>\n\n\n\n\n\u26a0\ufe0f IMPORTANT:<\/strong> If \/oracle<\/code> or \/u01<\/code> filesystem is above 85% used, clean up old patch backups from .patch_storage<\/code> or ask your storage team to extend the filesystem BEFORE patching.<\/p>\n<\/blockquote>\n\n\n\n
\n\n\n\n4.6 \u2014 Run OPatch Prerequisite Check (Without Applying)<\/h4>\n\n\n\n\nWhy?<\/strong> OPatch has a built-in prereq check that validates everything before touching a single file. It checks for conflicts with existing patches, verifies OPatch version, checks permissions, and checks disk space. This is a dry-run \u2014 it changes nothing. Always run it first.<\/p>\n<\/blockquote>\n\n\n\nsu - oracle\ncd \/stage\/patches\/unzipped\/<PATCHNUM>\n\n# Run prereq check only \u2014 does NOT apply the patch\n$ORACLE_HOME\/OPatch\/opatch prereq CheckConflictAgainstOHWithDetail \\\n -ph \/stage\/patches\/unzipped\/<PATCHNUM><\/code><\/pre>\n\n\n\nWhat to look for in output:<\/strong><\/p>\n\n\n\nOPatch succeeded. \u2190 This is what you want to see<\/code><\/pre>\n\n\n\n\n\u26a0\ufe0f IMPORTANT:<\/strong> If prereq check shows Patch conflict detected<\/code> \u2014 stop. Do NOT proceed with patching until the conflict is resolved. Check the conflict details in the output, search MOS for the conflicting patches, and either remove the conflicting patch or get a merged patch from Oracle Support.<\/p>\n<\/blockquote>\n\n\n\n
\n\n\n\n4.7 \u2014 Check for Running Database Sessions<\/h4>\n\n\n\n\nWhy?<\/strong> The database must be shut down before applying the patch. But before shutting down, check for active sessions. In production, coordinate with application teams for a maintenance window. Never shut down a database with active transactions without notice.<\/p>\n<\/blockquote>\n\n\n\nsqlplus \/ as sysdba\n\nset linesize 180\nset pagesize 100\ncol username for a20\ncol osuser for a20\ncol machine for a30\ncol program for a30\ncol status for a10\ncol logon_time for a22\n\n-- Shows all active user sessions\nSELECT username, osuser, machine, program, status, logon_time\nFROM v$session\nWHERE type = 'USER'\nAND username IS NOT NULL\nORDER BY logon_time;\n\n-- Quick count of active sessions\nSELECT COUNT(*) active_sessions\nFROM v$session\nWHERE type = 'USER'\nAND status = 'ACTIVE';<\/code><\/pre>\n\n\n\n
\n\n\n\n4.8 \u2014 Take RMAN Backup Before Patching<\/h4>\n\n\n\n\nWhy?<\/strong> This is your safety net. If the patch goes wrong and rollback also fails (rare but it happens), the RMAN backup is your last resort to restore the database. Never patch a production database without a valid recent backup.<\/p>\n<\/blockquote>\n\n\n\nbash<\/p>\n\n\n\n
su - oracle\n\n# Take a full database backup before patching\nrman target \/\n\nRMAN> BACKUP DATABASE PLUS ARCHIVELOG;\nRMAN> LIST BACKUP SUMMARY; -- Confirm backup completed\nRMAN> EXIT;<\/code><\/pre>\n\n\n\n\n\u26a0\ufe0f IMPORTANT:<\/strong> If a full RMAN backup was taken within the last 24 hours and no significant data changes have happened, you can skip this step in non-production environments. In production \u2014 always take a fresh backup.<\/p>\n<\/blockquote>\n\n\n\n
\n\n\n\n4.9 \u2014 Record Pre-Patch Baseline<\/h4>\n\n\n\n
Why?<\/strong> You need a record of exactly what the system looked like BEFORE the patch. This is used for comparison during post-patch checks and as evidence for your change management record.<\/p>\n\n\n\nsqlplus \/ as sysdba\n\nset linesize 200\nset pagesize 100\ncol comp_name for a50\ncol version for a15\ncol status for a12\n\n-- Record current component versions\nSELECT comp_name, version, status\nFROM dba_registry\nORDER BY comp_name;\n\n-- Record current invalid object count\nSELECT COUNT(*) pre_patch_invalid_count\nFROM dba_objects\nWHERE status = 'INVALID';<\/code><\/pre>\n\n\n\n# Record current patch inventory to a file for reference\n$ORACLE_HOME\/OPatch\/opatch lsinventory > \/tmp\/pre_patch_inventory_$(date +%Y%m%d).txt\ncat \/tmp\/pre_patch_inventory_$(date +%Y%m%d).txt<\/code><\/pre>\n\n\n\n
\n\n\n\n5. Patching Activity<\/h3>\n\n\n\n\n\u26a0\ufe0f IMPORTANT:<\/strong> From this point onwards the database will be shut down. Ensure your maintenance window is active, application teams are notified, and monitoring alerts are suppressed (blackout in OEM if configured).<\/p>\n<\/blockquote>\n\n\n\n
\n\n\n\n5.1 \u2014 Stop All Database Services and Shut Down Database<\/h4>\n\n\n\n\nWhy?<\/strong> Oracle binaries cannot be patched while they are in use. The database, listener, and any other Oracle processes using this ORACLE_HOME must be stopped before OPatch can replace the binary files.<\/p>\n<\/blockquote>\n\n\n\nsu - oracle\n\n# Step 1 \u2014 Shut down the listener first\nlsnrctl stop\n\n# Confirm listener is down\nlsnrctl status # Should show \"TNS-12541: No listener\"\n\n# Step 2 \u2014 Shut down the database\nsqlplus \/ as sysdba<\/code><\/pre>\n\n\n\n-- Graceful shutdown \u2014 waits for all active transactions to complete\n-- Use IMMEDIATE if NORMAL takes too long (more than 5 minutes)\nSHUTDOWN IMMEDIATE;\nEXIT;<\/code><\/pre>\n\n\n\n# Step 3 \u2014 Confirm no Oracle processes are running from this ORACLE_HOME\nps -ef | grep ora_ | grep -v grep\nps -ef | grep $ORACLE_HOME | grep -v grep\n\n# Expected: No output (or only grep itself)<\/code><\/pre>\n\n\n\n\n\u26a0\ufe0f IMPORTANT:<\/strong> If any Oracle process is still running after SHUTDOWN IMMEDIATE<\/code>, do NOT proceed. Identify the process and stop it cleanly. Patching while Oracle processes are running will corrupt the Oracle Home.<\/p>\n<\/blockquote>\n\n\n\n
\n\n\n\n5.2 \u2014 Set ORACLE_HOME Environment (Confirm Before Patching)<\/h4>\n\n\n\n
Why?<\/strong> OPatch uses the ORACLE_HOME<\/code> environment variable to know which Oracle Home to patch. If this is set incorrectly, you could accidentally patch the wrong Oracle Home. Always verify before running OPatch.<\/p>\n\n\n\nsu - oracle\n\n# Confirm environment is pointing to correct ORACLE_HOME\necho \"ORACLE_HOME = $ORACLE_HOME\"\necho \"ORACLE_BASE = $ORACLE_BASE\"\necho \"ORACLE_SID = $ORACLE_SID\"\n\n# Also confirm OPatch is using the correct home\n$ORACLE_HOME\/OPatch\/opatch lsinventory | grep \"Oracle Home\"<\/code><\/pre>\n\n\n\n
\n\n\n\n5.3 \u2014 Apply the Patch Using OPatch<\/h4>\n\n\n\n\nWhy opatch apply<\/code>?<\/strong> This is the command that actually replaces the old Oracle binary files and libraries with the new patched versions. OPatch first backs up all files it will replace (into .patch_storage<\/code>), then replaces them. If something fails, OPatch uses this backup to roll back.<\/p>\n<\/blockquote>\n\n\n\nsu - oracle\n\n# Navigate to the extracted patch directory\ncd \/stage\/patches\/unzipped\/<PATCHNUM>\n\n# Apply the patch\n# -silent = no interactive prompts\n# -oh = explicitly specify ORACLE_HOME (best practice to avoid ambiguity)\n$ORACLE_HOME\/OPatch\/opatch apply -silent \\\n -oh $ORACLE_HOME\n\n# Watch for progress \u2014 OPatch shows files being patched<\/code><\/pre>\n\n\n\nExpected output at the end:<\/strong><\/p>\n\n\n\nPatching component oracle.rdbms, 19.x.x.x.x...\nPatch <PATCHNUM> successfully applied.\nOPatch succeeded.<\/code><\/pre>\n\n\n\n\n\u26a0\ufe0f IMPORTANT:<\/strong> If OPatch shows any error during apply \u2014 do NOT start the database. First run the rollback (Section 7) to restore to pre-patch state, then investigate the error. Starting a database with a partially applied patch can cause data dictionary corruption.<\/p>\n<\/blockquote>\n\n\n\n
\n\n\n\n5.4 \u2014 Verify Patch Was Applied Successfully<\/h4>\n\n\n\n\nWhy?<\/strong> Confirm the patch is now listed in the Oracle inventory before starting the database. This is your confirmation that OPatch completed successfully.<\/p>\n<\/blockquote>\n\n\n\nsu - oracle\n\n# Check patch is now listed in inventory\n$ORACLE_HOME\/OPatch\/opatch lsinventory | grep -E \"Patch|PATCHNUM\"\n\n# Detailed check\n$ORACLE_HOME\/OPatch\/opatch lsinventory -detail | grep -A5 \"<PATCHNUM>\"<\/code><\/pre>\n\n\n\n
\n\n\n\n5.5 \u2014 Start the Database and Listener<\/h4>\n\n\n\n\nWhy start before datapatch?<\/strong> The database must be open (not just mounted) for datapatch to run. datapatch applies SQL changes to the data dictionary, which requires the database to be in READ WRITE mode.<\/p>\n<\/blockquote>\n\n\n\nsu - oracle\n\n# Start the database\nsqlplus \/ as sysdba<\/code><\/pre>\n\n\n\nSTARTUP;\n\n-- Confirm database is open\nSELECT name, open_mode FROM v$database;\nEXIT;<\/code><\/pre>\n\n\n\n# Start the listener\nlsnrctl start\n\n# Confirm listener is up and database is registered\nlsnrctl status<\/code><\/pre>\n\n\n\n
\n\n\n\n5.6 \u2014 Run datapatch (CRITICAL STEP)<\/h4>\n\n\n\n\nWhy datapatch?<\/strong> OPatch patches the Oracle software binaries (the files on disk). But Oracle also stores version-specific SQL objects, packages, and dictionary tables inside the database itself. datapatch updates these internal database objects to match the newly patched binaries. Without datapatch, there will be a mismatch between the binary version and the dictionary version \u2014 this causes ORA- errors and incorrect behavior.<\/p>\n<\/blockquote>\n\n\n\n\n\u26a0\ufe0f IMPORTANT:<\/strong> datapatch MUST be run after every OPatch apply. It is not optional. Skipping datapatch is one of the most common patching mistakes.<\/p>\n<\/blockquote>\n\n\n\nsu - oracle\n\n# Navigate to OPatch utilities directory\ncd $ORACLE_HOME\/OPatch\n\n# Run datapatch\n# -verbose = shows detailed progress of each SQL script being applied\n.\/datapatch -verbose<\/code><\/pre>\n\n\n\nWhat to look for in datapatch output:<\/strong><\/p>\n\n\n\nSQL Patching tool version 19.x.x.x.x\nCopyright (c) 2012, 2023, Oracle. All rights reserved.\n\nLog file for this invocation: \/u01\/app\/oracle\/cfgtoollogs\/sqlpatch\/<date>\/\nConnecting to database...OK\nBootstrapping registry and package to current versions...done\nDetermining current state...done\nAdding patches to installation queue and performing prereq checks...done\nInstallation queue:\n For the following patches, no SQL actions will be performed:\n None\n The following patches will be applied:\n <PATCHNUM> (DATABASE RELEASE UPDATE 19.xx.x.x.x)\n\nInstalling patches...\nPatch installation complete. Total patches installed: 1\nValidating logfiles...done\nPatch <PATCHNUM> apply: SUCCESS\n logfile: \/u01\/app\/oracle\/cfgtoollogs\/sqlpatch\/...\/...log (no errors)\ndatapatch: ALL PATCHES APPLIED SUCCESSFULLY.<\/code><\/pre>\n\n\n\n\n\u26a0\ufe0f IMPORTANT:<\/strong> If datapatch shows any failures, check the log file path shown in the output. Common issues: database not fully open, temporary tablespace full, INVALID objects blocking compilation.<\/p>\n<\/blockquote>\n\n\n\n# Check datapatch log for errors if needed\nls -lrt \/u01\/app\/oracle\/cfgtoollogs\/sqlpatch\/\n# Convention B:\nls -lrt \/oracle\/cfgtoollogs\/sqlpatch\/<\/code><\/pre>\n\n\n\n
\n\n\n\n6. Post-Patching Checks<\/h3>\n\n\n\n\n\u26a0\ufe0f IMPORTANT:<\/strong> Post-patch checks are mandatory. Do not close your maintenance window or inform the team that patching is complete until every check below passes.<\/p>\n<\/blockquote>\n\n\n\n
\n\n\n\n6.1 \u2014 Confirm New Patch Version<\/h4>\n\n\n\n
Why?<\/strong> First confirmation that the patch is correctly reflected in both the Oracle binary and the data dictionary.<\/p>\n\n\n\nsqlplus \/ as sysdba\n\nset linesize 150\nset pagesize 50\ncol banner for a80\n\n-- Confirms binary version matches expected patched version\nSELECT banner FROM v$version WHERE banner LIKE 'Oracle%';\n\n-- Shows full version including patch level\nSELECT version, version_full FROM v$instance;<\/code><\/pre>\n\n\n\n# Confirms patch is listed in OPatch inventory\n$ORACLE_HOME\/OPatch\/opatch lsinventory | grep -E \"Patch|Oracle Database\"<\/code><\/pre>\n\n\n\n
\n\n\n\n6.2 \u2014 Verify datapatch Applied Successfully in the Database<\/h4>\n\n\n\n\nWhy?<\/strong> Even if datapatch appeared to succeed on the command line, verify it inside the database. dba_registry_sqlpatch<\/code> is the authoritative record of what datapatch has applied.<\/p>\n<\/blockquote>\n\n\n\nset linesize 200\nset pagesize 100\ncol patch_id for 9999999999\ncol patch_uid for 9999999999\ncol version for a15\ncol status for a15\ncol description for a55\ncol action_time for a25\n\n-- Shows all patches applied by datapatch and their status\nSELECT patch_id, patch_uid, version, status, description, action_time\nFROM dba_registry_sqlpatch\nORDER BY action_time DESC;<\/code><\/pre>\n\n\n\nWhat to look for:<\/strong> Your patch number must appear with SUCCESS<\/code> in the status<\/code> column.<\/p>\n\n\n\n
\n\n\n\n6.3 \u2014 Check Database is Open and Healthy<\/h4>\n\n\n\nset linesize 150\nset pagesize 50\ncol name for a12\ncol db_unique_name for a20\ncol open_mode for a15\ncol log_mode for a15\ncol instance_name for a15\ncol status for a12\ncol host_name for a30\n\nSELECT name, db_unique_name, open_mode, log_mode\nFROM v$database;\n\nSELECT instance_name, version_full, host_name, status\nFROM v$instance;<\/code><\/pre>\n\n\n\n
\n\n\n\n6.4 \u2014 Check All Datafiles Are Online<\/h4>\n\n\n\nset linesize 200\nset pagesize 100\ncol file# for 999\ncol tablespace_name for a25\ncol status for a12\ncol name for a70\n\nSELECT file#, tablespace_name, status, name\nFROM v$datafile\nORDER BY file#;<\/code><\/pre>\n\n\n\nWhat to look for:<\/strong> All files must show ONLINE<\/code>.<\/p>\n\n\n\n
\n\n\n\n6.5 \u2014 Check for INVALID Objects After Patching<\/h4>\n\n\n\n\nWhy?<\/strong> Patching sometimes invalidates PL\/SQL objects that reference changed packages or types. datapatch recompiles most of them automatically, but some may remain invalid. These must be recompiled before application teams reconnect.<\/p>\n<\/blockquote>\n\n\n\nset linesize 180\nset pagesize 100\ncol owner for a20\ncol object_name for a45\ncol object_type for a25\ncol status for a10\n\n-- Check for any invalid objects\nSELECT owner, object_name, object_type, status\nFROM dba_objects\nWHERE status = 'INVALID'\nORDER BY owner, object_type, object_name;\n\n-- Count\nSELECT COUNT(*) post_patch_invalid_count\nFROM dba_objects\nWHERE status = 'INVALID';<\/code><\/pre>\n\n\n\n\n\u26a0\ufe0f IMPORTANT:<\/strong> If invalid count is higher than your pre-patch baseline recorded in Section 4.9, run utlrp.sql<\/code> to recompile:<\/p>\n<\/blockquote>\n\n\n\n-- Recompile all invalid objects\n@?\/rdbms\/admin\/utlrp.sql\n\n-- Re-verify\nSELECT COUNT(*) FROM dba_objects WHERE status = 'INVALID';<\/code><\/pre>\n\n\n\n
\n\n\n\n6.6 \u2014 Verify All Components Are VALID<\/h4>\n\n\n\nset linesize 200\nset pagesize 100\ncol comp_name for a50\ncol version for a15\ncol status for a12\n\nSELECT comp_name, version, status\nFROM dba_registry\nORDER BY comp_name;<\/code><\/pre>\n\n\n\nWhat to look for:<\/strong> Every component must show VALID<\/code>. Compare versions against pre-patch baseline \u2014 they should now show the new patched version numbers.<\/p>\n\n\n\n