Otrzymałem alert od Enterprise Manager, że w jednej z moich produkcyjnych baz danych zaczyna brakować miejsca na dysku. Wyśledziłem go do $GRID_HOME/.patch_storage, który zajmował 30 GB mojego dysku o pojemności 90 GB. Ups!
Pierwszą rzeczą, którą zrobiłem, było uruchomienie procedury czyszczenia Opatch, jak udokumentowałem tutaj w 2013 roku: http://www.peasland.net/2013/03/21/patch_storage/
Niestety niczego nie posprzątało.
Tym razem musiałem uciec się do ręcznego czyszczenia. Oto kroki, które wykonałem.
Pliki w .patch_storage zaczynają się od numeru cząsteczki poprawki i znacznika czasu. Na przykład: 19582630 _14 listopada 2014_21_43_23
Muszę zapytać Opatcha, czy ta łatka nadal znajduje się w ekwipunku.
$ORACLE_HOME/OPatch/opatch lsinventory|grep 19582630
20075154, 20641027, 22271856, 20548410, 19016964, 19582630
lsinventory pokazuje, że łatka jest w ekwipunku. Przechodzę do następnego patcha.
Kiedy moje polecenie lsinventory nic nie zwraca, łatki nie ma w ekwipunku. MOS Note 550522.1 mówi, że możesz usunąć ten katalog, ponieważ nie jest już potrzebny. Zawsze ostrożna osobowość DBA we mnie chce mieć pewność, że mogę odzyskać sprawność po prostym poleceniu „rm -rf dir_name”. Więc najpierw tar i gzip katalog, a następnie usuń katalog.
smoła cvf 25869825_lip_3_2017_23_11_58.tar 25869825_lip_3_2017_23_11_58
gzip 25869825_Jul_3_2017_23_11_58.tar
rm -rf 25869825_Jul_3_2017_23_11_58
Jego żmudna praca robi to dla każdego patcha. Jestem pewien, że ktoś, kto jest lepszy ode mnie w sed, awk i skryptach powłoki, mógłby zautomatyzować ten proces.
Po wykonaniu tych kroków mój katalog .patch_storage spadł z 30 GB do 11 GB.
W następnym kwartale, kiedy ponownie użyję procesora, jeśli opatch cry faul i zażądam ich odłożenia, mogę szybko rozpakować i rozpakować archiwum, a opatch powinien być zadowolony.
Wykonałem tę operację na $GRID_HOME, ale będzie działać również na $RDBMS_HOME. Ponadto, ponieważ jest to Oracle RAC, mogę chcieć to zrobić na wszystkich węzłach w klastrze.
