Cleanup Oracle After Patching

cleanup Oracle-Home(s)
after applying the quarterly Release Updates

Do you suffer from the fact that release updates take longer each time?
Are you afraid that your hard disk will fill up because the Oracle-Home is getting bigger and bigger?
Here is the how-to for cleaning up your environment.

A) cleanup – option 1 for Out-Of-Place patching

According to Oracle’s recommendations, you did “out of place patching” and have now several Oracle-Home directories.
All your databases are using the new ORACLE_HOME (OH) and the old OHs are now obsolete.
Cleaning up is not only a matter of disk space. The old Software releases contain security issues – of course. This is the very reason for patching.

Set the environment for the OH you want to delete

export ORACLE_HOME=/u01/app/oracle/product/19.25.0/dbhome_1
PATH=$ORACLE_HOME/bin:$ORACLE_HOME/OPatch:$ORACLE_HOME/perl/bin:$ORACLE_HOME/ctx/bin
PATH=$PATH:/home/oracle/.local/bin:/home/oracle/bin:/usr/local/bin:/usr/bin:/usr/ccs/bin:/usr/local/sbin:/usr/sbin:/sbin
export PATH
export CV_ASSUME_DISTID=OEL8.1

cd $ORACLE_HOME/deinstall
./deinstall
   -> enter required answers …
       Enter     (confirm [LISTENER] )
       Enter     (confirm databases [] )
        Y        (to confirm to delete the listed OH)

you can delete the empty directory, now

cd /u01/app/oracle/product/
du -sh *
rmdir 19.25.0

B) cleanup – option 2 for Out-Of-Place patching

In some cases, the deinstall does not work and gives you some error messages.
Now we have the option to detach AND remove the old ORACLE_HOME.
In this example our OH-path is: /u01/app/oracle/product/19.15.0.0.220419.EE

first you need to find the “Home-Name” for the OH to deinstall – you might have to look into several subfolders for it

cd /u01/app/oraInventory/logs
ls -l
cd InstallActions<timestamp>
grep -i ORACLE_HOME_NAME *.log
-->> responds for example with:   OraDB19Home1

set the environment for the ORACLE_HOME to remove and DETACH it

export ORACLE_HOME=/u01/app/oracle/product/19.15.0.0.220419.EE
PATH=$ORACLE_HOME/bin:$ORACLE_HOME/OPatch:$ORACLE_HOME/perl/bin:$ORACLE_HOME/ctx/bin
PATH=$PATH:/home/oracle/.local/bin:/home/oracle/bin:/usr/local/bin:/usr/bin:/usr/ccs/bin:/usr/local/sbin:/usr/sbin:/sbin
export PATH
export CV_ASSUME_DISTID=OEL8.1

cd $ORACLE_HOME/oui/bin
./runInstaller -silent -detachHome ORACLE_HOME="/u01/app/oracle/product/19.15.0.0.220419.EE" ORACLE_HOME_NAME="OraDB19Home1"

cd /u01/app/oracle/product
rm -rf 19.15.0.0.220419.EE

and don’t forget to remove the obsolete OH from the oratab file

vi /etc/oratab

C) cleanup – option for IN-Place patching

For reasons, you could not do “out of place” patching. When you have an OH which was already patched several times, the OH increased in size over time. The old patches got stored in a subdirectory for rollback reasons.

Simply check the size of the subdirectory

du -sh $ORACLE_HOME/.patch_storage/
-->> 6.6G  .patch_storage/

I checked this for an ORACLE_HOME with up to 7 RUs installed:

.patch_storage with   2 RUs     3 RUs     4 RUs     5 RUs     6 RUs     7 RUs
          Size GB      5.6       6.6        9.1       12        14        18

you can imagine that each run of opatch needs more and more time for a larger repository in directory ‘.patch_storage’.
For the first patch it goes ‘on the fly’. The second needs a coffee break, the third needs a lunch break …

with this command you can list your obsolete patches

opatch util listorderedinactivepatches

now delete them (this will take a while) and it leaves intentionally the last RU in the repository

opatch util deleteinactivepatches

the disk usage is now reduced, and the next patch will run definitively faster

du -sh $ORACLE_HOME/.patch_storage/
-->> 6.0G .patch_storage/

I am an impatient DBA and I don’t like drinking lots of coffee while waiting for opatch to finish. This is why I love to keep my Oracle-Home directories small and smart.

D) add on – patch the OPatch

regardless of you do in-place or out-of-place patching, you need to update your opatch with the most recent release. The very most DBAs follow the advice in p6880880_opatch_README_12.2.0.1.xy.txt
“Please take a backup of ORACLE_HOME/OPatch into a dedicated backup location” and rename the folder OPatch to OPatch_old.
With the next RU, they move the current to OPatch_even_older or some other funny name.
Just to remember: the purpose of patching is to REPLACE older Software, which contains security issues, by newer releases, containing fixes.
Did you know that opatch contains its own Java? So why should we leave an outaged Java on the system as a gate for hackers?

Remove it immediately after you have verified, the new release is working.

--->>> rm -rf ORACLE_HOME/OPatch_old

I hope, this helps you to keep your environment clean and tidy.