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

Часть 1

Я буду отключать диски, и наблюдать, как поведёт себя ASM и база данных, а также данная статья призвана пролить свет на количественные характеристики показателей свободного, занятого, и прочего места в ASM, при проведение эксперимента и ответить на вопрос ‘а что если..?’.

Версия ASM 12.1.0.2.190716

Конфигурация: Дисковая группа из шести дисков и двух Failgroup, по 3 диска в каждой FG, с избыточностью Normal.

SQL> create diskgroup kksdg1 normal redundancy failgroup fg1 disk 'ORCL:DISK1','ORCL:DISK2','ORCL: DISK7' failgroup fg2 disk 'ORCL:DISK3','ORCL:DISK4','ORCL:DISK4N';

Diskgroup created.
рис1

Req_mir_free_MB  — зарезервировал по одному диску на каждую failgroup, и того зарезервировано 2 диска.

Расчет: Usable_file_MB  =( Free_MB  — Req_mir_free_MB  )/2= 10 183

1.1 Заполним дисковую группу:

SQL> create tablespace kkstbs1 datafile '+kksdg1' size 7168M;

Tablespace created.

Elapsed: 00:00:16.42

Взглянем на дисковую группу:

рис2

Все диски в дисковой группе заполнились равномерно(внимание на колонку Free_MB).

1.2 Проверим устойчивость дисковой группы к выходу из строя дисков:

Я выставил ‘DISK_REPAIR_TIME’=’1m’ для дисковой группы.

1.2.1 Отключаем первый диск(DISK1):

[root@kks grid12]# oracleasm querydisk -d DISK1
Disk "DISK1" is a valid ASM disk on device [8,81]
[root@kks grid12]# ls -l /dev/* | grep 8, | grep 81
brw-rw---- 1 root disk      8,  81 Aug  5 15:56 /dev/sdf1
[root@kks grid12]# echo 1 > /sys/block/sdf/device/delete

ASM Alert log:

Wed Aug 05 16:24:36 2020
Errors in file /grid/app/diag/asm/+asm/+ASM/trace/+ASM_gmon_2966.trc:
ORA-15186: ASMLIB error function = [kfk_asm_ioerror],  error = [0],  mesg = [I/O Error]
Wed Aug 05 16:24:36 2020
NOTE: PST update grp = 2 completed successfully 
Wed Aug 05 16:25:22 2020
WARNING: Started Drop Disk Timeout for Disk 0 (DISK1) in group 2 with a value 60
WARNING: Disk 0 (DISK1) in group 2 will be dropped in: (60) secs on ASM inst 1

DB Alert log:

Wed Aug 05 16:24:36 2020
NOTE: updating disk modes to 0x5 from 0x7 for disk 0 (DISK1) in group 2 (KKSDG1): lflags 0x0    
NOTE: disk 0 (DISK1) in group 2 (KKSDG1) is offline for reads
NOTE: updating disk modes to 0x1 from 0x5 for disk 0 (DISK1) in group 2 (KKSDG1): lflags 0x0    
NOTE: disk 0 (DISK1) in group 2 (KKSDG1) is offline for writes
ри3

ASM Alert log:

Wed Aug 05 16:28:29 2020
SUCCESS: alter diskgroup KKSDG1 drop disk DISK1 force /* ASM SERVER */
рис3

По прошествии нескольких минут диск был удалён, ребаланс прошел успешно.

1.2.2 Отключаем второй диск(DISK2):

[root@kks grid12]# oracleasm querydisk -d DISK2
Disk "DISK2" is a valid ASM disk on device [8,129]
[root@kks grid12]# ls -l /dev/* | grep 8, | grep 129
brw-rw---- 1 root disk      8, 129 Aug  5 15:56 /dev/sdi1
[root@kks grid12]# echo 1 > /sys/block/sdi/device/delete

ASM Alert log:

