oracle goldengate 12coraclegis.com/blog/wp-content/uploads/2015/01/handson_v2.pdf · 4....

ORACLE

GOLDENGATE 12C

HANDS ON WORKSHOP

ОГЛАВЛЕНИЕ

Оглавление

Ссылки на документацию ___________________________________________________ 1

0. Подготовка виртуальнои среды _______________________________________ 2

0. Создание схемы данных для репликации ____________________________ 3

1. Проверка базы данных ___________________________________________________ 4

2. Инсталляция GoldenGate с помощью Universal Installer _____________ 6

(Опционально) Обновляем GoldenGate до последнеи версии с

помощью OPatch _____________________________________________________________ 13

3. Подготовка источника базы данных Oracle для репликации _____ 15

4. Подготовка приемника базы данных Oracle для репликации _____ 16

4. Отчетная база данных ___________________________________________________ 17

5. Анализ и оптимизация производительности GoldenGate __________ 28

6. Настраиваем дополнительныи источник MySQL ____________________ 37

7. Настраиваем GoldenGate Director _______________________________________ 42

Настрои ка сверки данных с помощью Veridata _________________________ 46

ССЫЛКИ НА ДОКУМЕНТАЦИЮ

Страница 1

Ссылки на документацию

1. Сборник документации по GoldenGate 12c:

http://docs.oracle.com/goldengate/1212/gg-winux/docs.htm

2. Справочник по параметрам GoldenGate 12c

3. Руководство администратора GoldenGate 12c (общее)

4. Руководство администратора GoldenGate 12c для for Oracle Database

5. Руководство администратора GoldenGate 12c для for MSSQL

6. Руководство администратора GoldenGate 12c для for MySQL

http://docs.oracle.com/goldengate/1212/gg-winux/docs.htm

http://docs.oracle.com/goldengate/1212/gg-winux/GWURF/index.html

http://docs.oracle.com/goldengate/1212/gg-winux/GWUAD/index.html

http://docs.oracle.com/goldengate/1212/gg-winux/GIORA/index.html

http://docs.oracle.com/goldengate/1212/gg-winux/GIMYS/index.html

ПОДГОТОВКА ВИРТУАЛЬНОЙ СРЕДЫ

Страница 2

0. Подготовка виртуальнои среды

Виртуальная среда для проведения лабораторнои работы состоит из 3 серверов:

1. Сервер gg1ora – источник для репликации

2. Сервер gg2ora – приемник для репликации

3. Сервер gg3fmw – вспомогательные компоненты такие как нагрузочные скрипты,

репозитории GoldenGate Director, Veridata и Monitor.

orcl1

orcl2

eth0: 192.168.43.128 eth1: gg1ora, 192.168.154.50

eth0: 192.168.43.128 eth1: gg2ora, 192.168.154.51

eth0: 192.168.43.128 eth1: gg3fmw, 192.168.154.52 eth2: динамическии адрес

Director Director Monitor

mysql

СОЗДАНИЕ СХЕМЫ ДАННЫХ ДЛЯ РЕПЛИКАЦИИ

Страница 3

0. Создание схемы данных для репликации

cd ~/GG_LAB_NEW1/Oracle2OracleClassic/0.CreateSchema/

sqlplus "sys/oracle@gg1:1521/orcl1 as sysdba" @demo_ora_create

sqlplus "sys/oracle@gg1:1521/orcl1 as sysdba" @demo_ora_insert

[oracle@gg3 0.CreateSchema]$ cd ~/GG_LAB_NEW1/Oracle2OracleClassic/0.CreateSchema/

[oracle@gg3 0.CreateSchema]$ sqlplus "sys/oracle@gg1:1521/orcl1 as sysdba"

@demo_ora_create

SQL*Plus: Release 12.1.0.2.0 Production on Sun Jan 25 19:34:12 2015

Copyright (c) 1982, 2014, Oracle. All rights reserved.

Connected to:

Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production

With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options

User dropped.

User created.

User altered.

Grant succeeded.

Grant succeeded.

Table created.

Table created.

Sequence created.

Sequence created.

SQL>

1. ПРОВЕРКА БАЗЫ ДАННЫХ

Страница 4

1. Проверка базы данных

Прежде чем приступать к настрои ке репликации необходимо осуществить

проверку базы данных с точки зрения потенциальных проблем: отсутствие

первичного ключа, неподдерживаемые типы данных, сжатие и т.д. Набор

поддерживаемых и неподдерживаемых возможностеи разныи для разных типов

процессов Extract. Ниже в таблице приведена краткая сводка:

Способ проверки зависит от того какои планируется использовать режим Extract

(Classic или Integrated).

Classic Extract

Если планируется использовать классическии Extract, то для целеи проверки

используются скрипты, доступные на support.oracle.com – наи ти их можно по

словам “goldengate profile”. Например, скрипт для проверки планируемои к

репликации схемы Oracle доступен в ноте Oracle GoldenGate database Schema Profile

check script for Oracle DB (Doc ID 1296168.1).

Для лабораторнои работы этот скрипт загружен в каталог:

/home/oracle/GG_LAB_NEW1/Oracle2OracleClassic/1.CheckSchema/full-

schemaCheckOracle_11032014.sql

Запустим этот скрипт под пользователем обладающим правами DBA:

[oracle@gg3 0.CheckSchema]$ cd ~/GG_LAB_NEW1/Oracle2OracleClassic/1.CheckSchema/

[oracle@gg3 0.CheckSchema]$ sqlplus "sys/oracle@gg1:1521/orcl1 as sysdba" @full-

schemaCheckOracle_11032014.sql

Enter the Schema Name > ggtest

При запуске скрипт запросит схему пользователя, в которои хранятся

реплицируемые таблицы (я ввел ggtest). Результирующии отчет будет состоять

из трех частеи :

1. Общая информация: версия СУБД, включено ли минимальное

журналирование, архивирование журналов, производится ли форсирование

журналирования, количество объектов различных типов, типы данных

2. Потенциально проблемные таблицы

1. ПРОВЕРКА БАЗЫ ДАННЫХ

Страница 5

3. Нагрузка на базу данных по дня и часам: размер журнала, количество

переключении журнала по часам, объем сгенерированных журналов под

часа и дням.

Ответьте на вопросы:

1. Какие таблицы не имеют первичного ключа?

2. Какие таблицы сжаты?

3. Какие таблицы содержат неподдерживаемые типы данных и какие этот типы?

4. Существуют ли триггеры?

Integrated Extract

Для интегрированного Extract для этих целеи предназначена специальная

таблица в СУБД Oracle DBA_GOLDENGATE_SUPPORT_MODE

SQL> column object_name format a20

SQL> column owner format a20

SQL> select * from DBA_GOLDENGATE_SUPPORT_MODE where OWNER='GGTEST';

OWNER OBJECT_NAME SUPPOR

-------------------- -------------------- ------

GGTEST SPATIAL_TABLE FULL

GGTEST XMLTYPE_TABLE FULL

GGTEST EMPLOYEES FULL

GGTEST BLOB_TABLE FULL

GGTEST ANYDATA_TABLE FULL

GGTEST DEPARTMENTS FULL

GGTEST UDF_TABLE ID KEY

FULL - A capture process can capture changes made to all of the columns in the

table

ID KEY - A capture process can capture changes made to the key columns and any

other columns in the table supported by the capture process, except for LOB,

LONG, LONG RAW, and XMLType columns.

NONE - A capture process cannot capture changes made to any columns in the

table.

Ответьте на вопросы:

1. Какие таблицы не полностью захватываются из журнала СУБД?

2. ИНСТАЛЛЯЦИЯ GOLDENGATE С ПОМОЩЬЮ UNIVERSAL INSTALLER

Страница 6

2. Инсталляция GoldenGate с помощью Universal Installer

Начиная с GoldenGate версии 12c инсталляция осуществляется через

стандартныи Oracle Universal Installer. Пока что такая функция доступна не для

всех платформ, но, как минимум GoldenGate for Oracle, сеи час использует OUI

У нас 2 сервера gg1 и gg2.

На сервере gg1 проинсталлирована СУБД Oracle 12.1.0.2 и MySQL Community

Edition 5.6. На сервере gg2 проинсталлирована СУБД Oracle 12.1.0.2. На gg1 мы

проинсталлируем GoldenGate 12c для СУБД Oracle 12g и MySQL Enterprise Edition.

Инсталляцию будум осуществлять в каталог

/u01/app/oracle/product/ogg$VERSION/$DATABASE$DATABASE_VERSION.

Ниже показаны пути инсталляции.

orcl1

orcl2

ogg1: /u01/app/oracle/product/ogg12.1.2.1/ora12 port 7809 ogg2: /u01/app/oracle/product/ogg12.1.2.1/mysql port 8809



mysql

ogg1: /u01/app/oracle/product/ogg12.1.2.1/ora12 port 7809


Страница 7

На gg2 будет проинсталлирован GoldenGate 12c для СУБД Oracle 12c.

cd GG_LAB_NEW1/distrib/

ssh gg1 "mkdir /home/oracle/distrib/gg1212/ora12 -p"

ssh gg2 "mkdir /home/oracle/distrib/gg1212/ora12 -p"

ssh gg1 "mkdir /home/oracle/distrib/gg1212/mysql -p"

scp gg1212/ora12/* gg1:/home/oracle/distrib/gg1212/ora12

scp gg1212/ora12/* gg2:/home/oracle/distrib/gg1212/ora12

scp gg1212/mysql/* gg1:/home/oracle/distrib/gg1212/mysql

Вывод на экране:

[oracle@gg3 ~]$ cd GG_LAB_NEW1/distrib/

[oracle@gg3 distrib]$ ssh gg1 "mkdir /home/oracle/distrib/gg1212/ora12 -p"

[oracle@gg3 distrib]$ ssh gg2 "mkdir /home/oracle/distrib/gg1212/ora12 -p"

[oracle@gg3 distrib]$ ssh gg1 "mkdir /home/oracle/distrib/gg1212/mysql -p"

[oracle@gg3 distrib]$

[oracle@gg3 distrib]$ scp gg1212/ora12/* gg1:/home/oracle/distrib/gg1212/ora12

p20282720_121210_Linux-x86-64.zip

100% 121MB 120.6MB/s 00:01

V46695-01.zip

100% 336MB 167.9MB/s 00:02

[oracle@gg3 distrib]$ scp gg1212/ora12/* gg2:/home/oracle/distrib/gg1212/ora12

p20282720_121210_Linux-x86-64.zip

100% 121MB 120.6MB/s 00:01

V46695-01.zip

100% 336MB 56.0MB/s 00:06

[oracle@gg3 distrib]$ scp gg1212/mysql/* gg1:/home/oracle/distrib/gg1212/mysql

V47367-01.zip

100% 136MB 68.0MB/s 00:02


Для инсталляции OGG для Oracle на сервере gg1 запускаем Gnome:

startx

Запускаем терминал и переходим в каталог

cd /home/oracle/distrib/gg1212/ora12

unzip V46695-01.zip

cd fbo_ggs_Linux_x64_shiphome/Disk1/

./runInstaller

После запуска открывается окно для выбора версии СУБД. Связана такая

необходимость с тем, что в одном дистрибутиве есть GoldenGate как для Oracle

11g, так и Oracle 12c.


Страница 8

1. Выбираем версию СУБД. В нашем случае версия СУБД – 12c:

2. На следующеи странице инсталлятора указываем

- каталог, в которыи будет проинсталлирован GoldenGate: /u01/app/oracle/product/ogg12.1.2.1/ora12

- местоположение $ORACLE_HOME: /u01/app/oracle/product/12.1.0/dbhome_1

- порт, на котором будет работать менеджер 7809

Обратите внимание, что GoldenGate не следует инсталлировать в домашнии

каталог СУБД Oracle.


Страница 9

3.

4. На следующеи странице просматриваем настрои ки и жмем Install.

5. Жмем кнопку Close для выхода из Universal Installer

6. Аналогично инсталлируем GoldenGate для gg2.

7. Помимо Oracle Database для демонстрации возможностеи будет

использована СУБД MySQL Community. Для этои СУБД инсталляция

производится старыми методами – обычная распаковка дистрибутива.

Для этого на сервере gg1:

cd ~/distrib/gg1212/mysql/

mkdir /u01/app/oracle/product/ogg12.1.2.1/mysql

unzip V47367-01.zip -d /u01/app/oracle/product/ogg12.1.2.1/mysql

cd /u01/app/oracle/product/ogg12.1.2.1/mysql

tar xvf ggs_Linux_x64_MySQL_64bit.tar


Страница 10

8. GoldenGate для MySQL нужно проинициализировать. Для СУБД Oracle за нас

это сделал Universal Installer. Здесь нам это нужно делать вручную. Для

инициализации выполняем следующие деи ствия:

cd /u01/app/oracle/product/ogg12.1.2.1/mysql

./ggsci

create subdirs

Ниже вывод от выполнения этих команд

[oracle@gg1 mysql]$ cd /u01/app/oracle/product/ogg12.1.2.1/mysql

[oracle@gg1 mysql]$ ./ggsci

Oracle GoldenGate Command Interpreter for MySQL

Version 12.1.2.1.0 OGGCORE_12.1.2.1.0_PLATFORMS_140920.0203

Linux, x64, 64bit (optimized), MySQL Enterprise on Sep 20 2014 03:43:22

Operating system character set identified as UTF-8.

Copyright (C) 1995, 2014, Oracle and/or its affiliates. All rights reserved.

GGSCI (gg1.localdomain) 1> create subdirs

Creating subdirectories under current directory

/u01/app/oracle/product/ogg12.1.2.1/mysql

Parameter files /u01/app/oracle/product/ogg12.1.2.1/mysql/dirprm:

already exists

Report files /u01/app/oracle/product/ogg12.1.2.1/mysql/dirrpt:

created

Checkpoint files /u01/app/oracle/product/ogg12.1.2.1/mysql/dirchk:

created

Process status files /u01/app/oracle/product/ogg12.1.2.1/mysql/dirpcs:

created

SQL script files /u01/app/oracle/product/ogg12.1.2.1/mysql/dirsql:

created

Database definitions files /u01/app/oracle/product/ogg12.1.2.1/mysql/dirdef:

created

Extract data files /u01/app/oracle/product/ogg12.1.2.1/mysql/dirdat:

created

Temporary files /u01/app/oracle/product/ogg12.1.2.1/mysql/dirtmp:

created

Credential store files /u01/app/oracle/product/ogg12.1.2.1/mysql/dircrd:

created

Masterkey wallet files /u01/app/oracle/product/ogg12.1.2.1/mysql/dirwlt:

created

Dump files /u01/app/oracle/product/ogg12.1.2.1/mysql/dirdmp:

created

GGSCI (gg1.localdomain) 2>

9. Настраиваем Manager для MySQL. Для этого вводим команду

edit params mgr

В открывшемся редакторе вводим PORT 8809


Страница 11

10. Запускаем менеджер

start mgr

info mgr

Ниже вывод от команд:

GGSCI (gg1.localdomain) 2> start mgr

Manager started.

GGSCI (gg1.localdomain) 3> info mgr

Manager is running (IP port gg1.localdomain.8809, Process ID 7486).


Итак, на данныи момент мы имеет следующую конфигурацию:

На сервере GG1 сконфигурирована база данных Oracle 12g и MySQL 5.6

orcl1

orcl2

ogg1: /u01/app/oracle/product/ogg12.1.2.1/ora12 port 7809 process list: MGR (7809) ogg2: /u01/app/oracle/product/ogg12.1.2.1/mysql port 8809 process list: MGR (8809)



mysql

ogg1: /u01/app/oracle/product/ogg12.1.2.1/ora12 port 7809 process list: MGR (7809)


Страница 12

На сервере GG2 сконфигурирована база данных Oracle 12g

На сервере GG1 запущен менеджер GoldenGate для Oracle 12g (порт 7809) и

MySQL 5.6 (порт 8809)

На сервере GG2 запущен менеджер GoldenGate для Oracle 12g (порт 7809)

(ОПЦИОНАЛЬНО) ОБНОВЛЯЕМ GOLDENGATE ДО ПОСЛЕДНЕЙ ВЕРСИИ С ПОМОЩЬЮ OPATCH

Страница 13

(Опционально) Обновляем GoldenGate до последнеи версии с помощью OPatch

Обновления GoldenGate 12c выпускаются в стандартном формате для OPatch, т.е.

установка обновления GoldenGate делается стандартными инструментами Oracle.

Патчи для каждои версии СУБД разные. Даваи те установим патч на сервере GG1

для GoldenGate 12c для СУБД Oracle 12c.

1. Переходим в каталог, куда скачан патч и распаковываем его

cd ~/distrib/gg1212/ora12/

unzip p20282720_121210_Linux-x86-64.zip

cd 20282720

2. Устанавливаем переменную ORACLE_HOME, чтобы она указывала в каталог,

куда проинсталлирован GoldenGate

export ORACLE_HOME=/u01/app/oracle/product/ogg12.1.2.1/ora12

3. Запускаем установку патча

$ORACLE_HOME/OPatch/opatch apply

Вывод команды выглядит следующим образом

Invoking OPatch 11.2.0.1.7

Oracle Interim Patch Installer version 11.2.0.1.7

Copyright (c) 2011, Oracle Corporation. All rights reserved.

Oracle Home : /u01/app/oracle/product/ogg_12.1.2/db12c

Central Inventory : /u01/app/oraInventory

from : /etc/oraInst.loc

OPatch version : 11.2.0.1.7

OUI version : 11.2.0.3.0

Log file location :

/u01/app/oracle/product/ogg_12.1.2/db12c/cfgtoollogs/opatch/opatch2014-07-24_02-29-

18AM.log

Applying interim patch '19152124' to OH '/u01/app/oracle/product/ogg_12.1.2/db12c'

Verifying environment and performing prerequisite checks...

Do you want to proceed? [y|n]

y

User Responded with: Y

All checks passed.

Please shutdown Oracle instances running out of this ORACLE_HOME on the local system.

(Oracle Home = '/u01/app/oracle/product/ogg_12.1.2/db12c')

Is the local system ready for patching? [y|n]

y

User Responded with: Y

Backing up files...

(ОПЦИОНАЛЬНО) ОБНОВЛЯЕМ GOLDENGATE ДО ПОСЛЕДНЕЙ ВЕРСИИ С ПОМОЩЬЮ OPATCH

Страница 14

Patching component oracle.oggcore.ora12c, 12.1.2.0.0...

Patch 19152124 successfully applied

Log file location:

/u01/app/oracle/product/ogg_12.1.2/db12c/cfgtoollogs/opatch/opatch2014-07-24_02-29-

18AM.log

OPatch succeeded.

[oracle@gg2day 19152124]$

4. Проверим, что патч был установлен. Для этого можно открыть фаи л

/u01/app/oracle/product/ogg_12.1.2/db12c/OGG_WinUnix_Rel_Notes_12.1.2.0.0_B

LR19007464.pdf

В этом фаи ле содержится информация о последних багах исправленных в

GoldenGate. Также можно видеть, что номер патча 19007464 в консоли ggsci.

3. ПОДГОТОВКА ИСТОЧНИКА БАЗЫ ДАННЫХ ORACLE ДЛЯ РЕПЛИКАЦИИ

Страница 15

3. Подготовка источника базы данных Oracle для репликации

Для того, чтобы GoldenGate мог корректно захватывать изменения необходимо

выполнить ряд деи ствии :

создать пользователя;

включить минимальное журналирование;

включить архивацию журналов СУБД

разрешить использование GoldenGate

работать необходимо выполнить ряд подготовительных деи ствии на СУБД

источника:

Создать выделенного пользователя для работы GoldenGate

CREATE USER GGADMIN IDENTIFIED BY oracle;

GRANT CONNECT,RESOURCE,DBA to GGADMIN;

GRANT UNLIMITED TABLESPACE TO GGADMIN;

exec dbms_goldengate_auth.grant_admin_privilege('GGADMIN');

Oracle Database 12c в режиме CDB

CREATE USER C##GGADMIN IDENTIFIED BY oracle CONTAINER=ALL;

GRANT CONNECT,RESOURCE,DBA to C##GGADMIN CONTAINER=ALL;

GRANT UNLIMITED TABLESPACE TO C##GGADMIN CONTAINER=ALL;

exec dbms_goldengate_auth.grant_admin_privilege('C##GGADMIN', container => 'ALL');

Включить minimum supplemental logging

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

Включить режим архивирования журналов

mkdir /u02/oradata/orcl1/arcs/orcl1 –p

sqlplus / as sysdba

shutdown immediate

startup mount

alter system set LOG_ARCHIVE_DEST_1='location=/u02/oradata/orcl1/arcs/orcl1'

scope=both;

alter database archivelog;

alter database open;

Разрешить репликацию с помощью GoldenGate (необходимо для 11.2.0.4+,

12.1.0.2+)

ALTER SYSTEM SET enable_goldengate_replication=true scope=both;

4. ПОДГОТОВКА ПРИЕМНИКА БАЗЫ ДАННЫХ ORACLE ДЛЯ РЕПЛИКАЦИИ

Страница 16

4. Подготовка приемника базы данных Oracle для репликации

Для корректного применения изменении на приемнике необходимо выполнить

ряд деи ствии :

создать пользователя;

разрешить использование GoldenGate

Ниже описаны эти деи ствия:

Создать выделенного пользователя для работы GoldenGate

CREATE USER GGADMIN IDENTIFIED BY oracle;

GRANT CONNECT,RESOURCE,DBA to GGADMIN;

GRANT UNLIMITED TABLESPACE TO GGADMIN;

exec dbms_goldengate_auth.grant_admin_privilege('GGADMIN');

Oracle Database 12c в режиме CDB

CREATE USER C##GGADMIN IDENTIFIED BY oracle CONTAINER=ALL;

GRANT CONNECT,RESOURCE,DBA to C##GGADMIN CONTAINER=ALL;

GRANT UNLIMITED TABLESPACE TO C##GGADMIN CONTAINER=ALL;

exec dbms_goldengate_auth.grant_admin_privilege('C##GGADMIN', container => 'ALL');

Включить minimum supplemental logging

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

Разрешить репликацию с помощью GoldenGate (необходимо для 11.2.0.4+,

12.1.0.2+)

ALTER SYSTEM SET enable_goldengate_replication=true scope=both;

4. ОТЧЕТНАЯ БАЗА ДАННЫХ

Страница 17

4. Отчетная база данных

В этои лабораторнои работе мы рассмотрим конфигурирование GoldenGate для

поддержки одностороннеи репликации из Oracle 12с в Oracle 12c.

Первоначальное создание отчетнои базы данных может выполняться как с

остановкои , так и без остановки. Мы рассмотрим безостановочныи вариант.

Для этои лабораторнои будут использована схема ggtest (Oracle 12c) как на

источнике, так и на премнике.

Первоначально будет выполнена настрои ка GoldenGate в классическом режиме.

Следующие задачи будут выполнены в рамках это лабораторнои :

Запущены процессы Manager GoldenGate.

Создан процесс Extract, читающии данные из Oracle Redo среды gg1.

Создан процесс Pump, которые будет переносить захваченные транзакции в

среду gg2

Запустим Extract на стороне gg1

Запомним текущии SCN

Экспортируем данные на этот SCN из gg1 и импортируем их в gg2

Создадим Replicat, которыи будет синхронизировать базы

Запустим Replicat, чтобы он применял данные, начиная с записанного SCN

Сгенерируем транзакции на источнике и проверим, что они корректно

передаются на приемник

Согласно best practice работа GoldenGate будет осуществляться под выделенным

пользователем (ggadmin).

ИСТОЧНИК, ORACLE 12C (КОНФИГУРАЦИЯ OGG)

1. Будущая конфигурация


Страница 18

2. Переходим в каталог GoldenGate 12c для СУБД Oracle 12g

(проинсталлирован в разделе 2)

cd /u01/app/oracle/product/ogg12.1.2.1/ora12

3. Запускаем GoldenGate и смотрим, что ни один процесс не запущен (точнее

запущен MANAGER, которыи был настроен в Universal Installer)

[oracle@gg1 ora12]$ ggsci

Oracle GoldenGate Command Interpreter for Oracle

Version 12.1.2.1.0 OGGCORE_12.1.2.1.0_PLATFORMS_140727.2135.1_FBO

Linux, x64, 64bit (optimized), Oracle 12c on Aug 7 2014 10:21:34



GGSCI (gg1.localdomain) 1> info all

Program Status Group Lag at Chkpt Time Since Chkpt

MANAGER RUNNING


4. Если менеджер не запущен, то запускаем его и проверяем его состояние

GGSCI (gg1.localdomain) 3> start mgr

Manager started.

GGSCI (gg1.localdomain) 4> info mgr

Manager is running (IP port gg1.localdomain.7809, Process ID 8483).

Oracle 12c

DB_NAME: ORCL2

Oracle 12c

DB_NAME: ORCL1

Pump LAN / WAN /

INTERNET

Capture Delivery

CAB PAB DAB ./dirdat/ta ./dirdat/tb


Страница 19

5. Для подключения к СУБД Oracle будет использоваться пользователь

ggadmin. На обеих серверах создадим эту учетную запись

create wallet

add credentialstore

ALTER CREDENTIALSTORE ADD USER ggadmin ALIAS ggadmin

dblogin useridalias ggadmin

list tables ggtest.*

6. Мы готовы к созданию процессов GoldenGate.

7. Первым делом будет создан процесс Extract CAB. Конфигурация для этого

процесса лежит в каталоге

/home/oracle/GG_LAB_NEW1/Oracle2OracleClassic/4.StartCapture

Для редактирования конфигурацию используется команда

edit params cab

После ввода этои команды мы попадаем в редактор vi (или другои

заданныи командои SET EDITOR). В редакторе вводим конфигурацию и

сохраняем ее

GGSCI (gg1day.local) 14> edit params cab

Фаи л параметров представлен ниже:

EXTRACT cab

setenv (ORACLE_SID=orcl1)

setenv (ORACLE_HOME=/u01/app/oracle/product/12.1.0/dbhome_1)

USERIDALIAS ggadmin

EXTTRAIL ./dirdat/ta

TABLE GGTEST.*;

8. Следующие команды мы запустим для создания процесса CAB

GGSCI (gg1.localdomain as ggadmin@orcl1) 8> delete cab

Deleted EXTRACT CAB.

GGSCI (gg1.localdomain as ggadmin@orcl1) 9> add extract cab, tranlog,begin now

EXTRACT added.

GGSCI (gg1.localdomain as ggadmin@orcl1) 10> ADD exttrail ./dirdat/ta, EXTRACT cab,

MEGABYTES 50

EXTTRAIL added.


Страница 20

9. Следующии шаг – создание процесса, которыи будет передавать данные,

захваченные процессом CAB на удаленныи сервер. Этот процесс (pump)

будет называть PAB. Аналогично тому, как мы добавляли Extract добавляем

Pump:

GGSCI (gg1day.local) 14> edit params pab

10. Фаи л параметров для процесса PAB представлен ниже:

EXTRACT pab

RMTHOST gg2,MGRPORT 7809

RMTTRAIL ./dirdat/tb

PASSTHRU

TABLE ggtest.*;

11. Следующие команды мы запустим для создания процесса PAB

GGSCI (gg1.localdomain as ggadmin@orcl1) 12> delete extract pab

ERROR: EXTRACT PAB does not exist.

GGSCI (gg1.localdomain as ggadmin@orcl1) 13> add extract pab, EXTTRAILSOURCE

./dirdat/ta, begin now

EXTRACT added.

GGSCI (gg1.localdomain as ggadmin@orcl1) 14> ADD RMTTRAIL ./dirdat/tb, EXTRACT pab

RMTTRAIL added.

GGSCI (gg1.localdomain as ggadmin@orcl1) 15>

12. Для корректнои работы репликации необходимо добавить

supplemental logging первичного ключа для реплицируемых таблиц.

Параллельно мы проверим, что работает наше хранилище учетных записеи

GGSCI (gg1.localdomain as ggadmin@orcl1) 15> DBLOGIN USERidALIAS ggadmin

Successfully logged into database.

GGSCI (gg1.localdomain as ggadmin@orcl1) 16> add trandata ggtest.*

Logging of supplemental redo data enabled for table GGTEST.DEPARTMENTS.

TRANDATA for scheduling columns has been added on table 'GGTEST.DEPARTMENTS'.

Logging of supplemental redo data enabled for table GGTEST.EMPLOYEES.

TRANDATA for scheduling columns has been added on table 'GGTEST.EMPLOYEES'.

Logging of supplemental redo data enabled for table GGTEST.TABLE_ANYDATA.

TRANDATA for scheduling columns has been added on table 'GGTEST.TABLE_ANYDATA'.

Logging of supplemental redo data enabled for table GGTEST.TABLE_COMPRESS.

TRANDATA for scheduling columns has been added on table 'GGTEST.TABLE_COMPRESS'.

Logging of supplemental redo data enabled for table GGTEST.TABLE_DEFERRED.

TRANDATA for scheduling columns has been added on table 'GGTEST.TABLE_DEFERRED'.

Logging of supplemental redo data enabled for table GGTEST.TABLE_INVISIBLE.

TRANDATA for scheduling columns has been added on table 'GGTEST.TABLE_INVISIBLE'.


Страница 21

2015-01-26 00:59:33 INFO OGG-06441 Unique key SYS_C0010381 for table TABLE_NESTED

cannot be used due to the inclusion of virtual columns, or user-defined datatypes, or

extended long varchar columns, or function-based index columns.

2015-01-26 00:59:33 WARNING OGG-06440 No viable unique key is defined for table

TABLE_NESTED. All viable columns will be used to represent the key, but may not

guarantee uniqueness. KEYCOLS may be used to define the key.

Logging of supplemental redo data enabled for table GGTEST.TABLE_NESTED.

TRANDATA for scheduling columns has been added on table 'GGTEST.TABLE_NESTED'.

Logging of supplemental redo data enabled for table GGTEST.TABLE_NOLOGGING.

TRANDATA for scheduling columns has been added on table 'GGTEST.TABLE_NOLOGGING'.

2015-01-26 00:59:33 WARNING OGG-06439 No unique key is defined for table TABLE_NO_PK.

All viable columns will be used to represent the key, but may not guarantee uniqueness.

KEYCOLS may be used to define the key.

Logging of supplemental redo data enabled for table GGTEST.TABLE_NO_PK.

TRANDATA for scheduling columns has been added on table 'GGTEST.TABLE_NO_PK'.

Logging of supplemental redo data enabled for table GGTEST.TABLE_SPATIAL.

TRANDATA for scheduling columns has been added on table 'GGTEST.TABLE_SPATIAL'.

Logging of supplemental redo data enabled for table GGTEST.TABLE_TRIGGER.

TRANDATA for scheduling columns has been added on table 'GGTEST.TABLE_TRIGGER'.


13. Запускаем процессы CAB и PAB, проверяем, что процессы корректно

запустились

GGSCI (gg1.localdomain) 12> start cab

Sending START request to MANAGER ...

EXTRACT CAB starting

GGSCI (gg1.localdomain) 13> start pab


EXTRACT PAB starting



MANAGER RUNNING

EXTRACT RUNNING CAB 00:04:21 00:00:03

EXTRACT RUNNING PAB 00:00:00 00:15:

14. Если какои -то процесс не запустился, то используем команду view

report ИМЯ_ПРОЦЕССА, чтобы определить причину ошибки

15. После того как процессы на источнике запущены можно приступать к

экспорту данных на источнике и импорту их на приемнике. Для этих целеи

будем использовать Data Pump (СУБД) в сетевом, консистентном режиме

16. Создаем Directory GG_INITIAL_LOAD на источнике и приемнике:

На GG1:

SQL> CREATE DIRECTORY gg_initial_load AS '/home/oracle/';


Страница 22

Directory created.

SQL> grant read, write on directory gg_initial_load to ggadmin;

Grant succeeded.

На GG2:

SQL> CREATE DIRECTORY gg_initial_load AS '/home/oracle/';

Directory created.

SQL> grant read, write on directory gg_initial_load to ggadmin ;

Grant succeeded.

17. На приемнике (GG2) создаем Database Link, через которыи будет

производиться инициализация

SQL> create public database link orcl1 connect to ggadmin

identified by oracle using 'gg1:1521/orcl1';

Database link created.

SQL>

18. Фиксируем SCN, на которыи будем экспортировать данные. Именно

этот SCN будет служить точкои синхронизации, после которои GoldenGate

начнет применять накопленные изменения. На GG2 вводим следующую

команду:

SQL> SELECT DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER FROM DUAL@ORCL1;

GET_SYSTEM_CHANGE_NUMBER

------------------------

1919378

SQL>

19. На GG2 запускаем импорт данных через созданныи сетевои database

link. Обязательно нужно подставить ваш FLASHBACK_SCN.

[oracle@gg2 ~]$ impdp ggadmin/oracle@gg2:1521/orcl2 DIRECTORY=gg_initial_load

NETWORK_LINK=orcl1 FLASHBACK_SCN=1919378 schemas=ggtest

Import: Release 12.1.0.2.0 - Production on Mon Jan 26 01:19:38 2015

Copyright (c) 1982, 2014, Oracle and/or its affiliates. All rights reserved.

Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit

Production



Страница 23

FLASHBACK automatically enabled to preserve database integrity.

Starting "GGADMIN"."SYS_IMPORT_SCHEMA_01": ggadmin/********@gg2:1521/orcl2

DIRECTORY=gg_initial_load NETWORK_LINK=orcl1 FLASHBACK_SCN=1919378 schemas=ggtest

Estimate in progress using BLOCKS method...

Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA

Total estimation using BLOCKS method: 640 KB

Processing object type SCHEMA_EXPORT/USER

Processing object type SCHEMA_EXPORT/ROLE_GRANT

Processing object type SCHEMA_EXPORT/DEFAULT_ROLE

Processing object type SCHEMA_EXPORT/TABLESPACE_QUOTA

Processing object type SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA

Processing object type SCHEMA_EXPORT/TYPE/TYPE_SPEC

Processing object type SCHEMA_EXPORT/SEQUENCE/SEQUENCE

Processing object type SCHEMA_EXPORT/TABLE/TABLE

. . imported "GGTEST"."TABLE_SPATIAL" 0 rows

. . imported "GGTEST"."TABLE_ANYDATA" 0 rows

. . imported "GGTEST"."TABLE_NESTED" 0 rows

. . imported "GGTEST"."DEPARTMENTS" 0 rows

. . imported "GGTEST"."EMPLOYEES" 0 rows

. . imported "GGTEST"."TABLE_COMPRESS" 0 rows

. . imported "GGTEST"."TABLE_DEFERRED" 0 rows

. . imported "GGTEST"."TABLE_INVISIBLE" 0 rows

. . imported "GGTEST"."TABLE_NOLOGGING" 0 rows

. . imported "GGTEST"."TABLE_NO_PK" 0 rows

. . imported "GGTEST"."TABLE_TRIGGER" 0 rows

Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX

Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT

Processing object type SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS

Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINT

Processing object type SCHEMA_EXPORT/TABLE/TRIGGER

Processing object type SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS

Processing object type SCHEMA_EXPORT/STATISTICS/MARKER

Job "GGADMIN"."SYS_IMPORT_SCHEMA_01" completed with 1 error(s) at Mon Jan 26 01:20:50

2015 elapsed 0 00:01:08

20. Данные импортированы в моем случае на SCN=1919378. Именно с

этого момента нужно будет запускать применение данных на целевои

системе.

21. Создаем фаи л GLOBALS. В этои фаи ле, в частности, прописывается

глобальная таблица checkpoint.

GGSCI (gg2.localdomain as ggadmin@orcl2) 24> edit params ./GLOBALS

Необходимо ввести настрои ку

checkpointtable ggadmin.checkpointtable

22. Перезапустим ggsci консоль.

23. Создаем процесс DAB. Этот процесс будет читать данные,

передаваемые процессом PAB, из треи л-фаи лов dirdat/tb и применять их к

базе данных ORCL2. Создать конфигурацию процесса DAB можно командои

GGSCI (gg1day.local) 14> edit params dab


Страница 24

Фаи л параметров для процесса DAB представлен ниже:

replicat da



USERIDALIAS ggadmin

discardfile ./dirrpt/da.dsc, purge

assumetargetdefs

map ggtest.*, target ggtest.*;

24. Следующие команды мы запустим для создания процесса DAB

GGSCI (gg2.localdomain) 2> dblogin useridalias ggadmin


GGSCI (gg2.localdomain as ggadmin@orcl2) 3> add checkpointtable

No checkpoint table specified. Using GLOBALS specification (ggadmin.checkpointtable)...

Successfully created checkpoint table ggadmin.checkpointtable.

GGSCI (gg2.localdomain as ggadmin@orcl2) 6> delete dab

Deleted REPLICAT DAB.

GGSCI (gg2.localdomain as ggadmin@orcl2) 7> ADD REPLICAT dab, EXTTRAIL ./dirdat/tb,

EXTSEQNO 0, EXTRBA 0

REPLICAT added.

25. Запускаем репликация с ранее зафиксированного SCN.

GGSCI (gg2.localdomain as ggadmin@orcl2) 14> start dab aftercsn 1919378


REPLICAT DAB starting

GGSCI (gg2.localdomain as ggadmin@orcl2) 15> info all


MANAGER RUNNING

REPLICAT RUNNING DAB 00:00:00 00:00:03


26. Генерируем несколько записеи в DEPARTMENTS и EMPLOYEES на

источнике (GG1)

SQL> @/home/oracle/GG_LAB_NEW1/Oracle2OracleClassic/7.Workload/demo_ora_insert.sql


Страница 25

SQL*Plus: Release 12.1.0.2.0 Production on Mon Jan 26 01:42:05 2015


Connected.

Session altered.

Number of rows in array to update or delete =2000

PL/SQL procedure successfully completed.

SQL> select count(*) from employees;

COUNT(*)

----------

27590

SQL> select count(*) from departments;

COUNT(*)

----------

360

SQL> exit;

Disconnected from Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit

Production



Как можно видеть на источнике теперь 27590 записеи .

27. Проверяем количество записеи , переданных процессом DAB

GGSCI (gg2.localdomain as ggadmin@orcl2) 29> stats dab

Sending STATS request to REPLICAT DAB ...

Start of Statistics at 2015-01-26 01:45:00.

Replicating from GGTEST.DEPARTMENTS to GGTEST.DEPARTMENTS:

*** Total statistics since 2015-01-26 01:36:51 ***

Total inserts 360.00

Total updates 0.00

Total deletes 0.00

Total discards 0.00

Total operations 360.00

*** Daily statistics since 2015-01-26 01:36:51 ***


Total updates 0.00

Total deletes 0.00

Total discards 0.00


*** Hourly statistics since 2015-01-26 01:36:51 ***


Total updates 0.00

Total deletes 0.00

Total discards 0.00


Страница 26


*** Latest statistics since 2015-01-26 01:36:51 ***


Total updates 0.00

Total deletes 0.00

Total discards 0.00


Replicating from GGTEST.EMPLOYEES to GGTEST.EMPLOYEES:



Total updates 1002.00

Total deletes 782.00

Total discards 0.00


*** Daily statistics since 2015-01-26 01:36:51 ***




Total discards 0.00


*** Hourly statistics since 2015-01-26 01:36:51 ***




Total discards 0.00


*** Latest statistics since 2015-01-26 01:36:51 ***




Total discards 0.00


End of Statistics.

Как можно видеть было передано 360 записеи в таблице DEPARTMENTS. По

таблице EMPLOYEES прошло 28372 INSERT, 1002 UPDATE и 782 DELETE. Для

проверки можно взять по таблице EMPLOYEES количество INSERT и DELETE. Их

разница и будет количеством записеи в таблице.

28. Посмотрим количество записеи на приемнике

select count(*) from ggtest.employees;

select count(*) from ggtest.departments;

COUNT(*)

----------

27590

SQL>

COUNT(*)


Страница 27

----------

360

SQL>

Также на приемнике можно запустить следующие команды:

select * from ggtest.employees minus select * from ggtest.employees@orcl1;

select * from ggtest.employees@orcl1 minus select * from ggtest.employees;

Если обе команды не вернут данных, то можно сделать вывод о синхронности

баз.

5. АНАЛИЗ И ОПТИМИЗАЦИЯ ПРОИЗВОДИТЕЛЬНОСТИ GOLDENGATE

Страница 28

5. Анализ и оптимизация производительности GoldenGate

GoldenGate использует компонентную схему работы. Есть процессы Extract, Pump

и Replicat. Они никак не завязаны друг на друга. При остановке или торможении

одного процесса другие продолжают нормально работать.

Компонентная схема делает задачу оптимизации производительности довольно

простои . Для определения причины торможения можно использовать

информацию о лаге компонент GoldenGate.

1. Даваи те запустим более длительную нагрузку

[oracle@gg3 distrib]$ sqlplus /nolog

@/home/oracle/GG_LAB_NEW1/Oracle2OracleClassic/7.Workload/demo_ora_insert_1000000



Connected.

Session altered.

2. Параллельно с этим даваи те посмотрим на каждыи компонент в

отдельности. Полезная команда для этого info all. На источнике:



MANAGER RUNNING

EXTRACT RUNNING CAB 00:00:00 00:00:07

EXTRACT RUNNING PAB 00:00:03 00:00:00


Нас интересен столбец Lag at Chkpt. Он показывает разницу между текущим

временем системы и временем последнеи обработаннои транзакции. Видно, что

CAB не отстает, PAB отстает на 3 секунду.

3. Если то же самое посмотреть на приемнике, то можно увидеть, что DAB

будет отставать сильнее (в рамках лабораторнои это может не

наблюдаться)




Страница 29

MANAGER RUNNING



Видно, что DAB отстает на 8 секунд. Причины могут быть самые разные – от

слишком высокои нагрузки (что решается распараллеливанием) до медленно

работающеи целевои базы данных.

Основное – это понять, где мы отстаем.

4. Даваи те посмотрим статистику, с которои GoldenGate извлекает данные из

журнала. Для этого идем на источник и в ggsci вводим команды

GGSCI (gg1.localdomain) 6> stats CAB reportrate sec total

Sending STATS request to EXTRACT CAB ...


Output to ./dirdat/ta:

Extracting from GGTEST.DEPARTMENTS to GGTEST.DEPARTMENTS:


Total inserts/second: 3.30

Total updates/second: 0.00

Total deletes/second: 0.00

Total discards/second: 0.00

Total operations/second: 3.30

Extracting from GGTEST.EMPLOYEES to GGTEST.EMPLOYEES:







End of Statistics.

Как можно видеть в среднем обрабатывается около 323 операции в секунду.

Нужно понимать, что это статистика с момента запуска и она может быть

непоказательна.

5. Посмотрим статистику на стороне приемника для процесса DAB

GGSCI (gg2.localdomain as ggadmin@orcl2) 34> stats DAB reportrate sec total

Sending STATS request to REPLICAT DAB ...


Replicating from GGTEST.DEPARTMENTS to GGTEST.DEPARTMENTS:


Страница 30







Replicating from GGTEST.EMPLOYEES to GGTEST.EMPLOYEES:







End of Statistics.

Также можно видеть, что Replicat обрабатывает около 333 записеи в секунду.

Отставание при этом у все процессов близко к 0 секунд, а значит GoldenGate

справляется с текущеи нагрузкои .

6. Интересную информацию можно увидеть, если остановить все процессы и

дать скрипту "нагенерировать" побольше данных.

7. Даваи те остановим процессы на источнике и приемнике.

На источнике:

GGSCI (gg1.localdomain) 8> stop *

Sending STOP request to EXTRACT CAB ...

Request processed.

Sending STOP request to EXTRACT PAB ...

Request processed.



MANAGER RUNNING

EXTRACT STOPPED CAB 00:00:00 00:00:06

EXTRACT STOPPED PAB 00:00:00 00:00:06


На приемнике:

GGSCI (gg2.localdomain as ggadmin@orcl2) 35> stop *

Sending STOP request to REPLICAT DAB ...

Request processed.



Страница 31


MANAGER RUNNING

REPLICAT STOPPED DAB 00:00:00 00:00:02


8. Добавим в каждыи процесс команду для вывода статистики каждые 10

секунд. Это очень удобно для мониторинга.

edit params dab

REPORTCOUNT EVERY 10 SECONDS, RATE

9. Запустим нагрузку:

[oracle@gg3 distrib]$ sqlplus /nolog

@/home/oracle/GG_LAB_NEW1/Oracle2OracleClassic/7.Workload/demo_ora_insert_1000000



Connected.

Session altered.

10. Подождем 1 минуту. Запустим процессы и опять посмотрим

количество обработанных записеи в секунду. Но в этот раз воспользуемсы

командои просмотра отчета

view report cab

view report pab

view report dab

11. Вопрос: Какие процессы работают быстрее Extract или Replicat?

12. Обычно узким местом репликации становится процесс применения

изменении , поскольку на источнике изменения генерируются в несколько

потоков, а на приемнике мы пытаемся применить их в один поток. Чтобы

Replicat не становился узким местом необходимо настроить

распараллеливание. Настроим распараллеливание нагрузки. Для это

преобразуем Replicat в coordinated.

13. Для этого остановим и запомним текущую позицию Replicat

GGSCI (gg2.localdomain as ggadmin@orcl2) 64> stop dab

Sending STOP request to REPLICAT DAB ...

Request processed.


Страница 32

GGSCI (gg2.localdomain as ggadmin@orcl2) 65> info da

ERROR: Invalid command.

GGSCI (gg2.localdomain as ggadmin@orcl2) 66> info dab

REPLICAT DAB Last Started 2015-01-26 02:54 Status STOPPED

Checkpoint Lag 00:07:50 (updated 00:02:06 ago)

Log Read Checkpoint File ./dirdat/tb000004

2015-01-26 02:47:39.114736 RBA 61991649

Как можно видеть наш Replicat стоит на фаи ле #4 в позиции 61991649

14. Залогинимся, удалим DAB и пересоздадим его как coordinated

GGSCI (gg2.localdomain as ggadmin@orcl2) 67> dblogin useridalias ggadmin


GGSCI (gg2.localdomain as ggadmin@orcl2) 68> delete dab

Deleted REPLICAT DAB.


GGSCI (gg2.localdomain as ggadmin@orcl2) 69> add replicat dab coordinated exttrail

./dirdat/tb extseqno 4 extrba 61991649

REPLICAT (Coordinated) added.

15. Настроим распараллеливание для таблицы EMPLOYEES в фаи ле

параметров DAB

replicat dab



USERIDALIAS ggadmin

discardfile ./dirrpt/dab.dsc, purge

assumetargetdefs


map ggtest.*, target ggtest.*, threadrange (1-5);

16. Запустим DAB


REPLICAT DAB starting



MANAGER RUNNING


В результате были запущены 5 потоков, которые можно увидеть с помощью

команды info deuro detail

GGSCI (gg2.localdomain as ggadmin@orcl2) 80> info dab detail

REPLICAT DAB Last Started 2015-01-26 03:06 Status RUNNING


Страница 33

COORDINATED Coordinator MAXTHREADS 25

Checkpoint Lag 00:19:48 (updated 00:00:04 ago)

Process ID 10664

Log Read Checkpoint File ./dirdat/tb000005

2015-01-26 02:48:17.677812 RBA 10330279

Lowest Log BSN value: 4450719

Lowest Last Committed Transaction CSN value: 4548329

Active Threads:

ID Group Name PID Status Lag at Chkpt Time Since Chkpt

1 DAB001 10670 RUNNING 00:19:56 00:00:01

2 DAB002 10671 RUNNING 00:19:53 00:00:01

3 DAB003 10672 RUNNING 00:19:56 00:00:01

4 DAB004 10673 RUNNING 00:19:52 00:00:01

5 DAB005 10674 RUNNING 00:19:56 00:00:00

Current directory /u01/app/oracle/product/ogg12.1.2.1/ora12

Report file /u01/app/oracle/product/ogg12.1.2.1/ora12/dirrpt/DAB.rpt

Parameter file /u01/app/oracle/product/ogg12.1.2.1/ora12/dirprm/dab.prm

Checkpoint file /u01/app/oracle/product/ogg12.1.2.1/ora12/dirchk/DAB.cpr

Checkpoint table ggadmin.checkpointtable

Process file /u01/app/oracle/product/ogg12.1.2.1/ora12/dirpcs/DAB.pcr

Error log /u01/app/oracle/product/ogg12.1.2.1/ora12/ggserr.log

17. Через некоторое время координированныи Replicat прекратит работу

с ошибкои .



MANAGER RUNNING

REPLICAT ABENDED DAB 00:04:34 00:01:20

Чтобы выяснить причину ошибки просмотрим отчет.

view report DAB

В теле отчета будет следующая ошибкам

2015-01-26 03:17:26 ERROR OGG-06004 Coordinated Replicat thread DAB002 exited

unexpectedly. Please check the report file of DAB002 for more details.

Как можно видеть координированныи процесс остановил свою работу по

причине "смерти" одного из своих дочерних процессов – DAB002. Увидеть

причину смерти можно просмотрев отчет DAB002

view report DAB002

В теле отчета будет следующая ошибкам. Ошибка связана с тем, что процесс

при вставке не наше родительскую запись для дочернеи . В результате было

нарушено ограничение целостности FK:


Страница 34

2015-01-26 03:17:24 INFO OGG-06510 Using the following key columns for target

table GGTEST.EMPLOYEES: EMPLOYEE_ID.

2015-01-26 03:17:24 WARNING OGG-00869 OCI Error ORA-02291: integrity constraint

(GGTEST.SYS_C0010372) violated - parent key not found (status = 2291), SQL <INSERT INTO

"GGTEST"."EMPLOYEES" ("EMPLOYEE_ID","FIR

ST_NAME","LAST_NAME","EMAIL","PHONE_NUMBER","HIRE_DATE","JOB_ID","SALARY","COMMISSION_P

CT","MANAGER_ID","DEPARTMENT_ID") VALUES

(:a0,:a1,:a2,:a3,:a4,:a5,:a6,:a7,:a8,:a9,:a10)>.

18. Это нормальное поведение и основная проблема как классических

параллельных Replicat, так и координированных. Причинои является то,

что процессы не координируют между собои работу. Для того, чтобы

продолжить работу отключим Foreign Key. Для интегрированного Replicat

это делать не требуется.

alter table ggtest.employees disable constraint SYS_C0010372;

19. После отключения и перезапуска процесса DAB мы увидим

практически линеи ныи рост производительности:

view report dab001

…

view report dab005

Каждыи из процессов будет отрабатывать 2000 записеи , а суммарно будет

10000.

Switching to next trail file ./dirdat/tb000017 at 2015-01-26 03:38:46 due to EOF, with

current RBA 99999854

Opened trail file ./dirdat/tb000017 at 2015-01-26 03:38:46

94045 records processed as of 2015-01-26 03:38:50 (rate 2351,delta 2276)




20. Но производительность Replicat можно еще поднять, если

проанализировать ожидания.


Страница 35

21. Enterprise Manager показывает, что у нас есть ожидания commit и

конкуренция.

22. В рамках лабораторнои работы мы вряд ли увидим сильное

увеличение производительности, но при нормальнои дисковои системе

можно значительно снизить нагрузку на LGWR включением параметра

BATCHSQL в Replicat:

replicat dab



USERIDALIAS ggadmin

discardfile ./dirrpt/dab.dsc, purge

assumetargetdefs


--handlecollisions

batchsql

map ggtest.*, target ggtest.*, threadrange (1-5);

23. Перезапустим и посмотрим производительность dab. Она должна

значительно вырасти, потому что нагрузку на log резко упала


Страница 36

Switching to next trail file /u01/app/oracle/product/ogg12.1.2.1/ora12/dirdat/tb000022

at 2015-01-26 04:09:15 due to EOF, with current RBA 99999819

Opened trail file /u01/app/oracle/product/ogg12.1.2.1/ora12/dirdat/tb000022 at 2015-01-

26 04:09:15


Switching to next trail file /u01/app/oracle/product/ogg12.1.2.1/ora12/dirdat/tb000023

at 2015-01-26 04:09:22 due to EOF, with current RBA 99999957

Opened trail file /u01/app/oracle/product/ogg12.1.2.1/ora12/dirdat/tb000023 at 2015-01-

26 04:09:22


6. НАСТРАИВАЕМ ДОПОЛНИТЕЛЬНЫЙ ИСТОЧНИК MYSQL

Страница 37

6. Настраиваем дополнительныи источник MySQL

1. Если в качестве engine в MySQL используется InnoDB, то мы можем

использовать GoldenGate для репликации MySQL EE и MySQL Community

Edition (Относительно недавно)

2. Перед тем как настраивать репликацию в GoldenGate необходимо включить

журналирование MySQL. Для этого установим следующие параметры в

/etc/my.cnf:

log_bin=/mysql_log/mysql_log.bin

log_bin_index = /mysql_log/mysql_log_index.bin

binlog_format = ROW

3. Перезапустим MySQL:

[oracle@gg1 mysql]$ sudo mkdir /mysql_log -p

[oracle@gg1 mysql]$ sudo chmod 777 /mysql_log

[oracle@gg1 mysql]$

[oracle@gg1day db11g]$ sudo service mysqld restart

Shutting down MySQL.. [ OK ]

Starting MySQL. [ OK ]

[oracle@gg1day db11g]$

4. Проверим, что фаи л появились

ls /mysql_log/mysql_log*

/mysql_log/mysql_log.000001 /mysql_log/mysql_log.000002 /mysql_log/mysql_log.000003

/mysql_log/mysql_log.000004 /mysql_log/mysql_log.000005

/mysql_log/mysql_log_index.bin

5. Создадим таблицы

mysql -u root

SET PASSWORD FOR 'root'@'localhost' = PASSWORD('oracle');

GRANT ALL ON repl.* TO 'root'@'localhost' IDENTIFIED BY 'oracle';

create database repl;

use repl

CREATE TABLE DEPARTMENTS

( DEPARTMENT_ID NUMERIC(20),

DEPARTMENT_NAME VARCHAR(30),

MANAGER_ID NUMERIC(6),

LOCATION_ID NUMERIC(4),

PRIMARY KEY (DEPARTMENT_ID)

);

CREATE TABLE EMPLOYEES

( EMPLOYEE_ID NUMERIC(20,0),

FIRST_NAME VARCHAR(20),

LAST_NAME VARCHAR(25),

EMAIL VARCHAR(25),

PHONE_NUMERIC VARCHAR(20),


Страница 38

HIRE_DATE DATE,

JOB_ID VARCHAR(10),

SALARY NUMERIC(8,2),

COMMISSION_PCT NUMERIC(2,2),

MANAGER_ID NUMERIC(6,0),

DEPARTMENT_ID NUMERIC(20,0),

PRIMARY KEY (EMPLOYEE_ID),

FOREIGN KEY (DEPARTMENT_ID)

REFERENCES DEPARTMENTS (DEPARTMENT_ID)

);

6. Заполним таблицы небольшим количеством данных:

use repl

insert into DEPARTMENTS values (1,'AA',1,1);

insert into DEPARTMENTS values (2,'BB',1,1);

insert into DEPARTMENTS values (3,'CC',1,1);

insert into DEPARTMENTS values (4,'DD',1,1);

insert into EMPLOYEES values (1,'A','A','A','111',CURDATE(),'A',100,NULL,1,1);






commit;

set echo on

select count(*) from EMPLOYEES;

select count(*) from DEPARTMENTS;

exit;

7. Переи дем в каталог c GoldenGate for MySQL

[oracle@gg1 ~]$ cd /u01/app/oracle/product/ogg12.1.2.1/mysql/

[oracle@gg1 mysql]$ ggsci

Oracle GoldenGate Command Interpreter for MySQL






8. Включаем расширенное журналирование (для MySQL не требуется)

DBLOGIN SOURCEDB repl@localhost:3307, USERID root, PASSWORD oracle

ADD TRANDATA repl.*

9. В ggsci создаем фаи л параметров процесса CABM командои edit params

CABM (буквои M в конце имени процесса будем обозначать процессы

MySQL).

edit params CABM


Страница 39

Фаи л параметров будет содержать следующии текст

EXTRACT CABM

setenv (MYSQL_UNIX_PORT=/var/lib/mysql/mysql.sock)

SOURCEDB repl@localhost:3307, USERID root, PASSWORD oracle

TRANLOGOPTIONS ALTLOGDEST "/mysql_log/mysql_log_index.bin"

EXTTRAIL ./dirdat/tc

TABLE repl.*;

Создаем процесс CABM

delete CABM

add extract CABM, tranlog,begin now

ADD exttrail ./dirdat/tc, EXTRACT CABM, MEGABYTES 50

10. Запустим процесс CABM:

GGSCI (gg1.localdomain) 2> start cabm


EXTRACT CABM starting



MANAGER RUNNING

EXTRACT RUNNING CABM 00:08:57 00:00:01



MANAGER RUNNING

EXTRACT RUNNING CABM 00:00:00 00:00:06


11. Создаем фаи л параметров для peuroa

EXTRACT pabm

RMTHOST gg2,MGRPORT 7809

RMTTRAIL ./dirdat/td

PASSTHRU

TABLE repl.*;

Добавим pump-процесс

delete pabm

add extract pabm, exttrailsource ./dirdat/tc,begin now

ADD rmttrail ./dirdat/td, EXTRACT pabm, MEGABYTES 50

start pabm


Страница 40

12. Поскольку репликация осуществляется в гетерогеннои среде, то

необходимо будет создать def-фаи л. Этот фаи л создается на источнике и

переносится на приемник, чтобы приемник (а точнее процесс replicat)

обладал всеи необходимои информациеи об источнике.

13. На источнике заходим в каталог GoldenGate для mysql и создаем фаи л

параметров dirprm/defgen.prm со следующим содержимым

defsfile ./dirdef/mysql.defs, purge

SOURCEDB repl@localhost:3307, USERID root, PASSWORD oracle

table repl.*;

14. Запустим defgen

[oracle@gg1day mysql56]$ export MYSQL_UNIX_PORT=/var/lib/mysql/mysql.sock

[oracle@gg1 mysql]$ ./defgen paramfile dirprm/defgen.prm

***********************************************************************

Oracle GoldenGate Table Definition Generator for MySQL




Starting at 2015-01-26 05:05:30

***********************************************************************

Operating System Version:

Linux

Version #2 SMP Thu Dec 18 00:15:51 PST 2014, Release 3.8.13-55.1.2.el6uek.x86_64

Node: gg1.localdomain

Machine: x86_64

soft limit hard limit

Address Space Size : unlimited unlimited

Heap Size : unlimited unlimited

File Size : unlimited unlimited

CPU Time : unlimited unlimited

Process id: 4513

***********************************************************************

** Running with the following parameters **

***********************************************************************

defsfile ./dirdef/mysql.defs, purge

SOURCEDB repl@localhost:3307, USERID root, PASSWORD ******

table repl.*;

Expanding wildcard table specification repl.*:

Retrieving definition for repl.DEPARTMENTS.

Retrieving definition for repl.EMPLOYEES.

Definitions generated for 2 tables in ./dirdef/mysql.defs.

[oracle@gg1 mysql]$

15. Скопируем фаи л ./dirdef/mysql.defs на приемник в каталог ./dirdef


Страница 41

[oracle@gg1 mysql]$ scp ./dirdef/mysql.defs

oracle@gg2:/u01/app/oracle/product/ogg12.1.2.1/ora12/dirdef

oracle@gg2's password:

mysql.defs

100% 2790 2.7KB/s 00:00

[oracle@gg1 mysql]$

16. На приемнике создадим фаи л конфигурации Replicat:

replicat dabm

USERIDALIAS ggadmin

discardfile ./dirrpt/dabm.dsc, purge

sourcedefs dirdef/mysql.defs

map repl.*, target ggtest_mysql.*;

17. Создадим процесс Replicat:

delete dabm

ADD REPLICAT dabm, EXTTRAIL ./dirdat/td, EXTSEQNO 0, EXTRBA 0

18. Вставим несколько записеи на источнике

mysql –u root –p

password: oracle

use repl




commit;

19. Проверим, что данные попали на приемник.

SQL> select count(*) from ggtest_mysql.employees;

COUNT(*)

----------

3

7. НАСТРАИВАЕМ GOLDENGATE DIRECTOR

Страница 42

7. Настраиваем GoldenGate Director

GoldenGate имеет следующую архитектуру

Как можно видеть в центре есть серверное приложение, которое

разворачивается на Weblogic. Есть клиенты, через которое пользователи

подключаются к Director (Director Web, Director Client и Director Admininstrator).

Есть также база данных (репозитории ), где GoldenGate Director хранит

информацию об объектах GoldenGate.

1. Прежде чем начинать инсталляцию необходимо создать базу данных

репозитория (пароль обязательно должен содержать цифру). Базу данных

создаем на сервере gg1:

CREATE USER ggDirector IDENTIFIED BY welcome1 DEFAULT TABLESPACE users;

ALTER USER ggDirector QUOTA UNLIMITED ON users;

GRANT connect,resource TO ggDirector;

После этого запускаем инсталляцию Director на gg3fmw:

cd /home/oracle/GG_LAB_NEW1/distrib/gg_director

chmod 777 gg-director-serversetup_unix_v12_1_2_0_1.sh


Страница 43

./gg-director-serversetup_unix_v12_1_2_0_1.sh

2. Отвечаем на вопросы инсталляции


Страница 44


Страница 45

3. После того как инсталляция закончится необходимо запустить домен с

GoldenGate Director

cd /u01/app/oracle/product/director/domain

./startWeblogic.sh

НАСТРОЙКА СВЕРКИ ДАННЫХ С ПОМОЩЬЮ VERIDATA

Страница 46

Настрои ка сверки данных с помощью Veridata

Veridata позволяет производить сверку данных между источником и

приемником. Может работать параллельно с репликациеи . Проверка

корректности репликации не требует остановки СУБД.

Результаты сверки можно использовать для ресинхронизации баз данных.

Ниже приведены шаги по инсталляции и настрои ке Veridata 12.1.3. Инсталляция

Veridata делится на следующие этапы:

создание репозитория и инсталляция сервера Veridata – выполняется 1 раз

инсталляция stage-агентов (из этих агентов затем создаются агенты,

смотрящие непосредственно на базы данных) – выполняется 1 раз для

каждого хоста

инсталляция конечного агента – выполняется 1 раз для каждои базы

данных

1. На сервере GG3 установим переменную JAVA_HOME и запустим RCU для

создания репозитория

[oracle@gg3 bin]$ export JAVA_HOME=/usr/java/jdk1.7.0_67

[oracle@gg3 bin]$ cd /u01/app/oracle/product/fmw1213/oracle_common/bin/

[oracle@gg3 bin]$ ./rcu

2. После запуска графическои утилиты указываем, как мы хотим создавать

репозитории . Проще всего позволить RCU самому создать все


Страница 47

3. Вводим параметры для подключения к базе данных репозитория


Страница 48

4. Выбираем, что хотим инсталлировать Veridata. Также вводим префикс для

имен пользователеи (я ввел OGG)


Страница 49

5. Вводим пароль для вновь создаваемых пользователеи . Лучше взять пароль,

где есть хотя бы одна цифра (например, welcome1). На следующем экране

проверяем корректность параметров и запускаем создания репозитория


Страница 50

6. По окончанию создания нужно будет запустить создание домена Weblogic,

которыи будет хостить Veridata.

[oracle@gg1day bin]$ cd /u01/app/oracle/product/fmw1213/wlserver/common/bin/

[oracle@gg1day bin]$ ./config.sh

7. Указываем имя домена – я указал veridata_domain


Страница 51

8. Выбираем, что хоти инсталлировать Veridata. Автоматически поставится

галочка напротив JRF – это пререквизит для инсталляции Veridata


Страница 52

9. Задаем пароль для пользователя Weblogic:


Страница 53

10. Соглашаемся с режимом домена по-умолчанию

11. На следующем экране указываем подключению к базе данных, в

которои хранится ранее созданныи репозитории . Жмем Get RCU

Configuration. Не забываи те указывать префикс, заданыи при работе с

репозиторием.


Страница 54


Страница 55

12. По-умолчанию, GoldenGate Veridata попытается встать на отдельныи

managed server. Это хорошо для продукционнои системы, но плохо работает

в рамках лабораторнои работы. Поэтому я перераспределил и избавился от

лишних серверов приложении . Для этого на последнеи странице я поставил

галки, что хочу управлять куак приложениями, так и железными.

13. На закладке Managed Servers удалим специальныи сервер для Veridata


Страница 56

14. На закладке с развертывание приложении все приложения и

библиотеки перекидываем на AdminServer

15. Аналогично по ресурсам и сервисам. Они должны быть привязаны к

AdminServer.


Страница 57

16. Запускаем инсталляцию и ждем окончания.

17. По окончанию создания можно запускать сервис Veridata.

[oracle@gg1day bin]$ cd

/u01/app/oracle/product/fmw1213/user_projects/domains/veridata_domain/

[oracle@gg1day veridata_domain]$ ./startWebLogic.sh

18. Для работы нам понадобится 2 агента: один для orcl1 (gg1), второи

для orcl2 (gg2).

Следующии шаг – это инсталляция stage-агентов. Для этого запускаем

инсталляцию veridata:

java -jar fmw_12.1.3.0.0_ogg.jar

19. При запросе пути указываем

/u01/app/oracle/product/veridata12.1.3_stage1

20. В окне типов инсталляции указываем "Oracle GoldenGate Veridata

Agent":


Страница 58

21. Дожидаемся окончания инсталляции.

22. Повторяем на GG2

23. После того как stage-агенты проинсталлированы необходимо

выполнить их deploy. По сути это выполнение скрипта, которыи создает

отдельныи экземпляр агента под свою базу данных.

24. Запускаем следующие команды:

export JAVA_HOME=/usr/java/jdk1.7.0_67

cd /u01/app/oracle/product/veridata12.1.3_stage1/veridata/agent/

[oracle@gg1 agent]$ ./agent_config.sh /u01/app/oracle/product/veridata12.1.3_deploy

Successfully deployed the agent.

25. Теперь необходимо сконфигурировать агенты их и запустить их.

Конфигурация осуществляется редактированием фаи ла

/u01/app/oracle/product/veridata_agent_deploy/agent.properties. В поставке

есть фаи лы agent.properties.sample, которые и нужно взять за основу

26. Для gg2 введем следующие параметры:


Страница 59

server.port=9001

database.url=jdbc:oracle:thin:@localhost:1521/orcl2

server.jdbcDriver=ojdbc7.jar oracle.xdb_12.1.0.jar

27. Для Oracle gg1 введем следующие параметры

server.port=9001

database.url=jdbc:oracle:thin:@localhost:1521:orcl1

server.jdbcDriver=ojdbc7.jar oracle.xdb_12.1.0.jar

28. На обеих серверах запустим агента.

[oracle@gg1day ~]$ cd /u01/app/oracle/product/veridata12.1.3_deploy

[oracle@gg1day veridata_agent_deploy]$ export JAVA_HOME= /usr/java/jdk1.7.0_67

[oracle@gg1day veridata_agent_deploy]$ ./agent.sh start

[oracle@gg1day veridata_agent_deploy]$ tail -f logs/veridata-agent.log

[VERIAGT-BOOT] INFO Looking for home directory.

[VERIAGT-BOOT] INFO Found bootstrap class in

file:/u01/app/oracle/product/veridata_agent/veridata/agent/JavaAgent.jar!/com/goldengat

e/veridata/agent/Bootstrap.class.

[VERIAGT-BOOT] INFO Home directory:

/u01/app/oracle/product/veridata_agent/veridata/agent

[VERIAGT-BOOT] INFO Preparing classpath.

[VERIAGT-BOOT] INFO Driver location:

/u01/app/oracle/product/veridata_agent_deploy/drivers

[VERIAGT-BOOT] INFO Drivers to load: ojdbc7.jar oracle.xdb_12.1.0.jar

[VERIAGT-BOOT] INFO Classpath:

[VERIAGT-BOOT] INFO

/u01/app/oracle/product/veridata_agent/veridata/agent/JavaAgent.jar

[VERIAGT-BOOT] INFO

/u01/app/oracle/product/veridata_agent/oracle_common/modules/oracle.xdb_12.1.0.jar

[VERIAGT-BOOT] INFO

/u01/app/oracle/product/veridata_agent/oracle_common/modules/oracle.jdbc_12.1.0/ojdbc7.

jar

[VERIAGT-BOOT] INFO /u01/app/oracle/product/veridata_agent/veridata/agent/agent-

manifest.jar

[VERIAGT-BOOT] INFO Initializing.

[VERIAGT-BOOT] INFO Invoking startup method: public static void

com.goldengate.veridata.agent.VeridataAgent.main(java.lang.String[])

2014-07-24 07:11:10.209 NOTIFICATION OGGV-60150 Configuring logging.

2014-07-24 07:11:10.339 NOTIFICATION OGGV-60151 Config file for logger is

/u01/app/oracle/product/veridata_agent_deploy/config/odl.xml

2014-07-24 07:11:10.379 NOTIFICATION OGGV-60001: Veridata Agent Version 12.1.3.0.0

OGGVDT_12.1.3.0.0_PLATFORMS_140616.1904 built on Mon, 16 Jun 2014 19:38:59 -0700

2014-07-24 07:11:10.381 NOTIFICATION OGGV-60002 Veridata Agent starting on gg1day.local

port 9001

Server gg1day.local:9001 starting

29. После запуска агентов можно идти и конфигурировать сравнение в

интерфеи се Veridata, но перед эти нужно создать пользователя и наделить

его правами.

30. Адрес консоли для серверав

http://gg1day:7001/console

31.


Страница 60


Страница 61

Запускаем создание домена

Используемые возможности GoldenGate 12c.

Support for Oracle 12c Multitenant Databases. GoldenGate 12c supports capture

from multiple pluggable databases with a single capture process as well as

applying to pluggable databases (each with its own dedicated apply). Standard

three-part naming conventions allow data to be mapped between multitenant

and standalone databases.

Credential Store GoldenGate 12c now employs a credential store to maintain

encrypted database passwords and user IDs and associate them with an alias. It is

the alias, not the actual user ID or password that is specified in a command or

parameter file and no user input of an encryption key is required. The credential

store is implemented as an auto login wallet within the Oracle Credential Store

Framework (CSF).

Integrated Replicat. In integrated mode, available for Oracle databases of version

11.2.0.4 or later, a single Replicat configuration leverages apply processing

functionality that is available within the Oracle database. Integrated Replicat

enables heavy workloads to be partitioned automatically among parallel apply

processes that apply multiple transactions concurrently while preserving the

integrity (computes Primary and Foreign Key Relationships) and atomicity of the

source transaction. Parallelism is increased or decreased dynamically as needed.

Default Discard File. Parameter files no longer need to specify a discard file for

replication errors. A file will automatically be created in the dirrpt directory and s

named after the process that created it with a dsc extension (i.e. <process

name>.dsc).

oracle goldengate 12coraclegis.com/blog/wp-content/uploads/2015/01/handson_v2.pdf · 4....

Documents