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), т.к. как всегда(у меня), вопросов больше, чем ответов.

Резкий рост log file sync и buffer busy wait при незначительном повышении нагрузки.

Для начала приведу первоисточник, благодаря которому, проблема была локализована и устранена:

  1. High log file sync waits? Check log parallelism!

2.  Finding the root cause of “CPU waits” using stack profiling

В первоисточнике вы можете подробнее ознакомится с механизмами и параметрами, которые будут упомянутs здесь, я же только опишу конечный результат, который получился у меня.

Описание проблемы: после того как бд переехала на сервер с 4мя сокетами, по достижению определённой нагрузки, резко вырастали ожидания  log file sync и buffer busy wait.

Окружение: RHEL 7, Oracle 12.1.0.2 + BP, ASM 12.1.0.2 + BP

Как это выглядит:

AWR:

Lab128:

Промежутки времени для AWR и Lab128 взяты немного разные, поэтому есть разница в цифрах, но общей картины это не меняет, всё очень плохо.

1.      Первым делом решено было бороться с log file sync(LFS).

Из ссылки 1 я узнаю про параметр _log_parallelism_max.

Критерии, по которым можно попробовать оценить, есть ли смыл в изменении его значения по умолчанию:

1.      Ожидание log file sync гораздо выше(более чем в 2 раза) log file parallel write

Например, log file sync= 1мс, а log file parallel write=2мс и выше.

2.      Оценить значении log file parallel write P3(Number of I/O requests) из v$active_session_history/dba_active_session_history в нагруженный и не нагруженный период. P3 должен изменяться, от 1 до _log_parallelism_max т.е. быть 2,3,4,5…

3.      При повышении значения log file parallel write P3(Number of I/O requests), log file sync должен расти, но возможно не обязан.

4.      Количество потоков CPU больше, либо равно 64.

5.      Log File Parallel Writes Take Longer with a Higher CPU Count (Doc ID 1980199.1)

Я применил значение _log_parallelism_max=2

Результат:

AWR:

log file sync снизился с 5.68мс до 1.15мс(по AWR), казалось бы победа, но нет, присутствует ожидание buffer busy wait, которое оказывает сильное влияние на работу приложения, да и само значение log file sync всё ещё выше, чем на старом сервере, даже после улучшения.

2.   Здесь переходим ко второй части.

Ожидания buffer busy wait с работой приложения никак не связано, профиль нагрузки практически не менялся. Kоличественные характеристики полезной работы бд: dml выполненных в секунду, количество коммитов в секунду, LIO в секунду в целом выросли на 5%-10% и после переезда на 4 сокета, buffer busy wait раскрылся во всей красе, опять таки только по достижению определённой нагрузки(превышение на 5%-10%), если её не превышать, то всё хорошо.

Всё хорошо — это означает, что ожидания buffer busy wait стремятся к нулю, а log file sync значительно меньше 1мс (0.3-0.6мс) для работы под нужной нагрузкой.

Вышеописанное должно привести на мысль, что что-то не так с железом, либо проблема на уровне OS. Здесь на помощь приходит вторая ссылка, из которой становится понятно, что вероятно дело в kernel.numa_balancing. И действительно, если поискать на MOS используя kernel.numa_balancing, то получим:

  1. Requirements for Installing Oracle Database 19c on OL7 or RHEL7 64-bit (x86-64) (Doc ID 2551169.1)
  2. (EX39) NUMA-enabled database servers experience continuously high load or reduced performance after updating to Exadata 12.2.1.1.0 or higher. (Doc ID 2319324.1)

А также из общедоступных источников: Optimal Configuration of Memory System

https://support.huawei.com/enterprise/en/doc/EDOC1000117211/1395f4a4/optimal-configuration-of-memory-system

Откуда следует вывод, что без kernel.numa_balancing=0 никуда. И действительно, после применения данного параметра, производительность бд значительно выросла:

В итоге, конфигурация имеет значение _log_parallelism_max=2 на уровне бд и kernel.numa_balancing=0 на уровне ОС.

