‘.patch_storage’ consumes quite some space?

I was preparing database patching some days ago. It’s an Oracle DataGuard configuration on 19c. As always, I took a quick look at the free space of each partitions. An interesting thing I noticed was my “/opt” partition seemed using more storage (a few more gigabyte) than I would expect on the primary database. Then I did a closer look and the $ORACLE_HOME (under /opt) used about 16G. Usually Oracle software package with 19c uses about 8G. Why I saw 16G here. The standby database seemed to be OK. It used about 8G for $ORACLE_HOME.

At first, I used “du -sh *” to check sub-directory space usage under $ORACLE_HOME. Nothing looks suspicious. But there must be something missing here. Actually it was the du command I was using — with the option “-s” for summarize and “*” it only reported non-hidden sub-directories.

With another option of du “–threshold“, I saw the hidden directory “.patch_storage” used 6G space.

du -ah --threshold=1G
du -h --threshold=1G

[oracle@joetest_primary: 190000]$ du -ah --threshold=1G
1.9G    ./.patch_storage/32545013_Apr_16_2021_07_40_05/files
1.9G    ./.patch_storage/32545013_Apr_16_2021_07_40_05
1.1G    ./.patch_storage/32904851_Jul_20_2021_09_21_24/files/lib
1.8G    ./.patch_storage/32904851_Jul_20_2021_09_21_24/files
1.8G    ./.patch_storage/32904851_Jul_20_2021_09_21_24
1.2G    ./.patch_storage/33515361_Jan_13_2022_06_14_07/files/lib
1.8G    ./.patch_storage/33515361_Jan_13_2022_06_14_07/files
1.8G    ./.patch_storage/33515361_Jan_13_2022_06_14_07
6.6G    ./.patch_storage
2.2G    ./lib
16G     .

Basically when you apply an interim patch to an Oracle home, OPatch stores the patch information in $ORACLE_HOME/.patch_storage directory. Inside this directory, there are separate directories created for each patch applied to the Oracle home. Interim patches are bug fixes that are made available to customers in response to specific bugs. Critical Patch Update (CPU) and Patch Set Updates (PSUs) is also a kind of patche. The latest CPU/PSU will rollback the previously applied CPU/PSU as CPU/PSU is cumulative. So this rollback information is from the .patch_storage directory.

You might be able to reclaim some storage back with the command

$ opatch util cleanup -help

Additionally, further cleanup of the $ORACLE_HOME/.patch_storage is possible if there are directories from patches applied to previous versions. This can be done manually as follows:

run command:
$ opatch lsinventory
Remove all the sub-directories from $ORACLE_HOME/.patch_storage that are not present in the list of installed patches. Directory names would be prefaced with the patchid for example:
13343438_
example to find sub-directories : $ opatch lsinventory | grep -E “(^Patch.*applied)|(^Sub-patch)”

Note:

List of patches include the sub patches of install Bundle patches, PSU, GI PSU. Hence you should NOT remove the sub patch folders
There was a bug with the opatch cleanup option in the version 12.2.0.1.19/11.2.0.3.23 which could remove system files. See the reference item 4 for more details.

It’s interesting to see my primary database has more storage used by .patch_storage. I wonder if it’s because of no internal update on standby?

After I applied 2023 Jan. PatchSet. Now I’ve got more storage used by .patch_storage and sqlpatch two sub-directories. sqlpatch is used by datapatch. see another post I wrote here.

[oracle@joetest_primary 190000]$ du -h --threshold=1G
1.2G    ./sqlpatch
.
.
.
8.9G    ./.patch_storage
2.3G    ./lib
19G     .

[oracle@joetest_standby 190000]$ du -ah --threshold=1G
1.1G    ./sqlpatch
.
.
.
2.8G    ./.patch_storage
2.3G    ./lib
12G     .

References: