GoldenGate: как создать GG VIP и GG Agent

Для отказоустойчивости работы GG, особенно в кластерной среде, рекомендуется использовать GoldenGate Agent. В данной статье я покажу, как его создать и настроить.
Описание параметров команд приведено в GoldenGate: List of parameters.
Под grid необходимо определить список сетей:

$ <GRID_HOME>/bin/crsctl stat res -p |grep -ie .network -ie subnet |grep -ie name -ie subnet
Пример вывода:
NAME=ora.net1.network
USR_ORA_SUBNET=X.X.X.0
NAME=ora.net2.network
USR_ORA_SUBNET=X.X.X.0

Т.к. может быть несколько сетей, то администратор должен выбрать правильную сеть для интерфейсов GG VIP и GG Agent. В документации сказано: There may be multiple networks defined in the cluster and it is at the discretion of the Oracle Clusterware Administrator and the Oracle GoldenGate Administrator to choose the correct network based on the required interface and subnet.
Под root создается GG VIP

|# <GRID_HOME>/bin/appvipcfg create -network=<NETWORK_NUMBER> \
 -ip=<VIP_IP> \
 -vipname=<GGATEVIP> \
 -user=oracle
<NETWORK_NUMBER> - определен на основании предыдущей команды.

Проверить, что GG VIP появился в разделе Cluster Resources

|# <GRID_HOME>/bin/crsctl status resource -t | more
Пример вывода:
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ggatevip      1        OFFLINE OFFLINE

Выдать права для запуска под oracle и настроить автозапуск

|#<GRID_HOME>/bin/crsctl setperm resource <GGATEVIP> -u user:oracle:r-x
|#<GRID_HOME>/bin/crsctl modify resource <GGATEVIP> -attr "AUTO_START=always"

Под пользователем oracle запустить GG VIP

$<GRID_HOME>/bin/crsctl start resource <GGATEVIP>

И проверить, что статус online

$<GRID_HOME>/bin/crsctl status resource <GGATEVIP>
Пример вывода:
NAME=ggatevip
TYPE=app.appvip_net1.type
TARGET=ONLINE
STATE=ONLINE on xen-devgg-src2

Создание GG Agent необходимо производить под пользователем oracle.

$<XAG_HOME>/bin/agctl add goldengate <GGATE_XAG_XO> \
--gg_home <GG_HOME> \
--instance_type source \
--nodes <NODE_LIST> \
--vip_name <GGATEVIP> \
--filesystems ora.asm \
--databases ora.<SRC_DB_UNIQUE_NAME>.db \
--oracle_home <ORACLE_HOME> \
--monitor_extracts <XO>

Более подробно описание параметров создания GG Agent приведено в разделе GoldenGate Agent AGCTL Syntax  документации http://www.oracle.com/technetwork/products/clusterware/overview/ogiba-reference-guide-v1-1844341.html .
Проверку статуса GG Agent производится командой:

$ <XAG_HOME>/bin/agctl status goldengate <GGATE_XAG_XO>

Под grid нужно настроить автозапуск GG Agent

$ <GRID_HOME>/bin/crsctl modify resource xag.<GGATE_XAG_XO>.goldengate -attr "AUTO_START=always"

Агент готов к работе.

Форматирование в Logdump

Кто работал с logdump, знает сколько команд необходимо выполнить, что получить удобное форматирование при просмотре trail-файлов. Можно поступить проще.
Необходимо создать файл logdump.frm в каталоге установки GoldenGate:

$ cd <GG_HOME> 
$ vim logdump.frm 

И вставить код:

FILEHEADER DETAIL 
GHDR ON 
DETAIL ON 
USERTOKEN DETAIL 
GGSTOKEN DETAIL 
RECLEN 128 
POS 0 

Открываете нужный вам файл и используйте команду obey:

Logdump 29 >open ./dirdat/xo000438 
Logdump 30 >obey logdump.frm

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) 

Копирование файлов между 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'