Jag fick en varning från Enterprise Manager om att en av mina produktionsdatabaser började få lite diskutrymme. Jag spårade det till $GRID_HOME/.patch_storage som förbrukade 30 GB av min 90 GB-enhet. Hoppsan!
Det första jag gjorde var att köra opatch-rensningsrutinen som jag dokumenterade här 2013: http://www.peasland.net/2013/03/21/patch_storage/
Tyvärr rensade det inte upp någonting.
Den här gången var jag tvungen att ta till en manuell rengöring. Här är stegen jag gjorde.
Filerna i .patch_storage börjar med patchmolekylens nummer och en tidsstämpel. Till exempel: 19582630 _nov_14_2014_21_43_23
Jag måste fråga opatch om den patchen fortfarande finns i inventeringen.
$ORACLE_HOME/OPatch/opatch lsinventory|grep 19582630
20075154, 20641027, 22271856, 20548410, 19016964, 19582630
lsinventory visar att patchen finns i inventariet. Jag går vidare till nästa patch.
När mitt lsinventory-kommando inte returnerar något, finns inte patchen i inventeringen. MOS Note 550522.1 säger att du kan ta bort den katalogen eftersom den inte längre behövs. Den alltid försiktiga DBA-personligheten i mig vill säkerställa att jag kan återhämta mig från ett enkelt "rm -rf dir_name"-kommando. Så jag tar och gzippar katalogen först och tar sedan bort katalogen.
tar cvf 25869825_Jul_3_2017_23_11_58.tar 25869825_Jul_3_2017_23_11_58
gzip 25869825_Jul_3_2017_23_11_58.tar
rm -rf 25869825_Jul_3_2017_23_11_58
Dess mödosamma arbete gör detta för varje plåster. Jag är säker på att någon som är bättre än jag med sed och awk och shell scripting skulle kunna automatisera denna process.
Genom att följa dessa steg sjönk min .patch_storage-katalog från 30 GB till 11 GB.
Nästa kvartal när jag applicerar min CPU igen, skulle opatch gråta och kräva att dessa placeras tillbaka, kan jag snabbt packa upp och dra ut tarballen och opatch borde vara nöjd.
Jag gjorde den här operationen på $GRID_HOME men den kommer att fungera på $RDBMS_HOME också. Dessutom, eftersom detta är Oracle RAC, kanske jag vill göra detta på alla noder i klustret.