Также эксперимент был проведён на Solaris Sparc:

 Solaris Sparc : 11.4+patch

Oracle 12.1.0.2 + BP

ASM 19.7

И _log_parallelism_max=2 VS_log_parallelism_max=1:

Нагрузка тут уже в 3 раза выше, чем на Linux, а снижение LFS c 0.77 мс до 0.60 мс дало прирост быстродействия на стороне приложения до 30%.

Также _log_parallelism_max=1 снизил потребление ЦПУ на 7%.

Выводов нет, делайте их сами, а использование скрытых параметров должно быть обоснованным и обдуманным решением.

Oracle Cloud Control 13c- очищаем неочищаемые инциденты.

Случается так, что нельзя очистить инциденты из OEM13c.

Инцидент может быть просто не ‘кликабельным’ и виден он только если перейти в таргет, затем в All Metrics, увидим Open Metric Events , а в Incident Manager его нет.

Также выполнение всех требований (This incident will be automatically cleared when the underlying issue is resolved.) по его устранению не вызывает авто удаление инцидента.

Либо инцидентов может быть слишком много, чтобы быстро зачистить их с веб-консоли.

Я знаю два варианта решения этих проблем:

1.      Используя утилиту emcli.

Подключаемся к репозитарию OEM13c и запросом строим скрипт по зачистке:

select a.adr_related,a.problem_num,b.target_name, a.incident_num, a.severity, a.creation_date, a.summary_msg,

q'!emcli delete_incident_record -force -incident_number_list=!'||a.incident_num scr_incident,

q'!emcli delete_incident_record -force -incident_number_list=!'||a.problem_num scr_problem

from mgmt$incidents a, mgmt$target b, mgmt$INCIDENT_CATEGORY c

where a.target_guid=b.target_guid

and a.incident_id=c.incident_id

--and a.summary_msg like '%MesageName%'

--and adr_related=0

and b.target_name like 'targetName%'

--and a.incident_num=78381

and a.severity!='Clear'

В колонках scr_incident и scr_problem будет сгенерирована строка на каждый инцидент/проблему для удаления. Фильтровать можно по имени таргета, инциденту, или куску текста из сообщения об инциденте.

Далее логинемся по ssh на сервер где установлен Weblogic, переходим в MW_HOME/bin и выполняем:

emcli login -username=sysman

Enter password :    <------ Указываем пароль для SYSMAN

Теперь выполняем команду на удаление полученную из скрипта:

[oracle]$ emcli delete_incident_record -force -incident_number_list=218893

=========

Results

=========

=> Incident 218,893 has been successfully deleted.

Если же при выполнении удаления инцидента есть сообщения вида:

Incident 201,646 cannot be deleted. It may be closed, does not exist or is not accessible to this user.

Или

Incident 104,021 is a diagnostic incident and cannot be deleted.

Тогда переходим к варианту номер два.

2.  Вычистить данные об инцидентах из бд репозитория.

Подключаемся к репозитарию OEM. Создаём две таблицы(можете использовать свой вариант, главное запомнить эти ID), в которые запишем ID инцидентов, которые хотим удалить. Одна таблица будет содержать ISSUE_ID другая EVENT_INSTANCE_ID. Я собираю ISSUE_ID и EVENT_INSTANCE_ID  для инцидентов связанных с ошибкой ORA 3137:

create table KKS$ISSUE_ID as select pp.ISSUE_ID from em_issues_msg pp where pp.SUMMARY_MSG like '%ORA 3137%'
create table KKS$EVENT_INSTANCE_ID as select oo.EVENT_INSTANCE_ID from  EM_EVENT_MSGS oo where msg like '%ORA 3137%'

Далее генерируем скрипт по удалению данных для ISSUE_ID:

