Получих известие от Enterprise Manager, че една от производствените ми бази данни намалява на дисковото пространство. Проследих го до $GRID_HOME/.patch_storage, който консумираше 30GB от моето 90GB устройство. Браво!
Първото нещо, което направих, беше да стартирам рутината за почистване на opatch, както документирах тук през 2013 г.: http://www.peasland.net/2013/03/21/patch_storage/
За съжаление не почисти нищо.
Този път трябваше да прибягна до ръчно почистване. Ето стъпките, които направих.
Файловете в .patch_storage започват с номера на молекулата на пластира и времевата марка. Например: 19582630 _14_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 -rf dir_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 и shell скриптове, може да автоматизира този процес.
Следвайки тези стъпки, моята .patch_storage директория спадна от 30GB на 11GB.
Следващото тримесечие, когато приложа отново моя процесор, ако opatch cry фалира и поискам те да бъдат върнати, мога бързо да разархивам и извадя архива и opatch трябва да съм доволен.
Направих тази операция на $GRID_HOME, но тя ще работи и на $RDBMS_HOME. Освен това, тъй като това е Oracle RAC, може да искам да направя това на всички възли в клъстера.
