You know, I am not a fan of in-place patching. Actually, I think everyone should always patch out-of-place. But I know that for instance EBS with a 19c database requires in-place patching, and out-of-place will be supported only with 26ai for EBS. Therefore, in relation to an exercise I did over the weekend, let me share how to rollback an MRP.
Photo by Darío Bonzi on Unsplash
What is an MRP?
Very briefly, it stands for Monthly Recommended Patch – thus MRP. And it co-exists with CSPUs. I described the difference here. Read more if you are interested.
Rolling back an MRP
The reason why I rolled back an MRP was simply that I installed the wrong MRP. I wanted MRP3 for 19.31 but downloaded MRP4. So, after applying it and realizing how terrible in-place-patching is, I wanted to roll it back.
The README of the MRP has a deinstallation section under 4.
Follow the steps below, to roll back specific fixes included in the MRP patch.
- Shut down all instances and listeners associated with the Oracle home that you are updating.
- $ORACLE_HOME/OPatch/opatch nrollback -id <patch1, patch2… patchn>
- Start all instances and listeners associated with the Oracle home.
So, at first, the “nrollback” command is needed instead of the “rollback” since we are going to rollback multiple patches. But unfortunately, nowhere in the README does it specify the command ready for copy&paste.
Instead, I need to fetch the patch numbers, which in this case, is a nasty exercise. It could have done it with Kodex of course, but the first step is still required:
$ORACLE_HOME/OPatch/opatch lspatches 39779336;Fix for Bug 39779336 39750798;Fix for Bug 39750798 39661114;Fix for Bug 39661114 39661105;Fix for Bug 39661105 39661089;Fix for Bug 39661089 39598920;MERGE ON DATABASE RU 19.31.0.0.0 OF 39060101 39127997 39128024 39594515;Fix for Bug 39594515 39575331;Fix for Bug 39575331 39498075;MERGE ON DATABASE RU 19.31.0.0.0 OF 39360889 39370763 39429942; DB_DOMAIN NAME CHANGED TO UPPER CASE AUTOMATICALLY 39290842;Fix for Bug 39290842 39234501;Fix for Bug 39234501 39060241;Fix for Bug 39060241 39052286;Fix for Bug 39052286 38937302;AFTER APPLYING 19.30 DBRU THE AUTOTASK SQL TUNING ADVISOR GETS ORA-13602 38494116;Fix for Bug 38494116 39196236;DATAPUMP BUNDLE PATCH 19.31.0.0.0 38906621;OJVM RELEASE UPDATE: 19.31.0.0.260421 (38906621) 39034528;Database Release Update : 19.31.0.0.260421 (REL-APR2026) (39034528) 29585399;OCW RELEASE UPDATE 19.3.0.0.0 (29585399) OPatch succeeded.
Everything except the last 4 lines are patches belonging to the MRP.
I passed this into my editor and edited it to form the command. Of course, I could have done this task with Kodex or any other LLM as well.
$ORACLE_HOME/OPatch/opatch nrollback -id 39779336,39750798,39661114,39661105,39661089,39598920,39594515,39575331,39498075,39429942,39290842,39234501,39060241,39052286,38937302,38494116
I don’t spend any attention to figure out from the README which of the patches are “online”, and which aren’t since I applied all of them entirely.
But there is no way to rollback an MRP by using the MRP’s patch number: 39834048: DATABASE MRP 19.31.0.0.260818
What happens during rollback?
This is a pretty time-consuming exercise. It rolls back patch after patch. And if I’m not mistaken, it updates the inventory after every removal.
$ORACLE_HOME/OPatch/opatch nrollback -id 39779336,39750798,39661114,39661105,39661089,39598920,39594515,39575331,39498075,39429942,39290842,39234501,39060241,39052286,38937302,38494116 Oracle Interim Patch Installer version 12.2.0.1.51 Copyright (c) 2026, Oracle Corporation. All rights reserved. Oracle Home : /u01/app/oracle/product/19 Central Inventory : /u01/app/oraInventory from : /u01/app/oracle/product/19/oraInst.loc OPatch version : 12.2.0.1.51 OUI version : 12.2.0.7.0 Log file location : /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2026-08-29_14-15-31PM_1.log Patches will be rolled back in the following order: 39779336 39750798 39661114 39661105 39661089 39598920 39594515 39575331 39498075 39429942 39290842 39234501 39060241 39052286 38937302 38494116 The following patch(es) will be rolled back: 39779336 39750798 39661114 39661105 39661089 39598920 39594515 39575331 39498075 39429942 39290842 39234501 39060241 39052286 38937302 38494116 Please shutdown Oracle instances running out of this ORACLE_HOME on the local system. (Oracle Home = '/u01/app/oracle/product/19') Is the local system ready for patching? [y|n] y User Responded with: Y Rolling back patch 39779336... RollbackSession rolling back interim patch '39779336' from OH '/u01/app/oracle/product/19' Patching component oracle.perlint, 5.28.1.0.0... RollbackSession removing interim patch '39779336' from inventory Rolling back patch 39750798... RollbackSession rolling back interim patch '39750798' from OH '/u01/app/oracle/product/19' Patching component oracle.sdo, 19.0.0.0.0... Patching component oracle.rdbms.dbscripts, 19.0.0.0.0... RollbackSession removing interim patch '39750798' from inventory Rolling back patch 39661114... RollbackSession rolling back interim patch '39661114' from OH '/u01/app/oracle/product/19' Patching component oracle.rdbms, 19.0.0.0.0... Patching component oracle.network.rsf, 19.0.0.0.0... Patching component oracle.rdbms.rsf, 19.0.0.0.0... RollbackSession removing interim patch '39661114' from inventory (... cut out many lines for readability ...) Rolling back patch 38494116... RollbackSession rolling back interim patch '38494116' from OH '/u01/app/oracle/product/19' Patching component oracle.ldap.rsf, 19.0.0.0.0... Patching component oracle.rdbms.rsf, 19.0.0.0.0... Patching component oracle.rdbms, 19.0.0.0.0... Patching component oracle.ldap.client, 19.0.0.0.0... RollbackSession removing interim patch '38494116' from inventory Log file location: /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2026-08-29_14-15-31PM_1.log OPatch succeeded.
The whole exercise took from 2:15h until 2:37h – 22 minutes (!!) in total.
If you ask my why I don’t like in-place patching, this is one of the many reasons. It has significant disadvantages compared to out-of-place patching.
datapatch
Of course, in case you are trying this rollback of an MRP for real, you must run datapatch in any case at the end of the process in your database(s). Make sure that all PDBs are opened as well to avoid any issues. datapatch will sort all necessary tasks out for you. You just call it, and it does the job.
Summary
Rolling back an MRP may be necessary especially for those who do in-place patching.
Be prepared that currently the README does not list the whole command, you need to put it together by yourself. And you need to use nrollback, not rollback, since an MRP contains multiple one-off fixes.
In addition, take into account that every patch will be rolled back sequentially. Thus, an MRP with more patches takes quite a bit. As you see in my example, it took 22 minutes – on a fairly fast system with a decent storage.
I highly recommend out-of-place patching. This avoids all the hassle, and it makes patching not even faster but also more solid and secure since you get rid of the ballast, and you have a fallback if something goes wrong.
Further Links and Information
- MRP4 for 19.31.0 – Patch 39834048
- README – MRP4 for 19.31
- KB106882 . formerly known as 888.1
- KB425801: Oracle Database 19c Proactive Monthly Recommended Patches (MRPs) Information
–Mike