select q'!delete from !'||s.TABLE_NAME ||q'! e1 where !' 
|| case s.COLUMN_NAME when 'ISSUE_ID' then q'!ISSUE_ID in (select issue_id from KKS$ISSUE_ID);!'
                      when 'INCIDENT_ID' then q'!ISSUE_ID in (select issue_id from KKS$ISSUE_ID);!'
                      when 'EVENT_INSTANCE_ID' then q'!EVENT_INSTANCE_ID in (select p3.event_instance_id  from KKS$EVENT_INSTANCE_ID p3);!' 
  else q'!Wrong column !'||s.COLUMN_NAME
    end
from dba_tab_cols s where s.COLUMN_NAME='ISSUE_ID'; ---<<<<----- условие ISSUE_ID

Затем для EVENT_INSTANCE_ID:

select q'!delete from !'||s.TABLE_NAME ||q'! e1 where !' 
|| case s.COLUMN_NAME when 'ISSUE_ID' then q'!ISSUE_ID in (select issue_id from KKS$ISSUE_ID);!'
                      when 'INCIDENT_ID' then q'!ISSUE_ID in (select issue_id from KKS$ISSUE_ID);!'
                      when 'EVENT_INSTANCE_ID' then q'!EVENT_INSTANCE_ID in (select p3.event_instance_id  from KKS$EVENT_INSTANCE_ID p3);!' 
  else q'!Wrong column !'||s.COLUMN_NAME
    end
from dba_tab_cols s where s.COLUMN_NAME='EVENT_INSTANCE_ID';---<<<<----- условие EVENT_INSTANCE_ID

Эти два скрипта генерируют выражение delete для таблиц у которых встречается колонка SSUE_ID или EVENT_INSTANCE_ID в связке с нашими таблицами которые мы создали ранее.

Метод номер два гораздо опаснее чем метод номер один. Перед его применением просчитайте варианты отката бд к моменту до удаление(как вариант, используйте точку восстановления).

Всем ‘зелёных’ OEM!

Enq: SS- Contention

На эту тему есть хорошее описание от Riyaj Shamsudeen( https://orainternals.wordpress.com/2012/02/13/temporary-tablespaces-in-rac/). Откуда берётся это ожидание и почему так. Также есть ещё статья https://ebs12blog.wordpress.com/2017/09/24/enq-ss-contention-and-enq-ts-contention-waits-in-a-rac-database-in-ebs-environment , есть и другие статьи.

И есть нота на MOS: EVENT: DROP_SEGMENTS — Forcing cleanup of TEMPORARY segments (Doc ID 47400.1). Но всё выше описанное может ‘показаться’ не рабочим или ресурсоёмким.

Я пройдусь по возможным вариантам(а может есть ещё варианты ?), как избежать enq: ss- contention:

1.      Выполнить ‘какой либо’ resize.

Это может быть, как добавление темп файлов, так и выполнение shrink табличного пространства или coalesce.

Данный метод неэффективен (сколько можно добавлять файлов?) и ресурсоёмким, шринк/coalesce темпа создаёт нагрузку на ввод-вывод (регулярно это делать- сомнительное дело).

2.      Выполнить рекомендацию из ноты 47400.1

Если выполнить так как описано, то с виду будет выглядеть так, как будто решение alter session set events ‘immediate trace name DROP_SEGMENTS level TS#+1 не работает, эффект будет не заметен.

Первый вариант выглядит нерациональным, но если выбора нет, то и он сойдёт)))

А вот второй вариант выглядит более интересным, и он описан в блоге ebs12blog.wordpress.com(ссылка выше).

И тут главное не упустить две важные детали:

1.      Выполнять alter session set events ‘immediate trace name DROP_SEGMENTS level TS#+1 нужно в цикле, т.к. за одно выполнение освобождается определённое количество (или % ?) экстентов.

2.      Выполнять нужно на каждом экземпляре бд (для освобождения не занятых экстентов, и дальнейшего равномерного использования по всем экземплярам) или на том экземпляре, где больше всего свободных экстентов.

После выполнения скрипта на каждом инстансе бд, выглядит это так (gv$sort_segment):

Нет занятых и свободных. 🙂

Регулярное выполнение DROP_SEGMENTS level TS#+1 на нодах, побочных эффектов не выявило. Версия бд 12.1.0.2

