Can I cleanup the previous Patch Bundles with opatch?

Today I will step on mined territory. Can I cleanup the previous Patch Bundles with opatch?  Or can I just wipe out the old ones? That is a question which will bring people with temper quickly close to explosion. But let me start step by step, especially for those of you who aren’t familiar with this topic.

Can I cleanup the previous Patch Bundles with opatch?

The secret directories

You  L O V E  secrets, don’t you? No? Well … then let me start with a secret which isn’t a secret to most people making it even more obscure.

When you install a patch with opatch or opatchauto, there a lot of files will be stored in a hidden directory:

  • $ORACLE_HOME/.patch_storage
  • $ORACLE_HOME/.opatchauto_storage

Why are these directories hidden? I seriously have no idea. Maybe to indicate “Don’t touch anything! No Trespassing! Stay Away! Private Property“. But as usual when you try to hide something, you just make it more interesting. I just doubt that this was the intention.

Anyhow, when you look closer, especially when you have some sort of patch history like I have in my environments, you may quickly realized: There is a lot of space used.

In my case, these directories all together consume a bit over 10GB in my environment:

[CDB2] oracle@hol:/u01/app/oracle/product/19/.patch_storage
$ ls
32218454_Jan_14_2021_16_24_38               
32545013_Apr_16_2021_07_40_05     
32904851_Jul_20_2021_09_21_24    
33192694_Sep_14_2021_16_48_27     
33192793_Oct_15_2021_07_09_52
33197296_Oct_4_2021_00_44_36
33515361_Jan_13_2022_06_14_07
33561310_Jan_5_2022_08_13_10
interim_inventory.txt
LatestOPatchSession.properties
NApply
newdirs.txt
record_inventory.txt

10017056

Don’t wipe it out!

Rule no.1 given by the patching owners: Don’t wipe out this directory. It may be needed to rollback a patch later on.

Still I know from some people who remove the entire directory from time to time to free up space. And so far, I haven’t heard anywhere that this will break a future patch. If I did this in my environment, I made sure that the last two subdirectories were always kept – just in case. But I don’t have many one-off or merge patches. Hence, I can’t really tell you whether this was clever or just dumb. And this brings me back to …

Rule no.1:
Don’t wipe out .patch_storage and .opatchauto_storage.

opatch util cleanup

Let me make this chapter pretty short.

Rule no.2:
opatch util cleanup does not do what you’d expect it to do. And sometimes it does a bit more than you’d expect it to do.

What is the solution?

Addition May 16, 2023:

Before you read on, better jump to this blog post. With opatch 37, released in April 2023, a cleanup option is available – and this significantly improves performance:

 

For a 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.

The most interesting one I could find was:

  • Enh 31138227 – $OH/.PATCH_STORAGE KEEP N-1 VERSIONS ONLY FOR BETTER SPACE CONSUMPTION

I would have hoped for such a solution since I usually do this on my Linux system:

# package-cleanup --oldkernels --count=1

which removes older kernels I won’t need or use anymore.

From above enhancement request I learned that there is a new opatch option available from version 26 on:

./opatch util archive -patches 123456,1122334 -archive_dir /dirx

The first problem here is that the usual -help option in opatch doesn’t tell you about it. And since the Enhancement Request is non-public you can’t see the details. But the secret keyword is: opatch util archive -help

Annotation:

Actually I learned from the feature owners that there is a simple reason why the help didn’t show you the command options on the help’s higher level – the feature was not “live” yet. Since I learned about it through a bug I filed, I tried it out and wasn’t aware that it’s not public yet. Still, it works fine.

$ ./opatch util archive -help
Oracle Interim Patch Installer version 12.2.0.1.28
Copyright (c) 2022, Oracle Corporation.  All rights reserved.   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.


SYNTAX
opatch util archive [-patches  <List of Patch ids with comma separated>]
			[-archive_dir <path to store the archive files>]
                

OPTIONS

       -patches
              A comma separated list of patches to be given for 
              archive.

       -archive_dir
              Specify custom storage path to store the patches 
              which are going to be archived.
              
		NOTE: All options are mandatory.  

