Recebi um alerta do Enterprise Manager de que um dos meus bancos de dados de produção estava com pouco espaço em disco. Eu o rastreei até $GRID_HOME/.patch_storage, que estava consumindo 30 GB da minha unidade de 90 GB. Caramba!

A primeira coisa que fiz foi executar a rotina de limpeza do opatch conforme documentei aqui em 2013: http://www.peasland.net/2013/03/21/patch_storage/

Infelizmente, não limpou nada.

Desta vez, tive que recorrer a uma limpeza manual. Aqui estão os passos que fiz.

Os arquivos em .patch_storage começam com o número da molécula do patch e um carimbo de data/hora. Por exemplo: 19582630 _14_nov_2014_21_43_23

Preciso perguntar ao opatch se esse patch ainda está no inventário.

$ORACLE_HOME/OPatch/opatch lsinventory|grep 19582630
20075154, 20641027, 22271856, 20548410, 19016964, 19582630

lsinventory mostra que o patch está no inventário. Eu passo para o próximo patch.

Quando meu comando lsinventory não retorna nada, o patch não está no inventário. A nota MOS 550522.1 diz que você pode remover esse diretório, pois não é mais necessário. A personalidade sempre cautelosa do DBA em mim quer garantir que eu possa me recuperar de um simples comando “rm -rf dir_name”. Então eu tar e gzip o diretório primeiro, depois removo o diretório.

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

Seu trabalho meticuloso fazendo isso para cada patch. Tenho certeza de que alguém que é melhor do que eu com sed e awk e shell scripts poderia automatizar esse processo.

Seguindo essas etapas, meu diretório .patch_storage caiu de 30 GB para 11 GB.

No próximo trimestre, quando eu aplicar minha CPU novamente, se o opatch chorar e exigir que eles sejam colocados de volta, posso descompactar rapidamente e extrair o tarball e o opatch deve ficar feliz.

Eu fiz esta operação em $GRID_HOME mas funcionará em $RDBMS_HOME também. Além disso, como este é o Oracle RAC, talvez eu queira fazer isso em todos os nós do cluster.