Неинформативная ошибка ORA-29259 при использовании utl_http.

Разобрали недавно с коллегой странный случай: при обращении к сайту, который работает по https, получаем ошибку (пример обращения):

select utl_http.request(url => 'Ссылка', 
wallet_path    => 'file: Путь до wallet',  
wallet_password => 'Пароль') 
from dual;

ORA-29273: HTTP request failed

ORA-29259: end-of-input reached

ORA-06512: at "SYS.UTL_HTTP", line 1491 

ORA-06512: at line 1

Проблема стабильно воспроизводится в 12.1.0.2.170117 и 11.2.0.4.8, но работает как положено (ошибки нет, возвращается ожидаемый результат) в 18.0.0.0.0 и 12.2.0.1.180116. В трассировке (проблемного вызова) sqlnet имеется строка о том, что ‘что-то пошло не так’:

nserror: nsres: id=0, op=77, ns=12630, ns2=0; nt[0]=0, nt[1]=0, nt[2]=0; ora[0]=0, ora[1]=0, ora[2]=0

Имея вышеуказанные входные данные, найти в чем проблема не удалось. Проверили, что вообще использует этот сайт tls, ssl, шифры… при подключении:

Protocol : TLSv1.2

Cipher   : ECDHE-RSA-AES128-GCM-SHA256

И вроде как тоже, эта информация ни о чем не говорит. Спустя несколько дней поисков на MOS нашлась нота “UTL_HTTP fails with ORA-28860 In A 12c Database (Doc ID 2225262.1)”, где упоминается: ECDHE_RSA_WITH_AES_128_GCM_SHA256, а наш:

ECDHE-RSA-AES128-GCM-SHA256… очень похожи))

И ошибка:

ORA-29273: HTTP request failed
ORA-28860: Fatal SSL error
ORA-06512: at "SYS.UTL_HTTP", line 1491
ORA-06512: at line 1

Тоже почти наша (особенно line 1491), только у нас без ORA-28860.

Установили рекомендованный патч из ноты на 12.1.0.2, вызов начал работать как и ожидалось.

Длительное ожидание latch: row cache objects

Я с коллегой разбирали интересный случай, связанный с ожиданием ‘latch: row cache objects’ при выполнении запроса.

По ASH на ожидание ‘latch: row cache objects’ уходило значительная часть времени (до 48%):

Большое количество времени теряется на ожидании ‘latch: row cache objects’ Дополнительно, проанализировав трассировку 10046, выявлена большая ‘не учтённая’ часть времени:

Данные приведённые на рис 1. и рис. 2 взяты от разных сессий, но сути дела это не меняет. Далее выяснилось, что конкуренция ведётся за области словаря данных dc_users и dc_tablespace.

Исходя из доступных описаний dc_users и dc_tablespace, непонятно, для чего понадобилась блокировка(latch) при выполнении оператора select. Далее, была использована утилита perf для анализа вызовов на уровне OS и получена следующая картина:

На основе имеющихся данных была найдена статья ‘12c: эффекты Automatic Dynamic Sampling’.

Где указывалось, что защёлки ‘dc_users’ и ‘dc_tablespace’ могут быть связаны с HJ и багом 13902396. В баге 13902396, в разделе DIAGNOSTIC ANALYSIS есть ‘qerhjFetch’ как на рисунке, и решение на основе HJ.

Смотрим ASH ещё раз:

Теперь проблема выглядит не такой сложной…

Проблема воспроизводится в 11.2.0.4 и 12.1.0.2, обе версии имеют нужные PSU. 

Теперь мы можем попробовать сделать что ни будь с HJ. Я принял решение использовать параметр “_gby_hash_aggregation_enabled = false” на уровне сессии(это задание по расписанию). После применения параметра “_gby_hash_aggregation_enabled = false”, ожидание защёлки исчезло, производительность определённого SQL выражения выросло в 4 раза, с 5тыс выполнений в секунду до 20тыс выполнений в секунду.

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) и не считать это багом.