Wed Aug 05 16:34:44 2020
WARNING: Started Drop Disk Timeout for Disk 1 (DISK2) in group 2 with a value 60
WARNING: Disk 1 (DISK2) in group 2 will be dropped in: (60) secs on ASM inst 1
Errors in file /grid/app/diag/asm/+asm/+ASM/trace/+ASM_gmon_2966.trc:
ORA-15186: ASMLIB error function = [kfk_asm_ioerror],  error = [0],  mesg = [I/O Error]
…………………………………..
Wed Aug 05 16:37:51 2020
SUCCESS: alter diskgroup KKSDG1 drop disk DISK2 force /* ASM SERVER */

DB Alert log:

Wed Aug 05 16:32:47 2020
NOTE: updating disk modes to 0x5 from 0x7 for disk 1 (DISK2) in group 2 (KKSDG1): lflags 0x0    
NOTE: disk 1 (DISK2) in group 2 (KKSDG1) is offline for reads
NOTE: updating disk modes to 0x1 from 0x5 for disk 1 (DISK2) in group 2 (KKSDG1): lflags 0x0    
NOTE: disk 1 (DISK2) in group 2 (KKSDG1) is offline for writes
рис5

На данном этапе получилось, что ребаланc завешается ошибкой ORA-15041, недостаточно места в дисковой группе и в FG1 в частности, чтобы провести ребаланс.

Данный диск _DROPPED_0001_KKSDG1  не удаляется, а переименовался, бд по-прежнему доступна и таблицы в табличном пространстве kkstbs1 тоже живы, также Usable_file_MB  в минусе.

В Alert log BD:

Wed Aug 05 16:37:51 2020
SUCCESS: disk DISK2 (1.3916017828) renamed to _DROPPED_0001_KKSDG1 in diskgroup KKSDG

1.2.3 Отключаем третий диск(DISK7):

[root@kks grid12]# oracleasm querydisk -d DISK7
Disk "DISK2" is a valid ASM disk on device [8, 161]
[root@kks ~]# ls -l /dev/* | grep 8, | grep 161
brw-rw---- 1 root disk      8, 161 Aug  6 13:17 /dev/sdk1
[root@kks ~]# echo 1 > /sys/block/sdk/device/delete
рис5

Остановим бд и перемонтируем дисковую группу, проверим, не потеряю ли я группу на данном этапе:

SQL> alter diskgroup kksdg1 dismount;
Diskgroup altered.
SQL> alter diskgroup kksdg1 mount;
Diskgroup altered.
рис6

Может показаться, что если невозможно провести ребаланс, по причине ошибки ORA-15041, ASM не удалят диски, а переименовывает их.

Но это только показалось, в ходе эксперимента было десятки кейсов удаления дисков, и поведение может отличаться. Например, если удалить, созданное на этой дисковой группе табличное пространство kkstbs1, то произойдёт это:

SUCCESS: grp 2 disk _DROPPED_0000_KKSDG1 going offline 
SUCCESS: grp 2 disk _DROPPED_0001_KKSDG1 going offline
NOTE: Disk _DROPPED_0000_KKSDG1 in mode 0x0 marked for de-assignment
NOTE: Disk _DROPPED_0001_KKSDG1 in mode 0x0 marked for de-assignment

диски удалятся, но последующие несколько экспериментов показали, что это не всегда так.

Какой в этом смысл? Зачем держать эти диски, которых фактически нет.

Также, если удалять дисковую группу через drop diskgroup force including contents, то повторное использование дисков не требует зачистки их заголовков через dd, если использовать просто drop diskgroup, то нужно чистить заголовок диска, чтобы его повторно использовать(это особенность asm 12), force можно применить если группа не замонтирована.

И на сладкое, двойное удаление дисковой группы(тест на то, что заголовки дисков живы после удаления группы):

SQL> drop diskgroup kksdg1 force including contents;
drop diskgroup kksdg1 force including contents
*
ERROR at line 1:
ORA-15039: diskgroup not dropped
ORA-15230: diskgroup 'KKSDG1' does not require the FORCE option


