This occurred to me not too long ago, when I prepared an Oracle Software for a client. It is a small appliance with not a lot of disk space and we upgraded it from 11.2 to 19c. When we started, 19.6 was the latest version available, but then we upgraded to 19.9 and during the installation I figured something out.
A Patch on Top of a Patch
When I took one appliance and installed 19.9, this appliance already had 19.6 installed. Then I checked the disk space and found out and the Oracle Home takes more space than a different appliance where I installed 19.9 from scratch. The difference between them was the intermediate installation of 19.6. One installation was of the base 19.3 version and then patch to 19.9, while the other one was the base 19.3, patch to 19.6, and then patch to 19.9. The difference in disk space was significant (between 1-2GB).
What I did at the end was to rollback the 19.6 patch before installing the 19.9 patch to prevent the extra 1-2GB.
Demonstration
In my test servers I already had 19.6 installed, so to demonstrate this I simply patched it once straight to 19.9 and once to 19.8 and then to 19.9.
This is what I found out:
19.6
[oracle@ora19 db_home]$ du -sh .
9.3G .
19.6 -> 19.9
[oracle@ora19 db_home]$ du -sh .
11G .
19.6 -> 19.8 -> 19.9
[oracle@ora19 db_home]$ du -sh .
13G .
The Difference
I compared the directories content (using “du -sh | sort -h”) and there was a slight difference, but nothing that could explain the 2GB. Then I checked hidden folders and I found it: “.patch_storage”. In the original 19.6, this directory is 1.9GB, in the 19.9 (from 19.6) it is 3.4GB and in the 19.9 (from 19.8) it’s 4.8GB.
Now it all makes sense. The “.patch_storage” saves backups of the changed files when installing a patch so we will be able to rollback the patch. Here is the content of this directory in the 19.9 that I installed on top of 19.8:
[oracle@ora19 db_home]$ cd .patch_storage/
[oracle@ora19 .patch_storage]$ du -sh *
248K 29517242_Apr_17_2019_23_27_10
76K 29585399_Apr_9_2019_19_12_47
20K 29997937_Aug_12_2019_01_19_59
751M 30125133_Oct_9_2019_00_10_29
1.2G 30557433_Jan_6_2020_19_07_34
1.4G 31281355_Jul_6_2020_11_18_02
1.6G 31771877_Oct_7_2020_21_34_19
52K interim_inventory.txt
4.0K LatestOPatchSession.properties
40K NApply
24K record_inventory.txt
As you can see, the directory “31281355_Jul_6_2020_11_18_02” is the RU of July 2020 which is 19.8. This directory does not exist in the Oracle Home where I patch 19.6 directly to 19.9 and this explains the 1.4GB difference between the homes.
Cleanup
So, can we clean this directory up? MOS note 550522.1 talks about this (titled: how To Avoid Disk Full Issues Because OPatch Backups), and it also points to note 403218.1 (titled :Can You Delete $ORACLE_HOME/.patch_storage Directory).
The second note says that you cannot remove this directory manually. The first one talks about the content of the directory. It says that you can use “opatch util cleanup” to remove temporary files from the .patch storage directory (bullet #3 in the note). This is only for temporary files, you can still rollback any patch and when I tried it it didn’t release any space.
In the same bullet point, it also says that you can manually remove any sub-directory that is not listed in “opatch lspatches” to reclaim space manually. As far as I understand it, if I have 19.9 (directory is 31771877_Oct_7_2020_21_34_19) I can manually remove the directories for 19.6 and 19.8 backups.
Before you do something like that I suggest to contact Oracle Support and make sure this is okay. Also, be aware that if you do that, you can rollback the current patch but not previous patches (so in my demo environment I would be able to rollback 19.9 and go back to 19.8, but then won’t be able to rollback 19.8 and get back to 19.6).