Hot Online Patching in Oracle: Benefits and Pitfalls

If you need to patch your database, you want to do it easily, right? why complicate it? As a DBA, I have a choice to avoid interrupting the availability of the database instance. So, why bother stopping the database if you can do something online?

In this blog, I want to talk about hot online patching. It is not about RAC rolling patches. You know, one instance down, patching stuff, start it and move on to the other one. This is a patching mode without stopping anything! But be careful there are some implications. Want to know more? Keep reading!

What Is Hot Online Patching?

So, what is this hot patching? well, first let’s talk about what is a “regular patch”

A regular RDBMS patch consists of one or more object (.o) files and/or libraries (.a files). Typically, installing such a patch requires shutting down the Oracle database instance, which can disrupt availability. Next, it requires re-linking the Oracle binary and restarting the instance. Uninstalling a regular patch requires the same steps.

On the other hand, an online patch is a special kind of patch. It can be applied to a live, running Oracle database instance. An online patch contains a single shared library. Installing it does not require shutting down the instance. It also does not require relinking the oracle binary. An online patch can be installed/un-installed using Opatch (which uses oradebug commands to install/uninstall the patch).

Before you proceed with online patching, here are some important considerations to keep in mind:

Online patching is currently only supported for the RDBMS, i.e., the Oracle binary.
Online patching is not supported for ASM instance running in Grid Infrastructure home.
Not all the patches can be applied using this mode. Make sure to check the README for each patch individually. You can also use opatch query -is_online_patch for that purpose. Of course, make sure to check if there is any possible conflict. It’s normal stuff for patching, etc.
And finally, I think the most important thing is to ensure that you maintain adequate memory on your system. This is crucial to apply this type of online patch. I will talk about this later in the post.

What do the instructions look like?

(2.2) Installing in Online Mode
-----------------------------------
To  install the patch in online mode, follow these steps:

1.	Set your current directory to the directory where the patch is located and then run the OPatch utility by entering the following commands:
	
	$ cd <PATCH_TOP_DIR>/XXXX

2.	Install the patch by running the following command:
	-	For Non-RAC Environments (Standalone Databases):  
		$ opatch apply <patch unzipped location> -online -connectString <SID>:<USERNAME>:<PASSWORD>: 
	-	For RAC Environments: 
		$ opatch apply <patch unzipped location> -online -connectString <SID_Node1>:<Username_Node1>:<Password_Node1>:<Node1_Name>,<SID_Node2>:<Username_Node2>:<Password_Node2>:<Node2_Name>,<SID_NodeN>:<Username_NodeN>:<Password_NodeN>:<NodeN_Name>

	Note:
	-	Run the previous command on the first node of the Oracle RAC system, and specify details of each node separated by a comma. In the command, NodeN refers to the different nodes of the Oracle RAC system. Once the patch is applied on the first node, OPatch automatically moves over and patches the next node you have specified in the comamnd.

Quite simple, right?

Applying Online Patches across multiple databases

What happens if there are multiple databases running in the same ORACLE_HOME? You want or need to apply the patch on those databases as well.

Then you will need to:

Apply the patch following early instructions for the first database

opatch apply <patch_location> -online -connectString <SID:User:Passwd:Node>

Enable the fix for the other SIDs as following:

opatch util enableonlinepatch -connectString <SID>:<USERNAME>:<PASSWORD>:<NODE> -id <Commaseparated list of patch IDs>

Disabling or removing Online Patches for specific SIDs

In case you want to disable or remove the fix for some SIDs, You need to use the opatch util DisableOnlinePatch as follow:

opatch util DisableOnlinePatch -connectString <SID>:<USERNAME>:<PASSWORD>:<NODE> -ph<Patch_location>

Do you want to know what is the status of the patch? then you can execute the oradebug as follow:

sqlplus> oradebug patch list

Is the patch eligible to be applied online?

Finally, and I have already mentioned early if you want to know if a patch is eligible to be applied online you can use the opatch query as follow:

cd <patch_location>
opatch query -is_online_patch

