май 252009
 

Виждал съм много 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-а 🙂

 Posted by at 20:44

  10 Responses to “.patch_storage”

  1. Относно първата част на темата – се замислям колко би било тези производители на софтуер да използват за своите прости програмки и по-прости бази от данни които се подържат много по-лесно. Защото съгласи се, че на една Оракъл система и трябва Оракъл администратор(Казано по шопски: На козата и трябва пръч не ще друго 🙂 ), докато един Microsoft SQL Server може да се подържа и от системинят администратор – просто защото с ъпдейтите на Windows-а пристигат и ъпдейти и за SQL Server-a

  2. Абе СУБД да ти се ъпдейтва само си е нож с две остриета. Не е като да не се е случвало някой MS Update да прецака я ексчейнжа, я нещо друго…

  3. Тези backup patch-ове ни правят и на нас проблеми с disk space-a. Наистина е необходимо да се трият от време на време.

  4. Сега, след като си изстъргал така прилежно всичките тия работи, да не стане така че да се наложи да правиш roll-back на някой patch и util-то да ти каже „е да ама мене ми трябват едни файлове дето трябваше да са там, ама ги нема“. И да питам „… без да знаем мястото на диска става все по-малко с всеки инсталиран interim patch“ WTF?!? Ама ти (не визирам тебе конкретно ) ако не знаеш какво става в собствения ти home, по-добре почни да се занимаваш с нещо друго, преди да си омазал нещата тотално, дето се вика…айде нема нужда…

  5. @Hades: Надявам се да не каже така. Не знам дали погледна нотата, за която говоря – там пише, че го правят кадърно. Макар да не е много явно описано какво, точно, е ненужно и бива изтрито.
    А за това кой какво знае и какво работи… не всички сме благословени като теб да знаем всяко файлче и всяко парче код, с което си имаме работа. Но аз съм сигурен, че има не един и двама, които ще имат полза от написаното.
    И като си такъв познавач, що не врътнеш и ти един блог, да споделиш своите знания (за благото на всички oracle админи)? Убеден съм, че ще бъде адски полезен.

  6. Това което исках да кажа, е че трябва да се внимава с подобни tool-ве дето „чистят“, нито повече нито по-малко. Аз не съм Oracle админ :D, и честно казано са много малко хората които се _занимават_ с Oracle, които могат да си сложат тази титла ;).

  7. за най-сигурно- един аrhivche на ORACLE_HOME преди patch-ване
    друг тъп проблем – listener.log като стане 2g и listenera refuse-ва връзки към него

  8. Това с архива върши работа само ако искаш да върнеш точно последният сложен пач. Естествено, още един архив почти винаги е доба идея.

    Това за listener.log може да е бъг в някоя версия, и то на определена платформа. По принцип не съм го наблюдавал на живо. Чувал съм мнения, че на 32 битови платформи ако лога стане над 2 GB почва да се забавя listener-а, защото бавно адресира края на файла, но не ми звучи логично.

    От друга страна 2 GB лог си е трудно използваем така или иначе. За това има стратегии да се rename-ва, примерно всяка седмица.

  9. Аз до 2G listener.log не съм стигал, но почти до 1G съм. Това беше преди 5-6 години и го забелязахме понеже connect-ваше много бавно. Сега ги трием като стигнат няколко стотин M.

    А rollback на patch в Oracle се случва много, много рядко вече.

  10. Аз съм стигал до 2Г лог на RedHat AS 2.1 32bit/Oracle 9.2.0.5 и листенера замръзва, после го направих да се true-ва в cron-a

Sorry, the comment form is closed at this time.