Случается так, что нельзя очистить инциденты из 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 в связке с нашими таблицами которые мы создали ранее.
Метод номер два гораздо опаснее чем метод номер один. Перед его применением просчитайте варианты отката бд к моменту до удаление(как вариант, используйте точку восстановления).
И есть нота на 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
Разобрали недавно с коллегой странный случай: при обращении к сайту, который работает по 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 имеется строка о том, что ‘что-то пошло не так’:
Имея вышеуказанные входные данные, найти в чем проблема не удалось. Проверили, что вообще использует этот сайт 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’ при выполнении запроса.
По 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 и получена следующая картина:
Где указывалось, что защёлки ‘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тыс выполнений в секунду.
Данная статья призвана пролить свет на количественные характеристики показателей свободного, занятого и прочего места в ASM, т.к. иногда возникают вопросы.
Версия ASM 12.1.0.2.190716 Конфигурация 1: Дисковая группа из двух дисков с избыточностью Normal.
Создаём группу с нормальной(двойной избыточностью):
SQL> CREATE DISKGROUP testkks1 normal REDUNDANCY DISK 'ORCL:DISK1','ORCL:DISK2';
Diskgroup created.
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.
Конфигурация 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 диск на виртуальной машине я не нашел ))) —-
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.
Выведение ещё одного диска из строя приведёт к потере табличного пространства или дисковой группы.
Проводя очередные тесты с использованием kfed и kfod, наткнулся на баг, который как бы исправлен в версии 19.1. Ирония в том, что я использовал 19.3+RU19.7, установив патч через gridSetup.sh -applyRU.
После установки патча, но до развертывания самого ASM (это важно, т.к. никакие env ещё не выставлены), захотелось глянуть на диски, а там сюрприз:
Входные данные: сессии находятся в ожидании latch: row cache objects, раздел dc_rollback_segments, что очень замедляет работу базы данных. dc_rollback_segments легко виден в AWR за проблемный период в разделе Dictionary Cache Stats.
При таких входных данных, на MOS десятки багов, которые исправлены в 12.1.0.2, а то и в 11.2 или ещё раньше.
Собираем информацию далее.
Смотрим в v$undostat.tuned_undoretention, затюненое retention плавно добралось до 90000 сек, поднимали это значение два запроса, время выполнения которых было гораздо, гораздо ниже 90000сек.
Далее смотри dba_undo_extents.status, и выясняется, что почти все экстенты UNEXPIRED, очень мало ACTIVE, и почти нет EXPIRED.
И того имеем:
undo_retention=20000 в файле параметров(spfile).
Затюненое tuned_undoretention=90000
Свободных undo экстентов нет.
Проверяем новые данные на MOS, в уме держим мысль: “как уменьшить tuned_undoretention?”. И находим, очень похожий баг, который исправлен в 11.2.0.1,10.2.0.5 и т.д, про 12.1 ни слова.
Bug 7291739 — Contention with auto-tuned undo retention or high TUNED_UNDORETENTION (Doc ID 7291739.8)
В качестве решения проблемы, включаем два скрытых параметра, первый, отключение undo автотюненга, второй выставление наивысшего порога undoretention.
krotovks.com 