Od Enterprise Manager jsem obdržel upozornění, že v jedné z mých produkčních databází dochází místo na disku. Vystopoval jsem to na $GRID_HOME/.patch_storage, který spotřeboval 30 GB z mého 90GB disku. Jejda!
První věc, kterou jsem udělal, bylo spustit rutinu čištění opatch, jak jsem zdokumentoval zde v roce 2013: http://www.peasland.net/2013/03/21/patch_storage/
Bohužel to nic nevyčistilo.
Tentokrát jsem se musel uchýlit k ručnímu čištění. Zde jsou kroky, které jsem provedl.
Soubory v .patch_storage začínají číslem molekuly opravy a časovým razítkem. Například: 19582630 _Nov_14_2014_21_43_23
Musím se zeptat opatche, jestli je ten patch stále v inventáři.
$ORACLE_HOME/OPatch/opatch lsinventory|grep 19582630
20075154, 20641027, 22271856, 20548410, 19016964, 19582630
lsinventory ukazuje, že patch je v inventáři. Přecházím na další patch.
Když můj příkaz lsinventory nic nevrací, oprava není v inventáři. MOS Note 550522.1 říká, že tento adresář můžete odstranit, protože již není potřeba. Stále opatrná osobnost DBA ve mně se chce ujistit, že se dokážu zotavit z jednoduchého příkazu „rm -rf dir_name“. Takže nejprve taruji a gzipuji adresář a poté adresář odstraním.
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
Jeho pečlivá práce to dělá pro každý patch. Jsem si jistý, že někdo, kdo je lepší než já se skriptováním sed a awk a shell, by mohl tento proces automatizovat.
Podle těchto kroků klesl můj adresář .patch_storage z 30 GB na 11 GB.
V příštím čtvrtletí, až znovu použiji svůj CPU, pokud by opatch křičel faul a požadoval jejich umístění zpět, mohu rychle rozbalit a extrahovat tarball a opatch by měl být šťastný.
Tuto operaci jsem provedl na $GRID_HOME, ale bude fungovat i na $RDBMS_HOME. Protože se jedná o Oracle RAC, možná to budu chtít udělat na všech uzlech v clusteru.