Ho ricevuto un avviso da Enterprise Manager che uno dei miei database di produzione stava esaurendo lo spazio su disco. L'ho rintracciato fino a $GRID_HOME/.patch_storage che stava consumando 30 GB del mio disco da 90 GB. Accidenti!
La prima cosa che ho fatto è stata eseguire la routine di pulizia dell'opatch come ho documentato qui nel 2013: http://www.peasland.net/2013/03/21/patch_storage/
Sfortunatamente, non ha ripulito nulla.
Questa volta ho dovuto ricorrere a una pulizia manuale. Ecco i passaggi che ho fatto.
I file in .patch_storage iniziano con il numero della molecola della patch e un timestamp. Ad esempio: 19582630 _14_novembre_2014_21_43_23
Devo chiedere a opatch se quella patch è ancora nell'inventario.
$ORACLE_HOME/OPatch/opatch lsinventory|grep 19582630
20075154, 20641027, 22271856, 20548410, 19016964, 19582630
lsinventory mostra che la patch è nell'inventario. Passo alla patch successiva.
Quando il mio comando lsinventory non restituisce nulla, la patch non è nell'inventario. MOS Note 550522.1 dice che puoi rimuovere quella directory poiché non è più necessaria. La personalità DBA sempre cauta in me vuole assicurarsi di poter recuperare da un semplice comando "rm -rf dir_name". Quindi prima tar e gzip la directory, quindi rimuovo la directory.
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
Il suo lavoro scrupoloso lo fa per ogni patch. Sono sicuro che qualcuno che è meglio di me con sed, awk e script di shell potrebbe automatizzare questo processo.
Seguendo questi passaggi, la mia directory .patch_storage è scesa da 30 GB a 11 GB.
Il prossimo trimestre, quando applico nuovamente la mia CPU, se opatch grida al fallo e chiedo che vengano riposizionati, posso decomprimere rapidamente ed estrarre il tarball e opatch dovrebbe essere felice.
Ho eseguito questa operazione su $GRID_HOME ma funzionerà anche su $RDBMS_HOME. Inoltre, poiché si tratta di Oracle RAC, potrei volerlo fare su tutti i nodi del cluster.