SQL> drop diskgroup kksdg1;

Diskgroup dropped.

SQL> drop diskgroup kksdg1 force including contents;
drop diskgroup kksdg1 force including contents
*
ERROR at line 1:
ORA-15039: diskgroup not dropped
ORA-15063: ASM discovered an insufficient number of disks for diskgroup
"KKSDG1"


SQL> alter diskgroup kksdg1 mount;
alter diskgroup kksdg1 mount
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15017: diskgroup "KKSDG1" cannot be mounted
ORA-15040: diskgroup is incomplete


SQL> drop diskgroup kksdg1 force including contents;  <-----  Здесь я вернул отключенные диски(просканировав шину SCSI ) и смогу удалить дисковую группу ещё раз 0_о

Diskgroup dropped.

SQL>

Вероятно будет часть 3 и версия asm 19, с применением утилит ASM tools used by Support : KFOD, KFED, AMDU (Doc ID 1485597.1), т.к. как всегда(у меня), вопросов больше, чем ответов.

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:

  • Sun Jul 19 20:38:50 2020
  • WARNING: Write Failed. group:2 disk:0 AU:1 offset:1044480 size:4096
  • path:ORCL:DISK2
  • Sun Jul 19 20:38:50 2020
  • SQL> alter diskgroup TESTKKS1 dismount force /* ASM SERVER:816479400 */
  • SUCCESS: diskgroup TESTKKS1 was dismounted
  • Sun Jul 19 20:38:50 2020
  • SUCCESS: alter diskgroup TESTKKS1 dismount force /* ASM SERVER:816479400 */
  • SUCCESS: ASM-initiated MANDATORY DISMOUNT of group TESTKKS1
  • ASMCMD> lsdg -g testkks1
  • ASMCMD-8001: diskgroup ‘testkks1’ does not exist or is not mounted

Дисковая группа потеряна.

Конфигурация с несколькими дисками в одной Failgroup будет рассмотрена в следующей части.

ASM 19. При попытке воспользоваться KFOD ошибка gipclibInitializeClsd: clscfpinit failed with -1

Проводя очередные тесты с использованием kfed и kfod, наткнулся на баг, который как бы исправлен в версии 19.1. Ирония в том, что я использовал 19.3+RU19.7, установив патч через gridSetup.sh -applyRU.

После установки патча, но до развертывания самого ASM (это важно, т.к. никакие env ещё не выставлены), захотелось глянуть на диски, а там сюрприз:

[root@oratest ~]# /grid/app/oracle/19/bin/kfod.bin disks=all dscvgroup=true name=true asm_diskstring='ORCL:*'
Error 2 initializing CRS infrastructure
clscfpinit: Failed clsdinitx [-1] ecode [64]
2020-08-28 12:27:42.452 [2999893248] gipclibInitializeClsd: clscfpinit failed with -1.

Ошибка похоже на то, как будто чего-то не хватает gipclibInitializeClsd. Пробуем выставить ORACLE_HOME.

[root@oratest ~]# export ORACLE_HOME=/grid/app/oracle/19
[root@oratest ~]# /grid/app/oracle/19/bin/kfod.bin disks=all dscvgroup=true name=true asm_diskstring='ORCL:*'
Error 1 initializing CRS infrastructure
---------------------------------------------------------------------
 Disk  Size    Path        DiskName  Disk Group    User     Group   
=====================================================================
   1: 51199 MB ORCL:DISK1                                            #                             
KFOD-00301: Unable to contact Cluster Synchronization Services (CSS). Return code 2 from kgxgncin.

Теперь всё как нужно. Если поискать на MOS, то можно найти это:

Kfed Read — Clscfpinit: Failed Clsdinitx [-1] Ecode [64] (Doc ID 2547043.1)

Почему бы просто не обновить ноту ASM tools used by Support : KFOD, KFED, AMDU (Doc ID 1485597.1) и не считать это багом.