RECOMMENDATION :
  To archive patches, opatch recommends the following 
    1. Archiving inactive patches : 
        Run the following command to get inactive patches :  "OPatch/opatch lsinv -inactive" 
		
Example
	opatch util archive -patches 123456,1122334 -archive_dir /dir1/dir2/		            


OPatch succeeded.

So this is the new command: opatch util archive -patches … -archive_dir …

Don’t get puzzled by the brackets in the command syntax. All options are MANDATORY, and not optional.

This is the promise to solve the problem of gigabytes of old patch content just wasting space on your hard drive. Let’s see whether this solves your problem as well.

Which patch directories are candidates?

When you search for inactive homes, then this opatch command is most helpful but gives a lengthy output:

$ ./opatch lsinv -inactive

It tells you the patch numbers of the inactive ones. Those are the ones you want to pass on to the archive command below.

opatch util archive

As you read before, even though I cleaned up illegally by myself before, still more than 10GB get consumed on my machine.

Still, the archive command will do a space check (see below in What if …)

$ ./opatch util archive -patches 32218454,32545013,32904851,33192694,33192793,33197296,33515361,33561310 -archive_dir /media/sf_TEMP/
Oracle Interim Patch Installer version 12.2.0.1.28
Copyright (c) 2022, 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.28
OUI version       : 12.2.0.7.0
Log file location : /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2022-01-20_14-08-15PM_1.log

Invoking utility "archive"

Archiving Patch - 33515361 ....
Sucessfully archived patch - 33515361 in /media/sf_TEMP/33515361_Jan_13_2022_06_14_07.zip

Archiving Patch - 32545013 ....
Sucessfully archived patch - 32545013 in /media/sf_TEMP/32545013_Apr_16_2021_07_40_05.zip

Archiving Patch - 32904851 ....
Sucessfully archived patch - 32904851 in /media/sf_TEMP/32904851_Jul_20_2021_09_21_24.zip

Archiving Patch - 33197296 ....
Sucessfully archived patch - 33197296 in /media/sf_TEMP/33197296_Oct_4_2021_00_44_36.zip

Archiving Patch - 33192793 ....
Sucessfully archived patch - 33192793 in /media/sf_TEMP/33192793_Oct_15_2021_07_09_52.zip

Archiving Patch - 33192694 ....
Sucessfully archived patch - 33192694 in /media/sf_TEMP/33192694_Sep_14_2021_16_48_27.zip

Archiving Patch - 33561310 ....
Sucessfully archived patch - 33561310 in /media/sf_TEMP/33561310_Jan_5_2022_08_13_10.zip

Archiving Patch - 32218454 ....
Sucessfully archived patch - 32218454 in /media/sf_TEMP/32218454_Jan_14_2021_16_24_38.zip
Succesfully verified the created archive. Deleting the original patch from  - /u01/app/oracle/product/19/.patch_storage/33515361_Jan_13_2022_06_14_07
Succesfully verified the created archive. Deleting the original patch from  - /u01/app/oracle/product/19/.patch_storage/32545013_Apr_16_2021_07_40_05
Succesfully verified the created archive. Deleting the original patch from  - /u01/app/oracle/product/19/.patch_storage/32904851_Jul_20_2021_09_21_24
Succesfully verified the created archive. Deleting the original patch from  - /u01/app/oracle/product/19/.patch_storage/33197296_Oct_4_2021_00_44_36
Succesfully verified the created archive. Deleting the original patch from  - /u01/app/oracle/product/19/.patch_storage/33192793_Oct_15_2021_07_09_52
Succesfully verified the created archive. Deleting the original patch from  - /u01/app/oracle/product/19/.patch_storage/33192694_Sep_14_2021_16_48_27
Succesfully verified the created archive. Deleting the original patch from  - /u01/app/oracle/product/19/.patch_storage/33561310_Jan_5_2022_08_13_10
Succesfully verified the created archive. Deleting the original patch from  - /u01/app/oracle/product/19/.patch_storage/32218454_Jan_14_2021_16_24_38
Patch archive operation completed successfully.

