If the rman restore process has stopped due to an error, how can you continue the restore from the point of interruption without starting from the beginning?

This note is aimed at saving time on manual calculation of missing files that need to be restored and avoiding the need to restart the restore process from scratch.

The scenario involves initiating a database restore using RMAN (RESTORE DATABASE), and after some time, encountering an error:

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

ORA-19870: error while restoring backup piece 856802_vg1qa4qf_1_1

ORA-19504: failed to create file "+DATA"

ORA-17502: ksfdcre:4 Failed to create file +DATA

ORA-15041: diskgroup "DATA" space exhausted

And basically… after resolving the ORA-15041 issue, we have two options: either start the restore process from scratch (over 40TB), or manually determine what has already been restored (around 1800 files) and only recover the necessary ones (~120 files), constructing a new RMAN script based on the information mentioned above.

However, there is a script available that can be used:

Option 1:

select q'!set newname for DATAFILE !'||datafiled||q'! to '+ASMDG';!' from (
select 
dcopy.file# fcopy,d.file# datafiled 
from 
(
select file# from v$datafile_copy c where c.name is not null
order by c.file#) dcopy right join v$datafile d on dcopy.file#=d.file#)
where fcopy is null
union all
select q'!restore datafile !'||dfiled||q'!;!' from (select 
dcopy.file# fcopy,d.file# dfiled 
from 
(
select file# from v$datafile_copy c where c.name is not null
order by c.file#) dcopy right join v$datafile d on dcopy.file#=d.file#)
where fcopy is null

Option 2(In the last line of the output result, you need to replace the comma with a semicolon):

select q'!set newname for DATAFILE !'||datafiled||q'! to '+ASMDG';!' from (
select 
dcopy.file# fcopy,d.file# datafiled 
from 
(
select file# from v$datafile c where c.bytes=0 
order by c.file#) dcopy left join v$datafile d on dcopy.file#=d.file#)
union all
select q'!restore datafile !' from dual
union all
select dfiled||q'!,!' from (select 
dcopy.file# fcopy,d.file# dfiled 
from 
(
select file# from v$datafile c where c.bytes=0
order by c.file#) dcopy left join v$datafile d on dcopy.file#=d.file#)

Both scripts generate «set newname for DATAFILE» and «restore datafile» commands for each data file that needs to be restored. We wrap the script’s output in a «run» block and execute it. After all the files are restored, we perform a «switch database to copy» and continue with the recovery process.

However, it should be noted that under certain circumstances, the script may not work correctly(Especially option 1). For example, on a normally functioning database in open mode, the script’s output may not match reality because there may be no entries in v$datafile_copy, or conversely, there may be many entries in v$datafile_copy, and both scenarios are normal.

Therefore, to avoid causing any issues with the database, please proceed with caution.

Если rman restore остановился по причине какой-то ошибки, как продолжить восстановление с места остановки, не начиная всё сначала?

Данная заметка направлена на то, чтобы сэкономит время на ручное вычисление недостающих файлов, которые нужно восстановить и исключить повторный запуск восстановления с нуля.

Сценарий, запускаем восстановление бд через rman(restore database) и, через какое-то время получаем ошибку:

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

ORA-19870: error while restoring backup piece 856802_vg1qa4qf_1_1

ORA-19504: failed to create file "+DATA"

ORA-17502: ksfdcre:4 Failed to create file +DATA

ORA-15041: diskgroup "DATA" space exhausted

И как бы всё… решив проблему с ORA-15041, нужно либо начинать рестор по новой(овер 40ТБ), либо вычислять вручную или ещё как-то, что было восстановлено(~1800 файлов) и долить только нужное(~120 файлов), сконструировав на вышеизложенное новый rman скрипт.

Но можно воспользоваться скриптами:

Вариант 1:

select q'!set newname for DATAFILE !'||datafiled||q'! to '+ASMDG';!' from (
select 
dcopy.file# fcopy,d.file# datafiled 
from 
(
select file# from v$datafile_copy c where c.name is not null
order by c.file#) dcopy right join v$datafile d on dcopy.file#=d.file#)
where fcopy is null
union all
select q'!restore datafile !'||dfiled||q'!;!' from (select 
dcopy.file# fcopy,d.file# dfiled 
from 
(
select file# from v$datafile_copy c where c.name is not null
order by c.file#) dcopy right join v$datafile d on dcopy.file#=d.file#)
where fcopy is null

Вариант 2(в последней строчке вывода результата, нужно заменить запятую на точку с запятой):

select q'!set newname for DATAFILE !'||datafiled||q'! to '+ASMDG';!' from (
select 
dcopy.file# fcopy,d.file# datafiled 
from 
(
select file# from v$datafile c where c.bytes=0 
order by c.file#) dcopy left join v$datafile d on dcopy.file#=d.file#)
union all
select q'!restore datafile !' from dual
union all
select dfiled||q'!,!' from (select 
dcopy.file# fcopy,d.file# dfiled 
from 
(
select file# from v$datafile c where c.bytes=0
order by c.file#) dcopy left join v$datafile d on dcopy.file#=d.file#)

Оба скрипта формируют “set newname for DATAFILE” и “ restore datafile” для каждого файла данных, который нужно восстановить. Оборачиваем вывод скрипта в run блок и запускаем, после того как все файлы восстановлены(restore), выполняем switch database to copy, и продолжаем recover.

Следует, однако, заметить, что, при определённых обстоятельствах, скрипт(особенно вариант 1) будет работать не верно, например на нормально работающей бд в режиме open, вывод скрипта не будет совпадать с реальностью, т.к. в v$datafile_copy может не быть записей, а может быть и наоборот (много записей в v$datafile_copy) и это нормально.

Поэтому, дабы не завалить бд, будьте аккуратны. 

Log file sync switching to post/wait

Версия: Oracle 19.9

В данной заметке показано наглядно, как может выглядеть переход lgwr от poll->post к режиму post/wait.

Смотрим в трейс файл процесса lgwr, находим там:

*** 2023-02-16T12:45:09.010167+06:00

Log file sync switching to post/wait

Current approximate redo synch write rate is 10286 per sec

Идём в графану и смотрим визуализацию этого события:

Рис1.

Рис2.

На рисунке 1 показано, что переход lgwr от poll->post к режиму post/wait привёл к увеличению ожидания log file sync в 2 раза, с 250мксек до 500мксек, также, увеличилось количество записи редо блоком в 128KB в два раза. На графики этого не видно, но также имеется снижение количества записи редо блоком гораздо меньшим чем 128KB(4,8,16,32KB etc).

На рисунке 2 показано, как изменилось количество ожиданий log file parallel write(oracledb_event_p3_log_file_parallel_write_p2). Количество ожиданий уменьшилось в два раза, в тоже время длительность одного ожидания log file parallel write(oracledb_event_p2_log_file_parallel_write_p2) увеличилось, в среднем на 50%, с 50мксек до 75мксек.

Выглядит как какой-то челночный режим, выполнить меньше операций большим размером блока, что даёт снижение отклика в 2 раза. Данное поведение меняется согласно алгоритму и параметрам базы данных связанных с адаптивной работы LGWR.

Подробнее можно почитать тут:

  1. Adaptive Switching Between Log Write Methods can Cause ‘log file sync’ Waits (Doc ID 1462942.1)
  2. ADAPTIVE LOG FILE SYNC: ORACLE, PLEASE DON’T DO THAT AGAIN

Собственно, решение такое: ALTER SYSTEM SET «_use_adaptive_log_file_sync» = FALSE;

ORA-02376: invalid or redundant resource

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

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

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

При старте сервера приложения 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

Сделав эк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порт/импорт, что может пойти не так?” ©

Фрагментация таблиц в бд Oracle 12c, которой нет в 19с. Часть 1.

Окружение:

OS: OEL 7.8

DB: 12.1.0.2.190716 BP,  2. 19.7.0.0.200414 RU

При выполнений пакетных заданий и не только было замечено интересное — фрагментация таблиц, где казалось бы её не должно быть(или должно?).

Для проверки влияния был составлен тест из 3 циклов:

 1 цикл — главный.

2 цикл находится внутри цикла 1, выполняет вставку.

3 цикл находится внутри цикла 1, выполняет удаление.

Количество проходов циклов 2 и 3 одинаково и задаётся при старте, циклы выполняются друг за другом, commit выполняется после каждой удалённой или вставленной строки.

Тест проводится с участим трёх таблиц(KKS$FRAG_512B, KKS$FRAG_1024B, KKS$FRAG_2048B), в которых длина вставляемой строки заранее известна, это 512байт, 1024байт и 2048байта. Размер сегмента берётся из dba_segments.

Исходный код теста

Для таблиц KKS$FRAG_512B, KKS$FRAG_1024B, KKS$FRAG_2048B было выполнено:

Количество цикловКоличество операций вставок и удалений в каждом цикле
3032003
6061006
606706
606506
606106
Таб.1
  1. Результат для KKS$FRAG_512B:
12.1.0.2.190716 BP, занято байт в таблице KKS$FRAG_512B33554432
12.1.0.2.190716 BP, занято блоков в таблице KKS$FRAG_512B4096
19.7.0.0.200414 RU, занято байт в таблице KKS$FRAG_512B7340032
19.7.0.0.200414 RU, занято блоков в таблице KKS$FRAG_512B896
Таб.2 KKS$FRAG_512B

Различие в размере сегмента составляет 4,5 раза.

2. Результат для KKS$FRAG_1024B:

12.1.0.2.190716 BP, занято байт в таблице KKS$FRAG_1024B33554432
12.1.0.2.190716 BP, занято блоков в таблице KKS$FRAG_1024B4096
19.7.0.0.200414 RU, занято байт в таблице KKS$FRAG_1024B9437184
19.7.0.0.200414 RU, занято блоков в таблице KKS$FRAG_1024B1152
Таб.3 KKS$FRAG_1024B

Отличие скромнее, но оно по прежнему существенно — в 3,5 раза.

3. Результат для KKS$FRAG_2048B:

12.1.0.2.190716 BP, занято байт в таблице KKS$FRAG_2048B19922944
12.1.0.2.190716 BP, занято блоков в таблице KKS$FRAG_2048B2432
19.7.0.0.200414 RU, занято байт в таблице KKS$FRAG_2048B16777216
19.7.0.0.200414 RU, занято блоков в таблице KKS$FRAG_2048B2048
Таб.4 KKS$FRAG_2048B

Разница не велика, но она есть: 1,18 раза

4. Другой профиль нагрузки для KKS$FRAG_512B.

Количество цикловКоличество операций вставок и удалений в каждом цикле
20021002
Таб.5 KKS$FRAG_512B
12.1.0.2.190716 BP, занято байт в таблице KKS$FRAG_512B46137344
12.1.0.2.190716 BP, занято блоков в таблице KKS$FRAG_512B5632
19.7.0.0.200414 RU, занято байт в таблице KKS$FRAG_512B720896
19.7.0.0.200414 RU, занято блоков в таблице KKS$FRAG_512B88
Таб.6 KKS$FRAG_2048B

Разница: в 64 раза

5. Другой профиль нагрузки для KKS$FRAG_1024B.

Количество цикловКоличество операций вставок и удалений в каждом цикле
20021002
Таб.7 KKS$FRAG_1024B

Результат:

12.1.0.2.190716 BP, занято байт в таблице KKS$FRAG_1024B262144
12.1.0.2.190716 BP, занято блоков в таблице KKS$FRAG_1024B32
19.7.0.0.200414 RU, занято байт в таблице KKS$FRAG_1024B196608
19.7.0.0.200414 RU, занято блоков в таблице KKS$FRAG_1024B24
Таб.6 KKS$FRAG_1024B

Разница: в 1.3 раза

Исходя из результатов тестов можно сделать вывод: при переходе на версию 19с, рост бд возможно замедлиться при одинаковой нагрузке. Самое время понять, что приводит к такому различию размеров таблиц.

XDB SGA reset to NULL, ORA-00600: qmtb_init_len

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.

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