Jeg modtog en advarsel fra Enterprise Manager om, at en af mine produktionsdatabaser var ved at løbe tør for diskplads. Jeg sporede det ned til $GRID_HOME/.patch_storage, som forbrugte 30 GB af mit 90 GB-drev. Yikes!
Den første ting, jeg gjorde, var at køre opatch-oprydningsrutinen, som jeg dokumenterede her tilbage i 2013: http://www.peasland.net/2013/03/21/patch_storage/
Desværre ryddede det ikke op i noget.
Denne gang måtte jeg ty til en manuel oprydning. Her er de trin, jeg gjorde.
Filerne i .patch_storage starter med patch-molekylets nummer og et tidsstempel. For eksempel: 19582630 _Nov_14_2014_21_43_23
Jeg er nødt til at spørge opatch, om den patch stadig er på lageret.
$ORACLE_HOME/OPatch/opatch lsinventory|grep 19582630
20075154, 20641027, 22271856, 20548410, 19016964, 19582630
lsinventory viser, at patchen er i inventaret. Jeg går videre til næste patch.
Når min lsinventory-kommando ikke returnerer noget, er patchen ikke i inventaret. MOS Note 550522.1 siger, at du kan fjerne den mappe, da den ikke længere er nødvendig. Den altid forsigtige DBA-personlighed i mig ønsker at sikre, at jeg kan komme mig efter en simpel "rm -rf dir_name"-kommando. Så jeg tar og gziper mappen først, og fjerner derefter mappen.
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
Dens omhyggelige arbejde gør dette for hvert eneste plaster. Jeg er sikker på, at nogen, der er bedre end mig med sed og awk og shell scripting, kunne automatisere denne proces.
Ved at følge disse trin faldt mit .patch_storage-bibliotek fra 30 GB til 11 GB.
Næste kvartal, når jeg anvender min CPU igen, skulle opatch græde grimt og kræve, at disse sættes tilbage, kan jeg hurtigt pakke tarballen ud og udpakke, og opatch skulle være glad.
Jeg udførte denne handling på $GRID_HOME, men den vil også fungere på $RDBMS_HOME. Da dette er Oracle RAC, vil jeg måske også gøre dette på alle noder i klyngen.