OPatch succeeded.

What if …

Of course, with opatch there is always plenty of fun with opatch error messages.

My first attempt failed:

$ ./opatch util archive -patches 32218454,32545013,32904851,33192694,33192793,33197296,33515361,33561310 -archive_dir /home/oracle/patch_storage
Oracle Interim Patch Installer version 12.2.0.1.28
Copyright (c) 2022, 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.28
OUI version       : 12.2.0.7.0
Log file location : /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2022-01-20_11-48-35AM_1.log

Invoking utility "archive"
Patch archive operation failed.
UtilSession failed to Archive the patches 
UtilSession failed: Patch archive operation failed.

OPatch failed with error code 73

Why did it fail? I needed to check the logfile to find out:

[Jan 20, 2022 11:48:37 AM] [INFO]   Archive directory: /home/oracle/patch_storage has required permission to archive the patches
[Jan 20, 2022 11:48:37 AM] [INFO]   Space for patch :: /u01/app/oracle/product/19/.patch_storage/32218454_Jan_14_2021_16_24_38 :: 1715352980
[Jan 20, 2022 11:48:37 AM] [INFO]   Space for patch :: /u01/app/oracle/product/19/.patch_storage/32545013_Apr_16_2021_07_40_05 :: 1974092970
[Jan 20, 2022 11:48:37 AM] [INFO]   Space for patch :: /u01/app/oracle/product/19/.patch_storage/32904851_Jul_20_2021_09_21_24 :: 1927088358
[Jan 20, 2022 11:48:38 AM] [INFO]   Space for patch :: /u01/app/oracle/product/19/.patch_storage/33192793_Oct_15_2021_07_09_52 :: 1818503734
[Jan 20, 2022 11:48:38 AM] [INFO]   Space for patch :: /u01/app/oracle/product/19/.patch_storage/33192694_Sep_14_2021_16_48_27 :: 444972030
[Jan 20, 2022 11:48:38 AM] [INFO]   Space for patch :: /u01/app/oracle/product/19/.patch_storage/33197296_Oct_4_2021_00_44_36 :: 126355388
[Jan 20, 2022 11:48:38 AM] [INFO]   Space for patch :: /u01/app/oracle/product/19/.patch_storage/33515361_Jan_13_2022_06_14_07 :: 1750455909
[Jan 20, 2022 11:48:38 AM] [INFO]   Space for patch :: /u01/app/oracle/product/19/.patch_storage/33561310_Jan_5_2022_08_13_10 :: 452566990
[Jan 20, 2022 11:48:38 AM] [INFO]   Archive directory: /home/oracle/patch_storage needs 10209388359 bytes.
[Jan 20, 2022 11:48:38 AM] [SEVERE] No space to archive given patches in /home/oracle/patch_storage
[Jan 20, 2022 11:48:38 AM] [INFO]   Patch archive operation failed.
[Jan 20, 2022 11:48:38 AM] [SEVERE] Patch archive operation failed.
[Jan 20, 2022 11:48:38 AM] [INFO]   UtilSession failed to Archive the patches
[Jan 20, 2022 11:48:38 AM] [SEVERE] UtilSession failed to Archive the patches
[Jan 20, 2022 11:48:38 AM] [SEVERE] OUI-67073:UtilSession failed: Patch archive operation failed.
[Jan 20, 2022 11:48:38 AM] [INFO]   Finishing UtilSession at Thu Jan 20 11:48:38 CET 2022
[Jan 20, 2022 11:48:38 AM] [INFO]   Stack Description: java.lang.RuntimeException: Patch archive operation failed.
                                        at oracle.opatch.opatchutil.OUSession.archive(OUSession.java:3491)
                                        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
                                        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
                                        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
                                        at java.lang.reflect.Method.invoke(Method.java:498)
                                        at oracle.opatch.UtilSession.process(UtilSession.java:355)
                                        at oracle.opatch.OPatchSession.process(OPatchSession.java:2660)
                                        at oracle.opatch.OPatch.process(OPatch.java:870)
                                        at oracle.opatch.OPatch.main(OPatch.java:927)
                                    Caused by: java.lang.RuntimeException: Patch archive operation failed.
                                        ... 9 more

