Errors

ORA-00800: soft external error, arguments: [Set Priority Failed]. Dism(128). Oracle 19c

Krotov KonstantinОставьте комментарий

Коротенькая заметка про очередные грабли, всплывшие где-то с 19.16, но так-же существуют в плоть до 19.22.

Дано:

Oracle: 19.22

OS: Oracle Linux Server release 8.3

Kernel: 5.4.17-2011.7.4.el8uek.x86_64

При старте БД наблюдаем в алерт логе такую картину:

Starting background process VKTM
Errors in file /oracle/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_vktm_61290.trc  (incident=146927):
ORA-00800: soft external error, arguments: [Set Priority Failed], [VKTM], [Check traces and OS configuration], [Check Oracle document and MOS notes], []
Incident details in: /oracle/app/oracle/diag/rdbms/orcl/orcl/incident/incdir_146927/orcl_vktm_61290_i146927.trc
Error attempting to elevate VKTM's priority: no further priority changes will be attempted for this process


Starting background process LGWR
Errors in file /oracle/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_lgwr_61456.trc  (incident=147055):
ORA-00800: soft external error, arguments: [Set Priority Failed], [LGWR], [Check traces and OS configuration], [Check Oracle document and MOS notes], []
Incident details in: /oracle/app/oracle/diag/rdbms/orcl/orcl/incident/incdir_147055/orcl_lgwr_61456_i147055.trc

Starting background process DBW0
Errors in file /oracle/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_dbw0_61444.trc  (incident=147039):
ORA-00800: soft external error, arguments: [Set Priority Failed], [DBW0], [Check traces and OS configuration], [Check Oracle document and MOS notes], []
Incident details in: /oracle/app/oracle/diag/rdbms/orcl/orcl/incident/incdir_147039/orcl_dbw0_61444_i147039.trc

Просмотрев трейсы, находим много общего, а именно:

Error Info: Category(-2), Opname(skgdism_send), Loc(sp.c:setpr:0), ErrMsg(Operation not permitted) Dism(128)

Если пойти на MOS то можно найти ноту ORA-00800: soft external error, arguments: [Set Priority Failed], [VKTM] (Doc ID 2931494.1), которая, как по мне, ведёт в тупик(если конечно у вас на $ORACLE_HOME/bin/oradism установлены верные разрешения root:oinstall 4750), особенно если у вас 19.22.

Я же просто установил cgroup_disable=cpu в grub.

vi /etc/default/grub. Добавляем cgroup_disable=cpu в секцию  GRUB_CMDLINE_LINUX.

Далее выполнить:

Для легаси BIOS: grub2-mkconfig —output=/boot/grub2/grub.cfg

Для  UEFI: grub2-mkconfig —output=/boot/efi/EFI/redhat/grub.cfg.

[root@perfdbhost ~]# grub2-mkconfig --output=/boot/grub2/grub.cfg
Generating grub configuration file ...
device-mapper: reload ioctl on osprober-linux-nvme0n4p1 (252:2) failed: Device or resource busy
Command failed.
device-mapper: reload ioctl on osprober-linux-nvme0n5p1 (252:2) failed: Device or resource busy
Command failed.
Done

Перезагружаем хост.

P.S. В дальнейшем можно убрать cgroup_disable=cpu, процессы не получают(??) ошибок Set Priority Failed.

ORA-600 [6109] «Cannot get space to grow the ITL in an EMPTY block !!». Oracle 19

Krotov KonstantinОставьте комментарий

Из серии «никогда такого не было, и вот опять». Данная ошибка по сути является багом и её не должно быть. Первые упоминания о исправлении данной ошибки датируются версией 7.3.3(да, да, очень старая) и заканчиваются на отметке версии 10.1.0.2. Но как бы не так, данная ошибка воспроизводится(не всегда, но достаточно часто) в 19.3 и 19.19. Стоит отметить, что ошибка нашлась при синтетических тестах.

Для воспроизведения ошибки, нужно:

create table t1(
id varchar2(4000));
alter table t1 add constraint idpk primary key(id);
create sequence t1seq cache 5000;

Сам тест:

Запустить 5-10 конкурентных сессий, без использования PL/SQL, используя только sql:

next_val_seq_id_bind=t1seq.nextval||rpad(‘X’,3980,’R’)

insert into t1 values(:next_val_seq_id_bind);
commit;
delete from t1 where t1.id= :next_val_seq_id_bind;
commit;

Сам тест, является неким граничным/частным случаем, когда на один блок, приходится одна строка.

SR я завёл.

ORA-02376: invalid or redundant resource

Krotov KonstantinОставьте комментарий

