Oracle ASM. Что будет представлять из себя дисковая группа при различной конфигурации дисков. Часть 1.

Данная статья призвана пролить свет на количественные характеристики показателей свободного, занятого и прочего места в ASM, т.к. иногда возникают вопросы.

Версия ASM 12.1.0.2.190716 Конфигурация 1: Дисковая группа из двух дисков с избыточностью Normal.

Создаём группу с нормальной(двойной избыточностью):

SQL> CREATE DISKGROUP testkks1 normal REDUNDANCY DISK 'ORCL:DISK1','ORCL:DISK2';
Diskgroup created.

Смотрим результат:

https://docs.oracle.com/database/121/OSTMG/GUID-E775902B-6461-4E61-BC43-231D1701FBDA.htm#OSTMG94549

Total_MB — полный объем сырого места.

Free_MB — свободно сырого места.

Usable_file_MB- свободного (защищенного) места с учетом избыточности

Req_mir_free_MB- количество пространства, которое требуется для восстановления full redundancy after the most severe failure that can be tolerated by the disk group.

1.1 Добавим один диск в группу:

SQL> ALTER DISKGROUP testkks1 ADD DISK 'ORCL:DISK3';
Diskgroup altered.

Смотрим результат:

Что мы тут видим:

Total_MB- увеличился на объём одного диска

Free_MB- увеличился на объём одного диска

Req_mir_free_MB- увеличился на объём одного диска

Шок контент: Usable_file_MB- не изменился. Как было 5042, так и осталось.

1.2 Удалим диск:

Вернулись туда откуда и пришли.

1.3 Добавим два диска в дисковую группу:

SQL> ALTER DISKGROUP testkks1 ADD DISK 'ORCL:DISK3','ORCL:DISK4' REBALANCE POWER 9 WAIT;
Diskgroup altered.

Смотрим результат:

Что мы тут видим:

Total_MB- увеличился на объём двух дисков

Free_MB- увеличился на объём двух дисков

Req_mir_free_MB- равен объему одного диска

Usable_file_MB- изменился, добавилась половина объёма одного диска

Добавим ещё один диск:

SQL> ALTER DISKGROUP testkks1 ADD DISK 'ORCL:DISK5' REBALANCE POWER 9 WAIT;	
Diskgroup altered.

Total_MB- увеличился на объём одного диска

Free_MB- увеличился на объём одного диска

Req_mir_free_MB- равен объему одного диска (не изменился)

Usable_file_MB- изменился, добавилась половина объёма одного диска

Теперь сделаем заключение, о том, что:

Total_MB- общий объём, именно, сырого места

Free_MB- общий объём свободного, именно, сырого места

Req_mir_free_MB- равен объёму одного диска, если указано: normal избыточности, количество дисков больше или равно 3, и если не указывать Failgroup при создании дисковой группы индивидуально для дисков.

Из этого следует, что при normal избыточности (двойной) и количестве дисков 3 и более, Usable_file_MB будет равен:

Usable_file_MB=(Free_MB — Req_mir_free_MB)/2

Для 5 дисков:

Usable_file_MB=(25438-5119)/2= 10 159

Для 4 дисков:

Usable_file_MB=(20321-5119)/2=7 601

Для 3 дисков:

Usable_file_MB=(15204-5119)/2= 5 042

Для 2 дисков Usable_file_MB=(10136-0)/2= 5 068

Пограничный случай для 3х дисков показывает, что начиная с этого количества дисков, ASM начинает резервировать 1 диск, для восстановления full redundancy after the most severe failure that can be tolerated by the disk group.

https://docs.oracle.com/database/121/OSTMG/GUID-CF644399-17BF-4A2B-B01A-8F11B90A5267.htm#OSTMG10201

Конфигурация 2: Дисковая группа из двух дисков с избыточностью Normal и её заполнение.

1.1 Исходное состояние:

Заполняем:

SQL> create tablespace kkstbs1 datafile '+TESTKKS1' size 5050M autoextend on next 10m;
Tablespace created.

Результат:

Расширим файл данных ещё на 10М:

SQL> alter database datafile '+TESTKKS1/kksdb/DATAFILE/KKSTBS1.256.1046190953' resize 5060M;
Database altered.

Результат:

Расширим ещё на 10М:

SQL> alter database datafile '+TESTKKS1/kksdb/DATAFILE/KKSTBS1.256.1046190953' resize 5070M;
alter database datafile '+TESTKKS1/kksdb/DATAFILE/KKSTBS1.256.1046190953' resize 5070M
*
ERROR at line 1:
ORA-01237: cannot extend datafile 5
ORA-01110: data file 5: '+TESTKKS1/KKSDB/DATAFILE/kkstbs1.256.1046190953'
ORA-17505: ksfdrsz:1 Failed to resize file to size 648960 blocks
ORA-15041: diskgroup "TESTKKS1" space exhausted

Не тут-то было.

На данном этапе, делаем два важных вывода, Free_MB это действительно сырое место, т.к. его значение в двух итерациях(1. Создание табличного пространства (Free_MB 30 и Usable_file 15) и расширение файла данных (Free_MB 10 и Usable_file 5)) в два раза (Normal избыточность) больше чем Usable_file_MB.

