How to rollback an MRP
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.
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:
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.
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.
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.