You think this is a bit hard to read? I agree – and I did a quick translation since a size of 190423787 is not easy to consume. I removed a bit of the output too. Now this works much better:

Archive directory: /home/oracle/patch_storage has required permission to archive the patches
 32218454_Jan_14_2021_16_24_38 :: 1.715 GB
 32545013_Apr_16_2021_07_40_05 :: 1.974 GB
 32904851_Jul_20_2021_09_21_24 :: 1.927 GB
 33192793_Oct_15_2021_07_09_52 :: 1.818 GB
 33192694_Sep_14_2021_16_48_27 :: 0.444 GB
 33197296_Oct_4_2021_00_44_36 ::  0.126 GB
 32515361_Jan_13_2022_06_14_07 :: 1.750 GB
 33561310_Jan_5_2022_08_13_10 ::  0.452 GB
Archive directory: /home/oracle/patch_storage needs 10.209 GB.
No space to archive given patches in /home/oracle/patch_storage

Hah! Got it. The calculation takes the current sized of each patch directory (here between 444 MB and 1.9 GB, adds it up, calculates something around 10 GB – and says: “Hey Mike, you don’t have enough space on your device for another 10 GB“.

So I put the files on the disk of my host system knowing that I will have at least 80GB of free space. And this was the result once opatch was done with its duties:

688M   Jan 20 14:10   33515361_Jan_13_2022_06_14_07.zip
948M   Jan 20 14:12   32545013_Apr_16_2021_07_40_05.zip
824M   Jan 20 14:13   32904851_Jul_20_2021_09_21_24.zip
119M   Jan 20 14:13   33197296_Oct_4_2021_00_44_36.zip
717M   Jan 20 14:15   33192793_Oct_15_2021_07_09_52.zip
118M   Jan 20 14:15   33192694_Sep_14_2021_16_48_27.zip
120M   Jan 20 14:15   33561310_Jan_5_2022_08_13_10.zip
725M   Jan 20 14:17   32218454_Jan_14_2021_16_24_38.zip

In sum 4.26 GB used. This is means less than 50% space consumed.

Lesson no.1:
The space usage assumption is dead wrong and uses the current sizes instead at least a assumption.

Lesson no.2:
The opatch util archive command does a simple zip of the subdirectory for each patch.

And this brings me to the magic final question.

Will opatch util archive free up space in .patch_storage?

Since you saw the command output above already, you may not be curious anymore.

It does cleanup. Every patch subdirectory to be archived will be removed afterwards. This is how my .patch_storage directory looked afterwards:

$ ls -lhrt
total 160K
-rw-r--r--.  1 oracle dba  24K Jan 19 21:39 newdirs.txt
drwxr-xr-x. 16 oracle dba 4.0K Jan 19 22:12 NApply
-rw-r--r--.  1 oracle dba  64K Jan 19 22:12 record_inventory.txt
-rw-r--r--.  1 oracle dba  64K Jan 19 22:12 interim_inventory.txt
-rw-r--r--.  1 oracle dba   92 Jan 19 22:12 LatestOPatchSession.properties

All the subdirectories are gone. It accumulates now only 160K.

I think I can deal with this.

What happens if you want to rollback a patch?

I’m happy that I tried this out as well before deleting all the patches on my host environment where I archived them to:

$ ./opatch rollback -id 33516412
Oracle Interim Patch Installer version 12.2.0.1.28
Copyright (c) 2022, Oracle Corporation.  All rights reserved.


Oracle Home       : /u01/app/oracle/product/21
Central Inventory : /u01/app/oraInventory
   from           : /u01/app/oracle/product/21/oraInst.loc
OPatch version    : 12.2.0.1.28
OUI version       : 12.2.0.9.0
Log file location : /u01/app/oracle/product/21/cfgtoollogs/opatch/opatch2022-01-20_15-38-47PM_1.log


Patches will be rolled back in the following order: 
   33516412
Prerequisite check "CheckRollbackable" failed.
Possible causes are:
 The patch can not be rolled back 
 No read or write permission to ORACLE_HOME/.patch _storage 
 The ORACLE_HOME/.patch_storage file may have been removed.
The details are:
***************************************************
Following patches are archived:
33516412
Please follow the instructions below to unarchive the patches before proceeding with current Opatch operation (as /u01/app/oracle/product/21 owner).
Step 1: /u01/app/oracle/product/21/OPatch/opatch util unarchive -patches 33516412
Step 2 : Resume/Rerun current Opatch operation: /u01/app/oracle/product/21/OPatch/opatch rollback -id 33516412 -invPtrLoc /u01/app/oracle/product/21/oraInst.loc 
***************************************************

UtilSession failed: Prerequisite check "CheckRollbackable" failed.
Log file location: /u01/app/oracle/product/21/cfgtoollogs/opatch/opatch2022-01-20_15-38-47PM_1.log

OPatch failed with error code 73

So I would need to “unarchive” the patch before.

Let me try this with: opatch util unarchive -patches 33516412

$ /u01/app/oracle/product/21/OPatch/opatch util unarchive -patches 33516412
Oracle Interim Patch Installer version 12.2.0.1.28
Copyright (c) 2022, Oracle Corporation.  All rights reserved.


Oracle Home       : /u01/app/oracle/product/21
Central Inventory : /u01/app/oraInventory
   from           : /u01/app/oracle/product/21/oraInst.loc
OPatch version    : 12.2.0.1.28
OUI version       : 12.2.0.9.0
Log file location : /u01/app/oracle/product/21/cfgtoollogs/opatch/opatch2022-01-20_15-40-58PM_1.log

Invoking utility "unarchive"
Unarchive given patches for given OH
Started : unarchiving the patch dirs to OH/.patch_storage
User specified list :[33516412]
Total Space Needed for Unarchive :1511356677
Unarchive successful :/u01/app/oracle/product/21/.patch_storage/33516412_Jan_13_2022_06_54_26
Unarchive  session is complete
To clean up archives from custom storage path,Run the following command :'/u01/app/oracle/product/21/OPatch/opatch util cleanuparchives'

OPatch succeeded.

And afterwards I could complete the rollback of my bundle patch for this exercise.

Learning no.3:
If you ever EVER plan to rollback a patch bundle, then keep the archives at the EXACT same location where you asked opatch to archive them to. Otherwise, you may not be able to rollback a bundle.

Other findings

Besides the fact that you need to know the command to get the “help” information, this is another pitfall I came across quickly:

Don’t put space characters between your patch numbers.

When you do this:

$ ./opatch util archive -patches 33197448, 33587128 -archive_dir /media/sf_TEMP
Oracle Interim Patch Installer version 12.2.0.1.28
Copyright (c) 2022, Oracle Corporation.  All rights reserved.

Syntax Error... Unrecognized Option for util.

Please use the option 'opatch util -help' to get correct syntax

OPatch failed with error code 14

you see opatch failing with one of its mystical errors.

The fix is to remove the space between the patch number and the comma, such as:

$ ./opatch util archive -patches 33197448,33587128 -archive_dir /media/sf_TEMP
Oracle Interim Patch Installer version 12.2.0.1.28
Copyright (c) 2022, 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.28
OUI version       : 12.2.0.1.4
Log file location : /u01/app/oracle/product/12.2.0.1/cfgtoollogs/opatch/opatch2022-01-20_15-21-41PM_1.log

Invoking utility "archive"

Archiving Patch - 33587128 ....
Sucessfully archived patch - 33587128 in /media/sf_TEMP/33587128_Dec_27_2021_16_38_16.zip

Archiving Patch - 33197448 ....
Sucessfully archived patch - 33197448 in /media/sf_TEMP/33197448_Oct_4_2021_05_28_49.zip
Succesfully verified the created archive. Deleting the original patch from  - /u01/app/oracle/product/12.2.0.1/.patch_storage/33587128_Dec_27_2021_16_38_16
Succesfully verified the created archive. Deleting the original patch from  - /u01/app/oracle/product/12.2.0.1/.patch_storage/33197448_Oct_4_2021_05_28_49
Patch archive operation completed successfully.

OPatch succeeded.

Then it works.

Learning no.4:
Don’t use space characters in the comma-separated patch number list for -patches

Learning no.5:
The new opatch util archive command frees up a lot of space. Unfortunately there is no automatism and still non n-1 solution. But most of you won’t be affected since you patch with new homes, and just flip from one home to another.

In my test I freed up all together about 15GB in my 3 Oracle Homes, 12.2.0.1, 19c and 21c. What I would still want is a n-1 option keeping automatically only the previous patch and wipe out older ones since I rarely will jump back more than one patch bundle, if ever. And in addition I would have expected a “all” switch which clean out every patch without the need to copy and paste individual patch numbers.

Cleaning Up the archives

And finally – thanks to Stephen Anderson who pointed me to this – the question remains:
Do you need to remove the archives now manually from disk?

Let’s see since there is another – more or less undocumented – command for this. You may have seen this already in the output above:

opatch util cleanuparchives

Let me show you how this works:

$ $ORACLE_HOME/OPatch/opatch util cleanuparchives
Oracle Interim Patch Installer version 12.2.0.1.28
Copyright (c) 2022, 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.28
OUI version       : 12.2.0.7.0
Log file location : /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2022-01-21_12-27-56PM_1.log

Invoking utility "cleanuparchives"
Started : Util cleauparchives session
Patch id :33515361
Patch id :32545013
Patch id :32904851
Patch id :33197296
Patch id :33192793
Patch id :33192694
Patch id :33561310
Patch id :32218454
Nothing to cleanup
Cleanuparchives from secondary storage is successful.

OPatch succeeded.

Now knowing opatch for quite a while I was wondering about this “Nothing to cleanup” message followed by a “… is successful” output. What has happened?

At first, I check my archive storage – and all the files are still there.

And then as next step, I tried to restore one of the archives which are physically still on disk as I did this before:

$ /u01/app/oracle/product/21/OPatch/opatch util unarchive -patches 33515361
Oracle Interim Patch Installer version 12.2.0.1.28
Copyright (c) 2022, 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.28
OUI version       : 12.2.0.7.0
Log file location : /u01/app/oracle/product/19/cfgtoollogs/opatch/opatch2022-01-21_12-31-31PM_1.log

Invoking utility "unarchive"
Unarchive given patches for given OH
Started : unarchiving the patch dirs to OH/.patch_storage
User specified list :[33515361]
Total Space Needed for Unarchive :1750455909
Unarchive successful :/u01/app/oracle/product/19/.patch_storage/33515361_Jan_13_2022_06_14_07
Unarchive  session is complete
To clean up archives from custom storage path,Run the following command :'/u01/app/oracle/product/19/OPatch/opatch util cleanuparchives'

OPatch succeeded.

So basically I can’t tell you what the “cleanuparchives” command does, or if it is supposed to do anything. The opatch logfile didn’t help me any further.  And the command’s help tells me:

$ $ORACLE_HOME/OPatch/opatch util cleanuparchives -help
Oracle Interim Patch Installer version 12.2.0.1.28
Copyright (c) 2022, Oracle Corporation.  All rights reserved.


DESCRIPTION
    This operation helps to cleanup the archived files from custom storage
    location.
    NOTE: This will not cleanup any other directories/files in the system.
   		  This will only cleanup the archives generated as part of 
   		  util archive operation.


SYNTAX
opatch util cleanuparchives

I can just confirm that it is not doing what it is supposed to do.

Further Links and Information

–Mike

 

Share this: