Тонкость в использовании DBMS_PARALLEL_EXECUTE.RUN_TASK

При использовании DBMS_PARALLEL_EXECUTE выяснилось, что DBMS_PARALLEL_EXECUTE.RUN_TASK не всегда запускает необходимое кол-во параллельных процессов.
Код запуска параллельных процессов:

DBMS_PARALLEL_EXECUTE.CREATE_CHUNKS_BY_SQL
( task_name   => 'TASK_PJOB',
sql_stmt    => 'SELECT level start_id, level end_id FROM dual connect by level <= '||v_count_string,
by_rowid    => FALSE
);

DBMS_PARALLEL_EXECUTE.RUN_TASK
( task_name      => 'TASK_PJOB',
sql_stmt       => 'BEGIN PKG_PJOB.P_PJOB(:start_id, :end_id); END;',
language_flag  => DBMS_SQL.NATIVE,
parallel_level => v_parallel_level
);

При использования данного примера, первоначально переменная v_count_string была равна v_parallel_level.
При реальной эксплуатации на 3-x нодовом кластере с 48 ядрами, в среднем запускалось в параллельном режиме 12-14 процессов из 20 плановых, остальные запускались по мере окончания работы запущенных при старте. Но такой вариант работы не подходит, т.к. получаем псевдо-параллельное выполнение задач.
При использовании процедуры DBMS_PARALLEL_EXECUTE.CREATE_CHUNKS_BY_ROWID данной проблемы не наблюдается, но она не всегда удобна в использовании.

В ходе тестирования выяснилось, что если  переменная v_parallel_level (100) больше v_count_string (20) в 5 раз, то всегда запускается 20 параллельных процессов.

Поэтому при использовании DBMS_PARALLEL_EXECUTE.CREATE_CHUNKS_BY_SQL об этом эффекте нужно помнить.

Проверялось на Oracle 11.2.0.4.0.

Delete archive logs from a source DB

После запуска процесса репликации GoldenGate, обязательно возникнет инфраструктурная задача по очистке архивлогов на источнике.

Необходимо выполнить два пункта:

1. Согласно документации https://docs.oracle.com/cd/E11882_01/server.112/e17069/strms_adcapture.htm#i1010653 необходимо уменьшить значение параметра CHECKPOINT_RETENTION_TIME, т.к. значение по умолчанию слишком велико.

$ sqlplus '/ as sysdba'
sql> BEGIN
  DBMS_CAPTURE_ADM.ALTER_CAPTURE(
    capture_name              => 'OGG$CAP_EXTO',
    checkpoint_retention_time => );
END;
/
sql> select T.CHECKPOINT_RETENTION_TIME from DBA_CAPTURE t where capture_name = 'OGG$CAP_EXTO';

где EXTO - имя экстрактора.

2. Для уменьшения вероятности возникновения ошибок при работе rman

rman-08137: warning: archived log not deleted, needed for standby or upstream capture process

необходимо увеличить частоту обновления поля min_required_capture_change# представления v$database.

Данное поле обновляется раз в 6 часов, что очень много при нормальной работе экстракторов. Поэтому складывается ситуация когда значение поля required_checkpoint_scn представления dba_capture оказывается намного больше, и архивлоги обработанные экстрактором не могут быть удалены rman.

Согласно документации Doc ID 1581365.1 пункт Updates to V$DATABASE.MIN_REQUIRED_CAPTURE_CHANGE#

в param-файле экстрактора EXTO после строки USERID (DBLOGIN)

нужно выставить значение переменной _CKPT_RETENTION_CHECK_FREQ, например 3 часа:

TRANLOGOPTIONS INTEGRATEDPARAMS(_CKPT_RETENTION_CHECK_FREQ 10800)

После запуска экстрактора в представлениях переменных CAPTURE-процессов можно наблюдать значение _CKPT_RETENTION_CHECK_FREQ:

/* All Capture parameters */

select * from DBA_CAPTURE_PARAMETERS order by CAPTURE_NAME, PARAMETER;

/* Non-Default Capture parameters */

select * from DBA_CAPTURE_PARAMETERS where SET_BY_USER='YES' order by CAPTURE_NAME, PARAMETER;

Слишком часто V$DATABASE.MIN_REQUIRED_CAPTURE_CHANGE# обновлять не стоит, т.к. в момент обновления все процессы переходят в ожидание.

Update.

От последствий разворачивания Downstream-репликации Goldengate на источнике остался LOG_ARCHIVE_DEST_3 (в тестовых средах LOG_ARCHIVE_DEST может остаться от standby). 