1.2 Добавляем диск:

SQL> ALTER DISKGROUP testkks1 ADD DISK 'ORCL:DISK3' REBALANCE POWER 9 WAIT;
Diskgroup altered.

Результат:

Теперь расширим файл данных на существенные 1024м:

SQL> alter database datafile '+TESTKKS1/kksdb/DATAFILE/KKSTBS1.256.1046190953' resize 6074M;
Database altered.

На данном этапе заключим, что Usable_file_MB ушел в минус за счет одного диска, который зарезервирован для восстановления full redundancy after the most severe failure that can be tolerated by the disk group, иначе получим ошибку ORA-15041, которая говорит о том, что закончилось место на дисковой группе. И заметим, что данные начали попадать на этот диск задолго до того, как Usable_file_MB стал отрицательным.

Очевидно, что далее заполнять дисковую группу бессмысленно, т.к. максимум мы можем уйти в минус, на данном этапе, это Usable_file_MB = -5119.

А теперь обратимся к документации:

REQUIRED_MIRROR_FREE_MB indicates the amount of space that must be available in a disk group to restore full redundancy after the worst failure that can be tolerated by the disk group without adding additional storage. This requirement ensures that there are sufficient failure groups to restore redundancy. Also, this worst failure refers to a permanent failure where the disks must be dropped, not the case where the disks go offline and then back online.

Согласно данному описанию, в текущей ситуации(Usable_file_MB в минусе, на диске, который должен быть резервным, лежит данных больше, чем положено), если мы внезапно потеряем один диск, то произойдёт что интересное.

Проверяем, теряем диск:

SQL> alter diskgroup testkks1 set attribute 'DISK_REPAIR_TIME'='10m';
Diskgroup altered.

——Здесь я сменил тип устройства с nvme на scsi (изменились названия Failgroup) т.к. нормального способа отключить nvme диск на виртуальной машине я не нашел ))) —-

[root@kks grid12]# ./bin/kfed read /dev/sdf1 | grep dskname
kfdhdb.dskname:                   DISK1 ; 0x028: length=5

Удаляем диск:

[root@kks grid12]# echo 1 > /sys/block/sdf/device/delete

Алертлог с бд:

Sun Jul 19 19:34:23 2020
NOTE: updating disk modes to 0x5 from 0x7 for disk 3 (DISK1) in group 2 (TESTKKS1): lflags 0x0
NOTE: disk 3 (DISK1) in group 2 (TESTKKS1) is offline for reads
NOTE: updating disk modes to 0x1 from 0x5 for disk 3 (DISK1) in group 2 (TESTKKS1): lflags 0x0
NOTE: disk 3 (DISK1) in group 2 (TESTKKS1) is offline for writes

Ребаланс ещё не запускался, с момента потери диска 10мин не прошло:

Попробуем расширить файл данных ещё на 1024М:

SQL> alter database datafile '+TESTKKS1/kksdb/DATAFILE/KKSTBS1.256.1046190953' resize 7098M;
Database altered.

Тут странность номер 1, хотя убитый диск “disk 3 (DISK1) in group 2 (TESTKKS1) is offline for writes”, его Free_MB уменьшился с 1012Мб до 332мб. Странность номер 2, максимальный Usable_file_MB = 5 042 в данной конфигурации, размер файла данных на момент удаления диска 6074Мб.

По прошествии ‘DISK_REPAIR_TIME’=’10m’ диск благополучно удалился:

Sun Jul 19 19:48:09 2020

SUCCESS: alter diskgroup TESTKKS1 drop disk DISK1 force /* ASM SERVER */

Но диск остался переименованным _DROPPED_0003_TESTKKS1.

Попытка провести ребеланс или добавить файл размером 10м неудачна:

ORA-15041: diskgroup "TESTKKS1" space exhausted
Sun Jul 19 19:48:12 2020
WARNING: Rebalance encountered ORA-15041; continuing


SQL> alter tablespace kkstbs1 add datafile '+TESTKKS1' size 10m;                    
alter tablespace kkstbs1 add datafile '+TESTKKS1' size 10m
*
ERROR at line 1:
ORA-01119: error in creating database file '+TESTKKS1'
ORA-17502: ksfdcre:4 Failed to create file +TESTKKS1
ORA-15041: diskgroup "TESTKKS1" space exhausted

Итого, на данный момент получилось, дисковая группа с normal избыточностью, из 3 дисков, превратилась в группу с двумя дисками.

При двух или трёх дисках, Usable_file_MB дисковой группы равен 5 042 Мб, при потере диска и нахождении Usable_file_MB в минусе, теряется избыточность тех данных, которые вызвали минус, т.к. сейчас размер табличного пространства 7098M.

Выведение ещё одного диска из строя приведёт к потере табличного пространства или дисковой группы.

Проверяем:

[root@kks grid12]# ./bin/kfed read /dev/sdi1 | grep dskname
kfdhdb.dskname:                   DISK2 ; 0x028: length=5

[root@kks grid12]# echo 1 > /sys/block/sdi/device/delete

ASM alertlog: