This blog post is about a feature not only I but you did ask for actually for a long time. Cleaning up older patch artifacts – improving opatch performance. Both in one opatch release. And opatch 12.2.0.1.37 from April 2023 has it.
Photo by Toon Lambrechts on Unsplash
A little bit of history
One of the longest journey I had ever done in my long time in Oracle was helping customers to find a voice for patch cleanup. Oracle 19c is a long term support release. Many customers upgraded to it already. And you apply patches on a regular basis. For those of you who install patches in-place for various reasons, a common annoyance was that the more often you patch(ed), the longer it took.
After a longer while with many SRs open, a root cause finally was identified: oui-patch.xml. This is an inventory file which tracks all installed patches within one home. Now, opatch mows through this file and all potential patch dependencies dozens of times. And the more you patch, the more entries this file has – and the longer this action takes.
Some customers reported hours of waiting time.
You can read more about this issue here: Binary patching is slow because of the inventory. Luckily, there is no need to edit the file by yourself. Regardless of the fact this workaround obviously was not supported by Oracle Support, it became a bit more tricky with the GI home. And some people commented on the blog that the same problem persists with Fusion Middleware – and editing the file did not solve the issue.
I hope that cleaning up patches does.
In-Place vs Out-Of-Place vs Cloning
Daniel pointed me to this. And I decided to add quickly a clarification when we speak about in-place and out-of-place patching.
When you patch in-place, you will apply a patch or patch bundle to your existing Oracle Home. In this case you keep your inventory, and over time more and more information get added to it. In this case, this procedure described below is exactly what you need.
When you patch out-of-place, we differ between two techniques. The one we highly recommend is a completely brand-new Oracle Home. Then you apply the desired patch bundles and patches to it. See here for how to do this the most easiest way, with Grid Infrastructure and Database homes.
The other technique is the one we don’t recommend: Home Cloning. When you clone your existing home, you basically again install the patches then in-place which will bring back all the constraints with the inventory. In this case you carried over the entire inventory – and everything you will read below applies again.
So please, just keep this in mind.
What is new in opatch 37?
At first, there is a MOS Note 2942102.1 – OPatch 12.2.0.1.37+ Introduces a New Feature to Delete Inactive Patches in the ORACLE_HOME/.patch_storage Directory describing the change.
And let me try this in my 19c environment right away. Plus, let me add some warning upfront: The first call may take as long as you are used to wait when you do the conflict check. Be prepared.
$ ./OPatch/opatch util listorderedinactivepatches Oracle Interim Patch Installer version 12.2.0.1.37 Copyright (c) 2023, 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.37 OUI version : 12.2.0.7.0 Log file location : /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2023-05-15_21-44-33PM_1.log Invoking utility "listorderedinactivepatches" List Inactive patches option provided The oracle home has the following inactive patch(es) and their respective overlay patches: -Inactive RU/CPU 32218454, installed on: Wed Jan 20 00:53:50 CET 2021, with overlays: 33197296 -Inactive RU/CPU 32545013, installed on: Wed Apr 21 14:22:28 CEST 2021, with overlays: 33197296 -Inactive RU/CPU 32904851, installed on: Fri Aug 06 21:09:30 CEST 2021, with overlays: 33197296 -Inactive RU/CPU 29517242, installed on: Thu Apr 18 09:21:17 CEST 2019, with no overlays -Inactive RU/CPU 30557433, installed on: Tue Jan 21 21:13:29 CET 2020, with overlays: 33197296 -Inactive RU/CPU 33192793, installed on: Wed Dec 15 23:04:33 CET 2021, with overlays: 33197296 -Inactive RU/CPU 33515361, installed on: Wed Jan 19 21:37:55 CET 2022, with overlays: 33197296 -Inactive RU/CPU 30869156, installed on: Wed Apr 15 00:10:36 CEST 2020, with overlays: 33197296 -Inactive RU/CPU 31281355, installed on: Wed Jul 15 10:17:40 CEST 2020, with overlays: 33197296 -Inactive RU/CPU 31771877, installed on: Wed Oct 21 11:47:02 CEST 2020, with no overlays -Inactive RU/CPU 33192694, installed on: Thu Dec 16 00:07:03 CET 2021, with no overlays -Inactive RU/CPU 33561310, installed on: Wed Jan 19 22:12:28 CET 2022, with no overlays -Inactive RU/CPU 34086870, installed on: Wed Jul 20 21:11:37 CEST 2022, with no overlays -Inactive RU/CPU 34411846, installed on: Tue Nov 08 22:35:03 CET 2022, with no overlays Total: 14 inactive RU/CPU patch(es) and 8 inactive overlay patch(es). OPatch succeeded.
And I’d wish the cleanup would be as simple as listing the patches. But MOS Note 2942102.1 tells you also about the Known Issues with the command (blame it on me, I was asked to test this very early and was not available).
Again, please be aware that the cleanup call takes a long coffee break at first until it gives you some details:
$ ./OPatch/opatch util deleteinactivepatches Oracle Interim Patch Installer version 12.2.0.1.37 Copyright (c) 2023, 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.37 OUI version : 12.2.0.7.0 Log file location : /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2023-05-15_22-13-57PM_1.log Invoking utility "deleteinactivepatches" Inactive Patches Cleanup option provided Delete Inactive Patches .......
Now I wait … wait … and 21 minutes later … it starts cleaning up.
$ ./OPatch/opatch util deleteinactivepatches Oracle Interim Patch Installer version 12.2.0.1.37 Copyright (c) 2023, 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.37 OUI version : 12.2.0.7.0 Log file location : /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2023-05-15_22-13-57PM_1.log Invoking utility "deleteinactivepatches" Inactive Patches Cleanup option provided Delete Inactive Patches ....... Opatch will delete the following inactive patch(es) and their overlays: -Inactive RU/CPU 32218454, installed on: Wed Jan 20 00:53:50 CET 2021, with overlays: 33197296 -Inactive RU/CPU 32545013, installed on: Wed Apr 21 14:22:28 CEST 2021, with overlays: 33197296 -Inactive RU/CPU 32904851, installed on: Fri Aug 06 21:09:30 CEST 2021, with overlays: 33197296 -Inactive RU/CPU 29517242, installed on: Thu Apr 18 09:21:17 CEST 2019, with no overlays -Inactive RU/CPU 30557433, installed on: Tue Jan 21 21:13:29 CET 2020, with overlays: 33197296 -Inactive RU/CPU 33192793, installed on: Wed Dec 15 23:04:33 CET 2021, with overlays: 33197296 -Inactive RU/CPU 33515361, installed on: Wed Jan 19 21:37:55 CET 2022, with overlays: 33197296 -Inactive RU/CPU 30869156, installed on: Wed Apr 15 00:10:36 CEST 2020, with overlays: 33197296 -Inactive RU/CPU 31281355, installed on: Wed Jul 15 10:17:40 CEST 2020, with overlays: 33197296 -Inactive RU/CPU 31771877, installed on: Wed Oct 21 11:47:02 CEST 2020, with no overlays -Inactive RU/CPU 33192694, installed on: Thu Dec 16 00:07:03 CET 2021, with no overlays -Inactive RU/CPU 33561310, installed on: Wed Jan 19 22:12:28 CET 2022, with no overlays -Inactive RU/CPU 34086870, installed on: Wed Jul 20 21:11:37 CEST 2022, with no overlays Total: 13 inactive RU/CPU patch(es) and 8 inactive overlay patch(es). OPatch will keep the following inactive patch(es) and their overlays: -Inactive RU/CPU 34411846, installed on: Tue Nov 08 22:35:03 CET 2022, with no overlays Total: 1 inactive RU/CPU patch(es) and 0 inactive overlay patch(es). Do you want to proceed? [y|n] y User Responded with: Y Deleted patch: 33197296 Deleted patch: 32218454 Deleted patch: 32545013 Deleted patch: 32904851 Deleted patch: 29517242 Deleted patch: 30557433 Deleted patch: 33192793 Deleted patch: 33515361 Deleted patch: 30869156 Deleted patch: 31281355 Deleted patch: 31771877 Deleted patch: 33192694 Deleted patch: 33561310 Deleted patch: 34086870 OPatch succeeded.
If you wonder about the divergence listing 14 inactive patches at first, and then displaying 13 in the cleanup activity:
My blind guess it that, since the procedure is supposed to keep the previous, last patch, it does list one less when it cleans up. When you compare the two lists, you will quickly find out that this one doesn’t get cleaned up:
-Inactive RU/CPU 34411846, installed on: Tue Nov 08 22:35:03 CET 2022, with no overlays
If you want to keep not only the previous one but the one before as well, then you can edit:
vi $ORACLE_HOME/OPatch/config/opatch.properties OPATCH_HEAP_MEMORY=3072 PS_OBFUSCATION=true RETAIN_INACTIVE_PATCHES=1
Change RETAIN_INACTIVE_PATCHES=1 to RETAIN_INACTIVE_PATCHES=2 for instance in case you want to keep older patches.
Happy Ever After?
Let’s see. I’m doing a quick check for leftovers in $ORACLE_HOME/.patch_storage
cd /u01/app/oracle/product/19/.patch_storage du -h --max-depth=1 92K ./NApply 2.0G ./34133642_Jul_14_2022_16_09_56 1.8G ./34419443_Oct_14_2022_05_25_14 432M ./34411846_Sep_27_2022_09_46_15 4.0K ./NRollback 1.9G ./34765931_Jan_16_2023_07_01_27 432M ./34786990_Dec_6_2022_13_24_50 4.5M ./34972375_Jan_13_2023_08_19_47 50M ./backup_delete_inactive 6.5G .
Ups. That’s still 6.5 GB. But none of them seems to be listed above with the inactive patches.
Why is that?
Let me try the listorderedinactivepatches again.
$ $ORACLE_HOME/OPatch/opatch util listorderedinactivepatches Oracle Interim Patch Installer version 12.2.0.1.37 Copyright (c) 2023, 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.37 OUI version : 12.2.0.7.0 Log file location : /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2023-05-15_22-58-06PM_1.log Invoking utility "listorderedinactivepatches" List Inactive patches option provided The oracle home has the following inactive patch(es) and their respective overlay patches: -Inactive RU/CPU 34133642, installed on: Wed Jul 20 19:22:28 CEST 2022, with no overlays -Inactive RU/CPU 34419443, installed on: Tue Nov 08 22:22:04 CET 2022, with no overlays -Inactive RU/CPU 30125133, installed on: Wed Oct 16 19:27:15 CEST 2019, with no overlays -Inactive RU/CPU 34411846, installed on: Tue Nov 08 22:35:03 CET 2022, with no overlays Total: 4 inactive RU/CPU patch(es) and 0 inactive overlay patch(es). OPatch succeeded.
Now I have a hit. And luckily, the command completed much faster this time.
Certainly, I try to cleanup again:
$ $ORACLE_HOME/OPatch/opatch util deleteinactivepatches Oracle Interim Patch Installer version 12.2.0.1.37 Copyright (c) 2023, 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.37 OUI version : 12.2.0.7.0 Log file location : /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2023-05-15_23-00-25PM_1.log Invoking utility "deleteinactivepatches" Inactive Patches Cleanup option provided Delete Inactive Patches ....... Opatch will delete the following inactive patch(es) and their overlays: -Inactive RU/CPU 34133642, installed on: Wed Jul 20 19:22:28 CEST 2022, with no overlays -Inactive RU/CPU 34419443, installed on: Tue Nov 08 22:22:04 CET 2022, with no overlays -Inactive RU/CPU 30125133, installed on: Wed Oct 16 19:27:15 CEST 2019, with no overlays Total: 3 inactive RU/CPU patch(es) and 0 inactive overlay patch(es). OPatch will keep the following inactive patch(es) and their overlays: -Inactive RU/CPU 34411846, installed on: Tue Nov 08 22:35:03 CET 2022, with no overlays Total: 1 inactive RU/CPU patch(es) and 0 inactive overlay patch(es). Do you want to proceed? [y|n] y User Responded with: Y Deleted patch: 34133642 Deleted patch: 34419443 Deleted patch: 30125133 OPatch succeeded.
Let me check .patch_storage another time:
cd /u01/app/oracle/product/19/.patch_storage du -h --max-depth=1 92K ./NApply 432M ./34411846_Sep_27_2022_09_46_15 4.0K ./NRollback 1.9G ./34765931_Jan_16_2023_07_01_27 432M ./34786990_Dec_6_2022_13_24_50 4.5M ./34972375_Jan_13_2023_08_19_47 68M ./backup_delete_inactive 2.8G .
One patch bundle is supposed to be kept – and I have other things patched in my home than just the RU itself.
$ $ORACLE_HOME/OPatch/opatch util listorderedinactivepatches Oracle Interim Patch Installer version 12.2.0.1.37 Copyright (c) 2023, 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.37 OUI version : 12.2.0.7.0 Log file location : /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2023-05-15_23-06-08PM_1.log Invoking utility "listorderedinactivepatches" List Inactive patches option provided The oracle home has the following inactive patch(es) and their respective overlay patches: -Inactive RU/CPU 34411846, installed on: Tue Nov 08 22:35:03 CET 2022, with no overlays Total: 1 inactive RU/CPU patch(es) and 0 inactive overlay patch(es). OPatch succeeded.
Luckily, the command runs faster with every cleanup. That is expected then now opatch does not need to mow through a ton of information anymore. And the case that the cleanup may need several tries is documented in MOS Note 2942102.1.
$ $ORACLE_HOME/OPatch/opatch util deleteinactivepatches Oracle Interim Patch Installer version 12.2.0.1.37 Copyright (c) 2023, 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.37 OUI version : 12.2.0.7.0 Log file location : /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2023-05-15_23-07-21PM_1.log Invoking utility "deleteinactivepatches" Inactive Patches Cleanup option provided Delete Inactive Patches ....... Warning: The oracle home has only 1 inactive RU/CPU, therefore no inactive RU/CPU is eligible for delete Warning: The oracle home must have at least 2, or more inactive RU/CPU for delete inactive patches operation to work. OPatch does not delete any inactive patches. OPatch succeeded.
Good. That is expected as well. One is supposed to stay,
Is there more?
Of course, I’d like to test whether I could get rid of the last one as well.
Does it work to change:
vi $ORACLE_HOME/OPatch/config/opatch.properties OPATCH_HEAP_MEMORY=3072 PS_OBFUSCATION=true RETAIN_INACTIVE_PATCHES=0
Nope. That does not override the engraved protection.
And older releases?
Of course, I needed to check whether this works with older releases as well.
$ $ORACLE_HOME/OPatch/opatch util listorderedinactivepatches Oracle Interim Patch Installer version 12.2.0.1.37 Copyright (c) 2023, Oracle Corporation. All rights reserved. Oracle Home : /u01/app/oracle/product/12.2.0.1 Central Inventory : /u01/app/oraInventory from : /u01/app/oracle/product/12.2.0.1/oraInst.loc OPatch version : 12.2.0.1.37 OUI version : 12.2.0.1.4 Log file location : /u01/app/oracle/product/12.2.0.1/cfgtoollogs/opatch/opatch2023-05-15_23-21-49PM_1.log Invoking utility "listorderedinactivepatches" List Inactive patches option provided The oracle home has the following inactive patch(es) and their respective overlay patches: -Inactive RU/CPU 28822515, installed on: Fri Feb 15 22:23:59 CET 2019, with no overlays -Inactive RU/CPU 29314339, installed on: Thu Apr 18 22:21:59 CEST 2019, with no overlays -Inactive RU/CPU 30138470, installed on: Wed Oct 16 19:59:51 CEST 2019, with overlays: 33197448 -Inactive RU/CPU 30593149, installed on: Tue Jan 21 21:42:08 CET 2020, with overlays: 33197448 -Inactive RU/CPU 30886680, installed on: Tue Apr 14 23:47:24 CEST 2020, with overlays: 33197448 -Inactive RU/CPU 31312468, installed on: Wed Jul 15 10:52:28 CEST 2020, with overlays: 33197448 -Inactive RU/CPU 31741641, installed on: Wed Oct 21 11:29:07 CEST 2020, with overlays: 33197448 -Inactive RU/CPU 32228578, installed on: Wed Jan 20 00:30:57 CET 2021, with overlays: 33197448 -Inactive RU/CPU 32507738, installed on: Wed Apr 21 15:06:17 CEST 2021, with overlays: 33197448 -Inactive RU/CPU 33261817, installed on: Thu Dec 16 09:03:45 CET 2021, with overlays: 33197448 -Inactive RU/CPU 33587128, installed on: Wed Jan 19 22:23:18 CET 2022, with no overlays Total: 11 inactive RU/CPU patch(es) and 8 inactive overlay patch(es). OPatch succeeded. $ $ORACLE_HOME/OPatch/opatch util deleteinactivepatches Oracle Interim Patch Installer version 12.2.0.1.37 Copyright (c) 2023, Oracle Corporation. All rights reserved. Oracle Home : /u01/app/oracle/product/12.2.0.1 Central Inventory : /u01/app/oraInventory from : /u01/app/oracle/product/12.2.0.1/oraInst.loc OPatch version : 12.2.0.1.37 OUI version : 12.2.0.1.4 Log file location : /u01/app/oracle/product/12.2.0.1/cfgtoollogs/opatch/opatch2023-05-15_23-23-17PM_1.log Invoking utility "deleteinactivepatches" Inactive Patches Cleanup option provided Delete Inactive Patches ....... Opatch will delete the following inactive patch(es) and their overlays: -Inactive RU/CPU 28822515, installed on: Fri Feb 15 22:23:59 CET 2019, with no overlays -Inactive RU/CPU 29314339, installed on: Thu Apr 18 22:21:59 CEST 2019, with no overlays -Inactive RU/CPU 30138470, installed on: Wed Oct 16 19:59:51 CEST 2019, with overlays: 33197448 -Inactive RU/CPU 30593149, installed on: Tue Jan 21 21:42:08 CET 2020, with overlays: 33197448 -Inactive RU/CPU 30886680, installed on: Tue Apr 14 23:47:24 CEST 2020, with overlays: 33197448 -Inactive RU/CPU 31312468, installed on: Wed Jul 15 10:52:28 CEST 2020, with overlays: 33197448 -Inactive RU/CPU 31741641, installed on: Wed Oct 21 11:29:07 CEST 2020, with overlays: 33197448 -Inactive RU/CPU 32228578, installed on: Wed Jan 20 00:30:57 CET 2021, with overlays: 33197448 -Inactive RU/CPU 32507738, installed on: Wed Apr 21 15:06:17 CEST 2021, with overlays: 33197448 -Inactive RU/CPU 33261817, installed on: Thu Dec 16 09:03:45 CET 2021, with overlays: 33197448 Total: 10 inactive RU/CPU patch(es) and 8 inactive overlay patch(es). OPatch will keep the following inactive patch(es) and their overlays: -Inactive RU/CPU 33587128, installed on: Wed Jan 19 22:23:18 CET 2022, with no overlays Total: 1 inactive RU/CPU patch(es) and 0 inactive overlay patch(es). Do you want to proceed? [y|n] y User Responded with: Y Deleted patch: 28822515 Deleted patch: 29314339 Deleted patch: 33197448 Deleted patch: 30138470 Deleted patch: 30593149 Deleted patch: 30886680 Deleted patch: 31312468 Deleted patch: 31741641 Deleted patch: 32228578 Deleted patch: 32507738 Deleted patch: 33261817 OPatch succeeded.
The really cool thing here:
I had cleaned up .patch_storage by myself manually. But of course only the files and directories. This way now the inventory is cleaned up as well.
But it would be too sweet if it would work with all releases. Unfortunately, with my 12.1.0.2 installation, the result is:
$ $ORACLE_HOME/OPatch/opatch util listorderedinactivepatches Oracle Interim Patch Installer version 12.2.0.1.37 Copyright (c) 2023, Oracle Corporation. All rights reserved. Oracle Home : /u01/app/oracle/product/12.1.0.2 Central Inventory : /u01/app/oraInventory from : /u01/app/oracle/product/12.1.0.2/oraInst.loc OPatch version : 12.2.0.1.37 OUI version : 12.1.0.2.0 Log file location : /u01/app/oracle/product/12.1.0.2/cfgtoollogs/opatch/opatch2023-05-15_23-45-43PM_1.log Invoking utility "listorderedinactivepatches" List Inactive patches option provided The oracle home has the following inactive patch(es) and their respective overlay patches: No Inactive RU/CPU patches found in OH OPatch succeeded.
But my .patch_storage contained almost 9GB.
du -h --max-depth=0 ./.patch_storage/ 8.8G ./.patch_storage/
Silence is golden
Finally, there is the option to run the delete operation silently without asking for confirmation. When you look at the above output of my removal actions, you may have seen this:
... -Inactive RU/CPU 32507738, installed on: Wed Apr 21 15:06:17 CEST 2021, with overlays: 33197448 -Inactive RU/CPU 33261817, installed on: Thu Dec 16 09:03:45 CET 2021, with overlays: 33197448 Total: 10 inactive RU/CPU patch(es) and 8 inactive overlay patch(es). OPatch will keep the following inactive patch(es) and their overlays: -Inactive RU/CPU 33587128, installed on: Wed Jan 19 22:23:18 CET 2022, with no overlays Total: 1 inactive RU/CPU patch(es) and 0 inactive overlay patch(es). Do you want to proceed? [y|n] y User Responded with: Y Deleted patch: 28822515 Deleted patch: 29314339 Deleted patch: 33197448 ...
If you want to avoid the Do you want to proceed? [y|n] message waiting for your confirmation, you simply start the removal command with the -silent switch:
$ORACLE_HOME/OPatch/opatch util deleteinactivepatches -silent
Summary
I am quite happy about this new feature. It works fine but seems to require multiple attempts in some cases. But it does what it’s supposed to be, at least for homes from Oracle 12.2.0.1 and newer.
The feature does not work – at least in my environment – with 12.1.0.2 and older homes. I guess, this wasn’t intended and neither tested. But please be aware of it.
In addition, I like the fact that I can cleanup a home’s inventory with this process when I manually deleted files from .patch_storage and .opatchauto_storage by myself already. That is very helpful indeed.
What do I miss right now?
I would like to have opatch and opatchauto allow me to do this automatically. This way, a patch run would cleanup automatically afterwards. And again, keep in mind that this only affects you in case you patch in-place. If you patch out-of-place you will remove your previous home anyway including all contents. And you start always with a fresh inventory as long as you did not clone the existing home.
And by the way, this feature is supported for FMW and OEM as well: MOS Note: 2942050.1 – OPatch 13.9.4.2.12+ Introduces a New Feature to Delete Inactive Patches in the ORACLE_HOME/.patch_storage Directory
Annotation and Known Issues
As of now in the first drop of this functionality there are still a few glitches. I try to list them here – those may be fixed with opatch 38/39 then.
- When you cleanup in an 12.2.0.1 environment, the original patch apply date my be altered. This isn’t a bigger problem but you may wonder why several cleanup runs actually could alter the date in the list. This has to do with the OUI’s 12.2.0.1 inventory and won’t be fixed anymore due to the fact that there is no bug fixing support for 12.2.0.1 anymore available.
- Several cleanup runs may be necessary. This is a restriction in opatch 37 tied to the structure of the inventory and the overlay patches. Please take this as granted now. And with the next available version one run should be enough to cleanup.
- The wrong bundle “survives” – and does not take care on important dependencies. We’ve had one customer realizing that after several cleanup runs only the OJVM RU stayed – everything else got removed. This is obviously not correct. The opatch team is working on the case. Hence, you may stop the cleanup as soon as you see that only one RU with dependent patches is kept. I’ll update the blog post as soon as the case is more clear and when I know when it will be fixed.
Further Links and Information
- Blog Post: Binary patching is slow because of the inventory
- MOS Note 2942102.1 – OPatch 12.2.0.1.37+ Introduces a New Feature to Delete Inactive Patches in the ORACLE_HOME/.patch_storage Directory
- MOS Note: 2942050.1 – OPatch 13.9.4.2.12+ Introduces a New Feature to Delete Inactive Patches in the ORACLE_HOME/.patch_storage Directory
–Mike
Hello, thank you for blog post. What will happen, when I run this command in env, where I have already cleaned .patch_storage manually? Will it just clean xml? Thank you
Hi,
please read in paragraph “And Older Releases?” where I wrote:
“The really cool thing here:
I had cleaned up .patch_storage by myself manually. But of course only the files and directories. This way now the inventory is cleaned up as well.”
Cheers
Mike
It is nice to reduce the size of my patch directory from 30GB to 5 GB on each of 3 servers!
Dear Mike,
thanks a lot for this very useful article. I assume this will work the same for the GRID_HOME?
I did a first per-liminary test and it seems 5 older RUs are constantly showing up as to be cleaned, even after running the delete option several times now.
But the IDs of the cleaned patches would differ from the patch IDs detected in the previous step. I am not 100 % sure if I already tried to cleanup manually before.
Will test on another VM to re-confirm this.
But I again assume the process is supposed to cleanup the XML registry as well.
Best regards, Matthias.
Hi Matthias,
there is still a sort-of-multi-step process right now. The next version should be able to clean up in one pass (I’d gotten a promise).
Please be patient and let us wait for opatch 38/39.
And generally, yes – this is supposed to work with GI as well.
Cheers
Mike
Seems buggy. Apart from, as you say, having to run deleteinactivepatches multiple times to actually delete the patches it says it is deleting. It also changes the last remaining patch applied date and time to today. (I tried this on 12.2.0.1 oracle home)
Hi Paul,
can you please elaborate this a bit more in detail?
I am in contact with the opatch team and can tell them quickly.
Cheers,
Mike
It created a folder called “backup_delete_inactive” under .patch_storage but doesn’t seem to have deleted anything in .patch_storage.
Hi Paul,
please give me all steps and commands you were issuing.
If that is too complex on the blog since it does not allow proper formatting, drop me an email (mike.dietrich …. oracle.com) or send me the SR number where you uploaded the logs to.
Cheers,
Mike
Hello Mike, one of your followers here. one quick question: Can this clean-up be done with the database up?
Hi Jean-Jules,
yes of course – there is no downtime involved in this activity.
Cheers,
Mike
Finally, finally !!!!
Great feature which took too long to implment. I know, Mike, that you are focused on database only, but still I want to ask you as you have the network and contact within the red beast 🙂
I ran the cleanup within grid home and it seems like this did the same – cleaned up and freed up a lot of giga.
But I also tried the feature within Oracle Enterprise home and opatch found inactive patches there as well. could you please check out if this is supported? It would be great to know:
[oracle@xxxxxxxxx ~]$ /u01/app/oracle/em135/middleware/OPatch/opatch util listorderedinactivepatches
Oracle Interim Patch Installer version 13.9.4.2.12
Copyright (c) 2023, Oracle Corporation. All rights reserved.
Oracle Home : /u01/app/oracle/em135/middleware
Central Inventory : /u01/app/oraInventory
from : /u01/app/oracle/em135/middleware/oraInst.loc
OPatch version : 13.9.4.2.12
OUI version : 13.9.4.0.0
Log file location : /u01/app/oracle/em135/middleware/cfgtoollogs/opatch/opatch2023-05-23_19-04-58PM_1.log
OPatch detects the Middleware Home as “/u01/app/oracle/em135/middleware”
Invoking utility “listorderedinactivepatches”
List Inactive patches option provided
The oracle home has the following inactive patch(es) and their respective overlay patches:
-Inactive RU/CPU 33424205, installed on: Mon Jan 17 15:06:53 CET 2022, with overlays:
-Inactive RU/CPU 33567421, installed on: Fri Feb 11 13:57:56 CET 2022, with overlays:
-Inactive RU/CPU 32941631, installed on: Mon Jan 17 15:05:09 CET 2022, with overlays:
-Inactive RU/CPU 34430441, installed on: Tue Nov 01 17:44:04 CET 2022, with overlays:
-Inactive RU/CPU 34801809, installed on: Mon Feb 13 13:26:01 CET 2023, with overlays:
Total: 5 inactive RU/CPU patch(es) and 0 inactive overlay patch(es).
OPatch succeeded.
Hi Kurt,
let me check and get back to you then.
Cheers,
Mike
Thx
It does – see here:
Oracle Support Document 2942050.1 (OPatch 13.9.4.2.12+ Introduces a New Feature to Delete Inactive Patches in the ORACLE_HOME/.patch_storage Directory) can be found at: https://support.oracle.com/epmos/faces/DocumentDisplay?id=2942050.1
I’m updating the blog post.
Cheers,
Mike
Really great. The OEM home is really growing so it will be nice to clean up there as well 👍👍
Hello Mike,
I was waiting for this fix long time! Thanks a lot!
I will apply this fix to reduce overall opatch time. I always do patching in place.
Regards,
Alejandra
Hi Alejandra,
you were not the only one 🙂
Thanks for your patience,
Mike
Hi Mike,
Is there a much faster way to delete inactive patches as of now? Multiple times of running the command take much time.
Thank you.
Stay tuned for the next version – I have it in test already 🙂
Then you will need only one single call.
Cheers
Mike
Hi, Mike! 🙂
Do we have the only one single call already?
Regards
Clyde
Hi Clyde,
the opatch released this week has it already.
Cheers,
Mike
Hi Mike! Thank you so much for this article! Our quarterly patching was a breeze after removing the old patches. And the disk space savings is tremendous.
But if anyone is planning to perform cleanups in parallel, beware of what an atrocious memory pig OPATCH is. I ran the cleanup for multiple databases (on the same server) in parallel, and watched the system memory drop precipitously. The Java processes were using over 2.3 gigabytes of memory per database and not releasing any of it until the whole job was done some 10-15 minutes later.
Hi Tim,
this is an awesome hint!! I was not aware that it will consume that much mem.
Thanks a lot!!
Cheers,
Mike
Started with 19.7 and almost 🙂 patching each RU up to RU 19.18 on GRID and RDBMS.
I could reclaim 25Gb space from /u01.
This new opatch function is great!!
Thanks for your feedback, Peter!
And one of the reasons we’ve got this is your constant exchange with us!!
So credits to you as well!!
Cheers,
Mike