Enterprise Managerから、実稼働データベースの1つでディスク容量が不足しているというアラートを受け取りました。 90GBドライブの30GBを消費していた$GRID_HOME/.patch_storageまで追跡しました。 Yikes！
私が最初にしたことは、2013年にここで文書化したように、opatchクリーンアップルーチンを実行することでした：http://www.peasland.net/2013/03/21/patch_storage/
残念ながら、何もクリーンアップされませんでした。
今回は、手動のクリーンアップに頼らざるを得ませんでした。これが私がしたステップです。
.patch_storage内のファイルは、パッチ分子番号とタイムスタンプで始まります。例： 19582630 _Nov_14_2014_21_43_23
そのパッチがまだ在庫にあるかどうかをopatchに尋ねる必要があります。
$ ORACLE_HOME / OPatch / opatch lsinventory | grep 19582630
20075154、20641027、22271856、20548410、19016964、 19582630
lsinventoryは、パッチがインベントリにあることを示します。次のパッチに進みます。
lsinventoryコマンドが何も返さない場合、パッチはインベントリにありません。 MOS Note 550522.1には、そのディレクトリが不要になったため、削除できると記載されています。私の常に慎重なDBAパーソナリティは、単純な「rm-rfdir_name」コマンドから確実に回復できるようにしたいと考えています。そのため、最初にディレクトリをtarおよびgzipで圧縮してから、ディレクトリを削除します。
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
パッチごとにこれを行うという骨の折れる作業。 sed、awk、シェルスクリプトで私より優れている人なら、このプロセスを自動化できると確信しています。
これらの手順に従うことで、私の.patch_storageディレクトリは30GBから11GBに減少しました。
次の四半期にCPUを再度適用すると、オパッチの叫び声がファウルになり、これらを元に戻すように要求された場合、tarballをすばやく解凍して抽出でき、オパッチは満足できるはずです。
この操作は$GRID_HOMEで実行しましたが、$RDBMS_HOMEでも機能します。また、これはOracle RACであるため、クラスター内のすべてのノードでこれを実行したい場合があります。