Opatch Rollback Id

[Hilda Bagnoli]

Fora long long time many customers asked for a solution. Just briefly browsing the bug database reveals a decent number of bugs and enhancement request filed against or for opatch to do a proper cleanup.

Hi Mike,

nice stuff. What about consolidation of old patches on a host with mulitple oracle homes (identical versions) into just one archive location? Does unarchive remove the patch from the archive location and so make it unavailable for the other homes?

Need to ask: do we really need n-1 and older quarterly patchsets in our OH to be able to apply future patchests?

If i install base release and every quarterly patchset. For examle, i install 19.3 then 19.11 then 19.12 then 19.13 and so on.

So, i definitely know that:

1) i need the latest patchset only.

2) i need to be able to install all the future patchsets: 19.14, 19.15 and so on.

Now many patchets i need to keep in OH ?

It bothers me that you can not change the Archive location after the fact, and if I try to unarchive from a new location, the system will require me to move the archived patches into the old archive location.

I ran into the problem of opatch taking more and more time for any simple lsinv / apply / rollback operations in 19c and this is directly related to the number of inactive RU patches available in the home. More the inactive RUs and longer the patching activities. Came up with the out-of-the box solution and it is documented at -my-oracle-19c-db-patching-slow-balaji-govindu/

After running through this process, the same patches are still listed as inactive. Is there a way I can tell what patches have been archived outside of looking at the zip files in the archive directory?

Also, if I have multiple Oracle Homes, all created from the same Gold image, could archive them all but only keep one copy of the zip files and delete the rest, knowing if I need to unarchive them I would have to put them into the correctly named archive directory?

DESCRIPTION

This operation helps to archive the patches stored under

ORACLE_HOME/.patch_storage to custom storage location.

NOTE: Patch directories in .patch_storage will be used during

rollback operation.

I created and executed a rollback task. After the task was completed and the client was restarted, the client update was still not uninstalled.

After studying the script, I found that in the Window10 1909 version I used, the registry key name did not match, and not all the KB provided in the analysis could be uninstalled.

Will someone correct the above problems?

I may discuss this in another blog post since this is interesting as well. A PDB is supposed to be unplugged from 19.17.0 on MS Windows, and plugged (or migrated) into a 19.17.0 CDB on Linux. This sounds straight forward but may offer you some challenges as well, especially because of the different directories.

Please note that the above command will rollback all patches from the REGISTRY within the database from all containers. So if you execute the above command in a container database environment, it will rollback patches from CDB$ROOT, PDB$SEED and all open PDBs.

While attempting to rollback a previous CPU's DB Bundle from a Runtime Client home, my functioning "opatch" hung for 31 minutes before continuing on its merry way...uninstalling the entire bundle in about 23 seconds.

I killed it a few times shy of the 31 minutes thinking it was truly permanently hung...possibly having something to do with upgrading this VM from Windows 2012 R2 to 2019 since the last patching. OPatch commands "version" and "lsinventory" are swift to return.

- It is relatively easier on UNIX because you don't have to worry about registry entries and you can even perform multiple installations on the same box as long as you use different locations and ports.

One solutions that I know works for a lot of my customers is virtualization. Before a fix pack or service pack is installed, they stop all BO XI services, take a backup of the database and FRS and snapshot the VM.

If anything should go wrong, it's relatively easy to rollback to the previous situation. However, this means that the problem should either come up while applying the fix/service pack, or shortly afterwards; as rolling back would mean a potential loss of data (reports, universes, ...).

To avoid unexpected issues, I would advise you to alway extensively test any fix/service pack on a separate, if possible identical environment. Due this for as long as you need to feel comfortable with the update. Meanwhile, keep an eye on the forums to see if others are experiencing any issues.

Remark: the snapshot could of course be replaced by a system backup when you're working with a physical system instead of a VM, but reverting to a snapshot is far easier (and faster) than restoring a backup.

Thank you for your inputs. I think your idea of using a virtual environment makes a lot of sense. I am not sure at this point if I will be able to set up a virtual infrastructure for testing patches and upgrades etc, but that is the route I want to take.

Working with physical systems, how can we be sure of no windows registry corruption if I were to "unistall" or "rollback" specific patches on the box. I think it would still need a complete system image (snapshot) that can be restored on the physical box if things were to get corrupted. Is that assumption correct?

Tim's response certainly can be used as an alternative, although it is more cumbersome than restoring a backup taken before the patch. Also, if you do follow this scenario, make sure you do not reset the existing CMS repository when installing BOE again.