3. Необходимо удостовериться, что на источнике отключены дополнительные/неактивные LOG_ARCHIVE_DEST
Для подобных LOG_ARCHIVE_DEST нужно выполнить команду:

$ sqlplus '/ as sysdba'
sql> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_3='defer';

4. В случае, если отключение LOG_ARCHIVE_DEST не поможет в решение проблемы rman-08137: warning: archived log not deleted, needed for standby or upstream capture process, необходимо воспользоваться рекомендацией из Doc ID 1380368.1.

$ sqlplus '/ as sysdba'
sql> alter system set "_deferred_log_dest_is_valid" = FALSE scope=both;

Определение параметра _deferred_log_dest_is_valid: 

$ sqlplus '/ as sysdba'
sql> select ksppinm, ksppdesc  from x$ksppi where ksppinm = '_deferred_log_dest_is_valid'; 
KSPPINM                                  KSPPDESC 
----------------------------------      -------------------------------------------------------------------------------------- 
_deferred_log_dest_is_valid             consider deferred log dest as valid for log deletion (TRUE/FALSE) 

ASMCMD - курьезы

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

ASMCMD [+data/rdbdevgg/archivelog/2015_04_30] > ls -l
Type        Redund  Striped  Time             Sys  Name
ARCHIVELOG  UNPROT  COARSE   APR 30 14:00:00  Y    thread_1_seq_22894.2939.878394477
ARCHIVELOG  UNPROT  COARSE   APR 30 14:00:00  Y    thread_1_seq_22895.4085.878394517
ARCHIVELOG  UNPROT  COARSE   APR 30 14:00:00  Y    thread_1_seq_22896.2938.878394563
ARCHIVELOG  UNPROT  COARSE   APR 30 14:00:00  Y    thread_1_seq_22897.3314.878394599
ASMCMD [+data/rdbdevgg/archivelog/2015_04_30] > rm thread_1_seq_22894.2939.878394477
....
ASMCMD [+data/rdbdevgg/archivelog/2015_04_30] > rm thread_1_seq_22897.3314.878394599
ASMCMD [+data/rdbdevgg/archivelog/2015_04_30] > ls -l
ASMCMD-8002: entry '2015_04_30' does not exist in directory '+data/rdbdevgg/archivelog/'
ASMCMD [+data/rdbdevgg/archivelog/2015_04_30] > cd ..
ASMCMD-8002: entry '2015_04_30' does not exist in directory '+data/rdbdevgg/archivelog/'
ASMCMD [+data/rdbdevgg/archivelog/2015_04_30] > pwd
+data/rdbdevgg/archivelog/2015_04_30
ASMCMD [+data/rdbdevgg/archivelog/2015_04_30] > cd +data/rdbdevgg/archivelog/

Вышел на уровень выше.

Копирование файлов между ASM инстансами

При работе с GoldenGate в режиме Downstream возникла необходимость в копировании archivelog между двумя инстансами ASM.
На source ASM нужно выполнить команду:

ASMCMD [+] >cp +DATA/arm4dev/ARCHIVELOG/2014_09_30/thread_1_seq_5689.451.859666035  sys@dev-rdb.+ASM:+data/DEV_RDB/archivelog/2014_09_30/thread_1_seq_5689.451

Где:
dev-rdb - host dest-сервера БД из файла /etc/hosts
+ASM - имя ASM-инстанса на dest-сервере БД
+data/DEV_RDB/archivelog/2014_09_30/thread_1_seq_5689.451 - путь и имя файла, суффикс incarnation необходимо стирать.

На dest ASM файлы копируются в каталог +DATA/ASM/ARCHIVELOG/
Т.е., если выполнить команду в каталоге с именем дня когда выполняется копирование:

ASMCMD [+data/dev_rdb/ARCHIVELOG/2014_10_03] > ls -ls
Type        Redund  Striped  Time             Sys  Block_Size  Blocks      Bytes      Space  Name
ARCHIVELOG  UNPROT  COARSE   OCT 03 11:00:00  Y           512  471565  241441280  243269632  none => thread_2_seq_8340.601.859982211
ARCHIVELOG  UNPROT  COARSE   OCT 03 13:00:00  Y           512  353388  180934656  182452224  none => thread_2_seq_8347.577.859984811
N                                              thread_2_seq_8348.521 => +DATA/ASM/ARCHIVELOG/thread_2_seq_8348.521.355.859988579

то можно увидеть ссылку на истинное положение файла.

Затем этот скопированный файл, можно зарегистрировать для экстрактора на dest БД:

SQL> alter database register or replace logical logfile '+DATA/ASM/ARCHIVELOG/thread_1_seq_5689.451.454.859914049' FOR 'OGG$CAP_XO'