Виждал съм много Oracle инсталации, които са „изсипани с лопатата“. Обичайната, ужасно стандартна картинка е следната: Дошъл, примерно, производител на софтуер и инсталирал своята система за billing/производство/HR или кой знае какво. И тази системка работи с Oracle Database. Обаче разработчиците не си дават много зор при инсталацията на Oracle софтуера и го дават с next-next-next… Фирмата, която си е купила софтуера, има един или двама сисадмини (най-много – може и да ги поддържа някой външен консултант). Този сисадмин разбира доста от Windows и или от Linux, от мрежи, от принтери и т.н. И няма как да бъде oracle гуру. И така се получава една… хм… не много оптимално работеща система.
Но това е само един от проблемите. Друг проблем е, че тая система работи с т.нар. base release – без никакви patchsets, да не говорим за отделни patch-ове. Което си е жива бомба за security, availability, performance, scalability и каквито още се сетите благини в една голяма комерсиална БД. Хайде, Oracle 11g излезе по-читав като Base release, но все пак…
Така описаната от мен ситуация е много тъжна, но голяма част от средният бизнес, че и част от „едрия“ за нашите мащаби, работи върху такива системи. И продължава да си работи, което е практическото доказателство, че може и да не са толкова страшни нещата.
Всичко кaзано до тук няма нищо общо с проблема, за който исках да пиша. Ама на тая тема паля от четвърт оборот. Защото съм ги сърбал такива попари…
Това, за което исках да пиша, е обратния случай – всички ние, които като добри хора си инсталираме patchsets, че даже и отделни interim patches и Critical Patch Update (CPU). Ние сърбаме друга попара:
OPatch, който е един от най-добрите patch tools, които съм виждал, е много внимателен и при инсталирането на кръпки винаги си прави backup на файловете, които мисли да подменя. Така ако стане нещо по време на наливането, винаги успява да върне предишното, (вероятно) стабилно състояние. Освен това запазва тези резервни копия и след като приключи, за да може ако след един ден (или месец) открием, че новия patch чупи нещо, да имаме тази възможност за стъпка назад. Честно казано не съм го тествал как се държи в по-заплетени случаи на слагане/махане на много зависими една от друга кръпки, но се надявам и да не опитвам.
Лошото е, че тези patch backups се натрупват в $ORACLE_HOME/.patch_storage и без проблем могат да станат повече от самата инсталация. И така може да се окаже, че без да знаем мястото на диска става все по-малко с всеки инсталиран interim patch и Critical Patch Update (CPU).
В Metalink note 550522.1 e описано по-подробно как в тази директория може да се натрупат няколко гигабайта „излишни“ файлове. И, по-важно, описано е как в последните версии на OPatch може да си върнем излишно заетото място без да извършваме безразборно клане триене. Тайната команда, която трябва да работи при всички по-съвременни версии на OPatch, е:
opatch util cleanup
С една такава команда аз получих следното неустоимо предложение:
Size of directory "/u01/product/11.1.0/db_1/.patch_storage" before cleanup is 2644331045 bytes.
Size of directory "/u01/product/11.1.0/db_1/.patch_storage" after cleanup is 191700734 bytes.
Това са си над 700 мегабайта, освободени без изобщо да се компрометира възможността на OPatch да деинсталира. Офертата наистина е уникална, защото още толкова успях да изстържа и от ASM home-а 🙂