If you have made export using FULL=y CONTENT=metadata_only from 19.3 db version, it is unable to import dump in 19.9 the cause of an error is ORA-02376: invalid or redundant resource.

If you search ORA-02376 on MOS you can find «DataPump Import Fails With Duplicated Resources In The Create Profile Statement (Doc ID 557383.1)», but this is not our case. The root of the problem is user profile which has PASSWORD_ROLLOVER_TIME option introduced from 19.12 according to Gradual Database Password Rollover. Creating profile with PASSWORD_ROLLOVER_TIME option produces an error ORA-02376 on db version lower than 19.12. I tested only 19.9. Export from 19.12 version and higher with parameter version=19.9, or 19.0, or 12.0 didn’t help.

You must skip profile from export and make it manually.

Tuxedo. xaorecover: xaofetch rtn -3

Krotov KonstantinОставьте комментарий

Short note.

In wery rare cases when Tuxedo server was starting you can get error ‘xaorecover: xaofetch rtn -3’.

Solution: Clear old XA transactions:

select 'rollback force '''||local_tran_id||''' ;' from dba_2pc_pending ;
select 'exec dbms_transaction.purge_lost_db_entry('''||local_tran_id||''' )' , 'commit;' from dba_2pc_pending ;

Manually Resolving In-Doubt Transactions: Different Scenarios (Doc ID 126069.1)

Tuxedo xaorecover: xaofetch rtn -3

Krotov KonstantinОставьте комментарий

Коротенькая заметка.

При старте сервера приложения Tuxedo получаем ошибку:

ORACLE XA: Version 19.0.0.0.0. RM name = 'Oracle_XA'.
 160307.273415.2676717376.0:
ORA-01405: fetched column value is NULL
  
160307.273415.2676717376.0:
xaorecover: xaofetch rtn -3.

Для решения проблемы нужно зачистить dba_2pc_pending :

select 'rollback force '''||local_tran_id||''' ;' from dba_2pc_pending ;
select 'exec dbms_transaction.purge_lost_db_entry('''||local_tran_id||''' )' , 'commit;' from dba_2pc_pending ;

Manually Resolving In-Doubt Transactions: Different Scenarios (Doc ID 126069.1)

Export из 19.13, Import в 19.9.  ORA-02376: invalid or redundant resource

Krotov KonstantinОставьте комментарий

Сделав экcпорт FULL=y CONTENT=metadata_only из бд 19.13, не получается залить дамп в 19.9 по причине ORA-02376: invalid or redundant resource.

На MOS по ошибке ORA-02376 есть нота,  DataPump Import Fails With Duplicated Resources In The Create Profile Statement (Doc ID 557383.1), но она не про этот случай.

Корень проблемы в том, что с 19.12 в профиле для пользователей появилась опция PASSWORD_ROLLOVER_TIME в рамках  Gradual Database Password Rollover.

При попытке провести импорт дампа, снятого из 19.12 и выше, в бд версии 19.11 и ниже (я проверил только 19.9) создание профиля ломается на ошибке ORA-02376, а далее не создаются пользователи и т.д.

Создать вручную профиль с опцией PASSWORD_ROLLOVER_TIME в 19.9 тоже не получится, эта версия просто не знает про такие опции.

Экспорт с параметром version=19.9, или 19.0 или 12.0 проблему не решает… Переносим профиля отдельно, и заливаем дамп.

“Это же экcпорт/импорт, что может пойти не так?” ©

XDB SGA reset to NULL, ORA-00600: qmtb_init_len

Krotov KonstantinОставьте комментарий

Oracle: 12.1.0.2.190716 BP

OS: Sparc Solaris 11.4

После старта бд и подключения приложения в алерт логе появляются ошибки:

XDB SGA reset to NULL.

ORA-00600: internal error code, arguments: [qmtb_init_len], [277], [276]

А сессии приложения находятся в ожидании XDB SGA initialization.

Если поискать на MOS по этим входным данным, то все они сводятся к выставлению переменной окружения LD_LIBRARY_PATH / LIBPATH / SHLIB_PATH(в зависимости от платформы), либо, идёт указание на то, что компонент XDB повреждён, в следствии апгрейда либо ещё чего, и нужно его переставить/исправить.

Но в данном случае все выше перечисленные решения на MOS не рабочие.

Ларчик открывается легко, просто нужно подождать, 5-10мин после входа первой сессии от приложения, после чего в алертлоге фиксируется:

XDB installed.

XDB initialized.

после чего ошибка не повторяется.

Данное долгое инициализирование XDB замечено только на Solaris.

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

Krotov KonstantinОставьте комментарий

Разобрали недавно с коллегой странный случай: при обращении к сайту, который работает по 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, вызов начал работать как и ожидалось.