ASM: disk_repair_time

В понеделник писах за приятната възможност на ASM за Fast Mirror Resync. Тогава забравих да спомена за един параметър (също нов в 11g), който е от съществено значение за тази функционалност: disk_repair_time.

Параметъра disk_repair_time указва колко време след отпадането на един диск имаме приятната възможност за Fast Mirror Resync.

Когато даден диск отпадне от дисковата си група, ASM започва да си води сметка кои от разположените върху него extents са променени в „отсъствие“ на диска. Тази информация се записва под формата на нещо като bitmap в ASM Header-а. На базата на този bitmap се прави и самият fast mirror resync когато се появи диска.

Обаче тази информация не може да се пази вечно. И вместо да се затормозяваме с някакъв синтаксис за триене на информация от тотално загинал диск, Oracle са го направили автоматично. След изтичането на определен период от време, информацията в този битмап се затрива; затрива се и всичката информация за съществуването на този диск (т.е. той се бори за загубен завинаги) – нещо като автоматичен drop disk. От това има две последствия:

– Ако успеем да възстановим диска, но това се случи след изтичането на периода, указан от disk_repair_time, той не се разпознава от системата като „свой“ и трябва да се добави като нов диск с add disk
– Когато изтече периода за disk_repair_time, поради drop-ването на диска започва ребалансиране на extent-и по наличните дискове. Това може да се възпрепятства ако се настори asm_power_limit=0.

Синтаксиса за сетване на параметъра disk_repair_time e:

SQL> ALTER DISKGROUP data SET ATTRIBUTE 'disk_repair_time' = '12h';

Diskgroup altered.

Проверка на текущата стойност се прави с:

select GROUP_NUMBER, VALUE from v$asm_attribute where name='disk_repair_time';

GROUP_NUMBER VALUE
------------ ------------------------------
           1 12h
           2 3.6h

Стойността по подразбиране, при стандартна ASM инсталация, е 3.6 часа. Тази стойност е взета от някаква статистика за средното време за отстраняване на хардуерен проблем с кабели, RAID контролери и т.н. Естествено, в България времето за доставка на един обикновен infinband кабел е поне 2 седмици (ако имаш късмет), така че това не важи за нас.

Според Oracle този параметър може да се сетне на произволно високa стойност. Това, обаче, е нож с две остриета: колкото повече време си дадем за оправяне на проблема (с последващ елементарен и бърз fast mirror resync), толкова по-дълго данните ни остават без mirror.