май 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
май 252009
 

Въведение:
Преди известно време Oracle обявиха пускането на пазара на Exadata Storage server. Това нещо представлява един HP DL180 G5 сървър наблъскан с 12 твърди диска. На него работи Oracle Linux 5.1 и малко допълнителен софтуер, който дава възможност на всеки Oracle Database 11.1.0.7 или по-нов да вижда тези 12 диска като локални през infiniband връзка. На практика това е нещо като shared storage, на който, обаче дисковете му се виждат като дискове, без никакви опити за RAID-ване. Всъщност има възможност от всеки физически диск да се направят няколко griddisks, като се прецизира физическото разпределение върху плочите.

Задачата:
Имам конфигурация с няколко Exadata cells и една RAC DB, чиито файлове са разположени върху тях. Искам да проверя какво ще се случи ако отпадне цял cell – дали ASM ще успее да поддържа работата на БД без абсолютно никакво прекъсване и колко време ще синхронизира дисковете като му ги върна. Дисковите групи са настроени с normal redundancy, т.е. всички данни са налични на 2 места (mirror).

Част 1:
Спирам без предупреждения един cell. В alert log-а на БД се появяват грозни съобщения:
Mon May 25 14:32:19 2009
Errors in file /ora11g/diag/rdbms/XXXX/XXXX1/trace/XXXX1_ckpt_31632.trc:
ORA-27603: Cell storage I/O error, I/O failed on disk o/10.0.1.153/DATA_CD_3_sagecell03 at offset 16826368 for data length 16384
WARNING: IO Failed. subsys:OSS dg:1, diskname:o/10.0.1.153/DATA_CD_3_sagecell03 disk:0x13.0xea55c0a4 au:4
iop:0x2af98b9dcaa0 bufp:0x2af98b757e00 offset(bytes):16826368 iosz:16384 operation:2(Write) synchronous:0
result: 4 osderr:0xc osderr1:0x0 pid:31632
OSS Subsystem error:12 (OSS_ERRCODE_NETWORKERR)
...
ORA-15080: synchronous I/O operation to a disk failed
WARNING: failed to write mirror side 2 of virtual extent 0 logical extent 1 of file 256 in group 1 on disk 19 allocation unit 4
WARNING: initiating offline of disk 19.3931488420 (DATA_CD_3_SAGECELL03) with mask 0x7e
NOTE: initiating MARK startup
Starting background process MARK
Mon May 25 14:32:20 2009
MARK started with pid=42, OS id=21872
NOTE: MARK has subscribed

Такива неща има за всичките дискове от този cell. В alertlog-а на ASM се появяват още грозни съобщения:

Mon May 25 14:32:19 2009
WARNING: initiating offline of disk 19.3931488420 (DATA_CD_3_SAGECELL03) with mask 0x7e
WARNING: kfk failed to open a disk[o/10.0.1.153/DATA_CD_2_sagecell03]

И тук такива съобщения има за всичките дискове от този cell.

Въпреки това БД продължава да си работи с пълна сила.

Част 2:
След около час и половина, в които БД работи без прекъсване, включих спреният cell. Както може да се очаква, ASM не може да се сети сам за тях – за него те са offline и той не ги търси. Закачих се с SQLPLUS към един от ASM instance-ите в клъстера:

SQL> select MOUNT_STATUS, NAME from v$asm_disk;

MOUNT_S NAME
------- ------------------------------
...
ONLINE  DATA_CD_7_SAGECELL04
OFFLINE DATA_CD_2_SAGECELL03
OFFLINE DATA_CD_5_SAGECELL03
OFFLINE DATA_CD_12_SAGECELL03
OFFLINE DATA_CD_8_SAGECELL03
OFFLINE DATA_CD_1_SAGECELL03
OFFLINE DATA_CD_10_SAGECELL03
OFFLINE DATA_CD_6_SAGECELL03
OFFLINE DATA_CD_3_SAGECELL03
OFFLINE DATA_CD_9_SAGECELL03
OFFLINE DATA_CD_4_SAGECELL03
OFFLINE DATA_CD_11_SAGECELL03
OFFLINE DATA_CD_7_SAGECELL03
ONLINE  DATA_CD_9_SAGECELL02
...

За да събудя възстановяването на данните от огледалните копия върху вече наличните дискове пуснах следната команда:

SQL> alter diskgroup DATA online disk DATA_CD_7_SAGECELL03,DATA_CD_11_SAGECELL03,DATA_CD_4_SAGECELL03,DATA_CD_9_SAGECELL03,DATA_CD_3_SAGECELL03,DATA_CD_6_SAGEGECELL03,DATA_CD_1_SAGECELL03,DATA_CD_8_SAGECELL03,DATA_CD_12_SAGECELL03,DATA_CD_5_SAGECELL03,DATA_CD_2_SAGECELL03;

Diskgroup altered.

SQL> select * from v$asm_operation;

GROUP_NUMBER OPERA STAT      POWER     ACTUAL      SOFAR   EST_WORK   EST_RATE EST_MINUTES ERROR_CODE
------------ ----- ---- ---------- ---------- ---------- ---------- ---------- ----------- --------------------------------------------
           1 ONLIN RUN           1          0          0          0          0           0

SQL> /

no rows selected

Както виждате, операцията е толкова бърза, че не можах да засека за колко време стана. Всъщност това е относително очакван резултат.

Защо става така:
Първо, при спирането на cell-а симулираме просто отпадане на диск. Е, всъщност на 12 диска. Това може да е породено от софтуерна или хардуерна грешка. Една от основните функции на ASM като high availability решение за дискове е да се справя в такава ситуация. И той наистина се справя – мърмори си в alertlog-а, но продължава да работи.

По-хубавото е бързото възстановяване на данните. Причина за това е новата в Oracle 11g функция Fast Mirror Resync. Когато един или няколко диска отпаднат без предупреждение, ASM започва да си записва кои extent-и са променени на огледалното копие. Така когато диска се върне, вместо да се rebuild-ва цялото огледало (12 диска по 450 GB са 5.4 терабайта!), се копират само промените. Това спестява много време и много IO. Естествено, това е полезно само ако се върне същият диск – примерно ако е имало проблемен кабел, повреден контролер, рестарт на cell и т.н.

Заключение:
И при отпадане на диск, и при връщането му, ASM работи много добре и точно според „рекламите“.

Още по въпроса
Тук не използвах параметрите ASM_POWER_LIMIT и новия за 11g DISK_REPAIR_TIME. Не знам дали и те работят както се очаква, но предвид видяното, нямам причини да се съмнявам.

 Posted by at 19:38