When you download the CPU patch, it includes a docs folder containing a readme file with all the instructions necessary for uninstalling the patch. The basic command to perform the rollback will resemble:

2. Perform the Rollback

-id : Specify the reference ID of the patch to be rolled back.

-connectString : Connect strings for the Oracle database.

-delay : Specify a delay value.

-init [-opatch_init_end]: Parameters for the init script.

-invPtrLoc : Path to the oraInst.loc file.

-jre : Location of the Java Runtime Environment (JRE).

-local: Perform the rollback on the local system.

-local_node : Specify the local node name.

-no_relink: Skip relinking.

-oh : Path to the Oracle Home directory.

-ph : Location of the patch.

-post [ -opatch_post_end]: Parameters for the post script.

-pre [-opatch_pre_end]: Parameters for the pre script.

-property_file : Path to a property file.

-ptlConnect : Portal connect string.

-ptlPassword : Portal password.

-ptlSchema : Portal schema.

-remote_nodes : List of remote nodes for rollback.

-retry : Specify a retry value.

-runSql: Run SQL scripts.

-silent: Perform the rollback silently.

-sqlScript : Path to the SQL script file.

-verbose: Verbose output for the rollback process.

Notes:

- Replace with the actual reference ID of the patch to be rolled back.

- Modify other options as needed based on your system configuration.

- Ensure you have the necessary permissions and backups before proceeding with the rollback.

Well it's been almost three years since my last post and while I haven't blogged for that long I am still working with Oracle technologies. I joined Accenture Enkitec Group in February 2018 and I've been working on a big migration project to Oracle Cloud Infrastructure for a UK customer since then. I should have posted some of the cloud stuff I did or issues I encountered but I didn't for one reason or another. I hope I can resume blogging and as before share issues and interesting things that I've been doing. Now on to the main topic of this post.

You are probably reading this because datapatch failed already ? Don't worry just re-run datapatch and this time it will rollback the patch successfully. If you have happen to be reading this prior datapatch then make sure you comment the drop command in advance.

Also, the following MOS note is very useful to track this bug as it's been superseded four times now:

Performance Issues While Monitoring the Unified Audit Trail of an Oracle12c Database (Doc ID 2063340.1)

I've been mostly busy with OCI-C and OCI in the past three years but occasionally I have to patch Exadata systems. That's what I have been doing every quarter for a Norwegian customer, patch their prod and non-prod Exadata systems in two consecutive weekends. The Exadata configuration was an X5-2

As the title suggests, I tried the other day to provision database home 19c on my X8M system and it failed. I managed quickly to find what the issue is and it comes down to file permissions. The Exadata Cloud Service X8M is using the new resource model so that

Few days ago Oracle announced another OCI feature. You can now upgrade Exadata Cloud Service databases to Oracle Database version 19c through the console or API. It's great to see the availability of these new features, as simple as they are it's what makes the cloud more feasible and mature.

Seeing a nice and good update with a new wipe with lots of good things to it trough twitch and youtube and decieded to come back on EFT only to get more bugs and problems than eft had early on trown in our faces please undo this patch asap and make the game playable again...

Since the update I can not load into the game....I get all the way to awaiting start or whatever it says...usually that means its about to load me into the match....now it just sits there and keeps ticking away at the time until everntually it says Game aborted. Been trying for hours to play...was working fine until I got kicked off for the update ....HELP!

Like, explain to me, fellow game devs that somehow manage to break features every patch despite working on this game and its engine for over 8 years (hello audio that has been in a broken state since reserve expansion). Explain to me why the recoil changes on this patch. Explain to me the reasoning for making the base M9 have more recoil than the ash-12. Explain to me the reasoning for making shotguns & pistols so ducking worst.

Where they the issue? Was there any issue actually with any gun? For once I finally see people running more guns than just RD-mutant-AKM, and somehow that's a bad thing? Is that it?

What's the ducking point of this change. Nobody wanted it, the games didnt need it, everybody gave you poo for the half assed retarded recoil change last wipe, so much so you FIXED IT IN 14.0, so why do you glue sniffers decide to revert it?

GIVE ME A GOOD ducking REASON, because I am confused about your ability to understand your own game and community.

Nobody wants a saiga-12 that jumps the ceiling at the 2nd bullet. Nobody wants a pistol that jumps 30 on the second bullet. I am playing a PMC or a 14yo girl weighting 35 kilos?

Revert the recoil changes made this patch. It has made the game worst, it is an artificial bandaid for a problem that doesnt exist. Imagine being able to make your gun shoot where you're pointing it at. Novelty concept am I right?

3a8082e126