Oracle Home : /u01/app/oracle/product/19c
Central Inventory : /u01/app/oracle/product/19c/oraInventory
from : /u01/app/oracle/product/19c/oraInst.loc
OPatch version : 12.2.0.1.37
OUI version : 12.2.0.7.0

Log file location : /u01/app/oracle/product/19c/cfgtoollogs/opatch/opatch.log

Patch is an online patch: true
OPatch succeeded.

As you can see in this example, it says: Patch is an online patch: true

How do you know what online patches are installed?

Quite simple, you just need to run the opatch lsinventory but in this case do not forget to add the “-detail”, example:

$ORACLE_HOME/OPatch/opatch lsinventory -detail

You will see something like this:

Rolling Back an Online Patch: Step-by-Step

You’ve successfully applied the patch—great job! However, if you need to revert it, you’ll have to roll back the patch and apply a regular one. Here’s how:

OPatch/opatch rollback -id <patch_number> -connectString <SID:User:Passwd:Node>

How Does the Online Patch Mechanism Work ?

An online patch consists of a shared library that contains the necessary fixes and diagnostics. When applied, the oradebug utility is used to instruct each Oracle process to perform the following steps:

Map the shared library into its address space.
Modify the original function in the text segment, redirecting execution to the patched version in the shared library.
Ensure that any static variables referenced in the patch resolve to the correct memory location.
Redirect any static function calls to the appropriate memory address.

When an online patch is uninstalled, the changes are reversed—jumps and branches in the text segment are removed, and the original instructions are restored.

Currently Supported Platforms

01 HP-UX Itanium .............................. ( requries OS Patch HPUX 11iv3 (11.31) + [March 2008 Quality Pack +PHKL_38038] )
02 IBM AIX on POWER Systems (64-bit) .. ( requires AIX 6.1 + TL-02 + SP-01 onwards )
03 IBM: Linux on POWER Systems
04 IBM: Linux on System z
05 Linux x86
06 Linux x86-64
07 Microsoft Windows x86 (32-bit) .......... ( requires Opatch tool version 11.2.0.1.1 )
08 Microsoft Windows x86-64 (64-bit)
09 Oracle Solaris on SPARC (64-bit) ........ ( requires SunOS kernel patch 137111-04 )
10 Oracle Solaris on x86-64 (64-bit) ........ ( requires kernel patch 137112-04 )
11 HP-PARISC Not supported
12 Windows/Itanium Not supported

Understanding Memory Requirements for Online Patching

There is a memory overhead when applying an online patch. Be sure to calculate the memory needed for the patch before applying it, and confirm that there is enough memory available.
You can use the following steps to determine the memory required for an online patch:

Unix : memory overhead = ( # of processes +1) x size of ( .pch file)
Windows: memory overhead = size of ( .pch file)

Note: Number of Oracle processes is determined by checking parameter “processes” in the db use v$parameter tp check on that!

Important!

Online patches are recommended when a downtime cannot be scheduled and the patch needs to be applied urgently.
Online patches consume additional memory, and if left permanently, the consumption will increase as more processes run in the system.
It is strongly recommended to rollback all Online patches and replace them with regular offline patches on next instance shutdown or the earliest maintenance window.

What’s the Best Approach for Patching?

To help you decide whether hot online patching is the right choice, I’ve created a decision flowchart. This serves as a general guideline, but keep in mind that every environment is unique—factors like patch compatibility, system workload, and business requirements may introduce additional considerations.

Use this flowchart as a starting point, but always evaluate your specific scenario before proceeding:

Flowchart illustrating the steps and considerations for applying hot online patches in database management.

Final Thoughts: When to use Online Patching

Hot online patching is a valuable tool for maintaining database availability, but it should never be the final step. While it prevents downtime, it increases memory usage and should only be used as a temporary measure.

To ensure long-term stability, DBAs must:
Verify patch eligibility and system resource requirements.
Monitor performance after applying an online patch.
Schedule a maintenance window ASAP to roll back the online patch and apply it properly.

Online patching provides flexibility, but a controlled rollback and reapplication as a regular patch is essential to avoid long-term risks. Plan ahead, patch smartly, and keep your database both available and stable.

DatabaseVerse: Journey into the World of Databases