GoldenGate Bidirecional Oracle para Oracle
May 10, 2011

Instrodução

No meu post  anterior sobre GoldenGate, foi apresentado de uma forma sintetizada, como o Oracle GoldenGate usa seus processos internos para realizar a replicação. Hoje, estarei demonstrando a instalação e configuração de um ambiente de replicação Bidirecional de Oracle para Oracle.

Lembro que essa é uma instalação em um ambiente de teste, em um ambiente de produção deve seguir rigorosamente todos os pré requisitos solicitados de acordo com o recomendado pela documentação (Hardwares, Sofwtares, Versões, etc …).

O download do Oracle GoldenGate pode ser feito através do http://edelivery.oracle.com, quando você aceita os termos de utilização será redirecionado para a página “Media Pack Search”. Selecione o produto no combo “Select a Product Pack” e selecione “Oracle Fusion Middleware” e abaixo selecione sua plataforma, que no meu caso foi “Linux x86″.

Criando o cénario

  • Virtual Box 4.0.4
  • Oracle Enterprise Linux 5 x86
  • Oracle Database !0g Release 2
  • Oracle GoldenGate 11g Release 1

Para que os testes de replicação fosse feito, duas máquinas virtuais com Oracle 10gR2 foi criada. Fique atendo as configurações de HOSTNAME, IP e DATABASE NAME que será utilizado por todo o artigo. As configurações podem ser diferentes deste exemplo, desde que sejam coerentes.

Máquina Virtual 1 – SERVER SOURCE

  • Hostname = gg1
  • Database = ponta1
  • Ip = 10.0.0.12

Máquina Virtual 2 – SERVER TARGET

  • Hostname = gg2
  • Database = ponta2
  • Ip = 10.0.0.13

As configurações acima reflete o ambiente da imagem abaixo, temos um database SOURCE e um TARGET. Toda ação que sofre uma reação de DML ou DDL será transferida do SOURCE para o TARGET, nesse exemplo estaremos usando somente a replicação do usuário REPLICA que será criado mais a adiante.

Instalação

Após ser realizado o download do binário do GoldenGate é necessário descompactar, neste exemplo estarei colocando o GoldenGate dentro do ORACLE_BASE na pasta gg11.

flavio@shadowy:~$ ssh oracle@gg1
oracle@gg1's password:
Last login: Thu Apr 21 18:14:36 2011 from 10.0.0.1
[oracle@gg1 ~]$ cd $ORACLE_BASE/gg11
[oracle@gg1 gg11]$ ls -l
total 59880
-rw------- 1 oracle oinstall 61250823 Apr 21 18:11 V22228-01 GG 11g.zip
[oracle@gg1 gg11]$ unzip V22228-01\ GG\ 11g.zip
Archive: V22228-01 GG 11g.zip
inflating: ggs_Linux_x86_ora11g_32bit_v11_1_1_0_0_078.tar
inflating: OGG_WinUnix_Rel_Notes_11.1.1.0.0_078.pdf
inflating: README.txt
[oracle@gg1 gg11]$ ls -l
total 227292
-rw-rw---- 1 oracle oinstall 170721280 Jul 28 2010 ggs_Linux_x86_ora11g_32bit_v11_1_1_0_0_078.tar
-rwxrwxr-x 1 oracle oinstall 500964 Aug 6 2010 OGG_WinUnix_Rel_Notes_11.1.1.0.0_078.pdf
-rwxrwxr-x 1 oracle oinstall 26726 Aug 2 2010 README.txt
-rw------- 1 oracle oinstall 61250823 Apr 21 18:11 V22228-01 GG 11g.zip
[oracle@gg1 gg11]$ tar -xvof ggs_Linux_x86_ora11g_32bit_v11_1_1_0_0_078.tar
bcpfmt.tpl
bcrypt.txt
chkpt_ora_create.sql
...
[oracle@gg1 gg11]$

O mesmo procedimento deve ser feito no servidor gg2

flavio@shadowy:~$ ssh oracle@gg2
oracle@gg2's password:
Last login: Thu Apr 21 18:14:36 2011 from 10.0.0.1
[oracle@gg2 ~]$ cd $ORACLE_BASE/gg11
[oracle@gg2 gg11]$ ls -l
total 59880
-rw------- 1 oracle oinstall 61250823 Apr 21 18:11 V22228-01 GG 11g.zip
[oracle@gg2 gg11]$ unzip V22228-01\ GG\ 11g.zip
Archive: V22228-01 GG 11g.zip
inflating: ggs_Linux_x86_ora11g_32bit_v11_1_1_0_0_078.tar
inflating: OGG_WinUnix_Rel_Notes_11.1.1.0.0_078.pdf
inflating: README.txt
[oracle@gg2 gg11]$ ls -l
total 227292
-rw-rw---- 1 oracle oinstall 170721280 Jul 28 2010 ggs_Linux_x86_ora11g_32bit_v11_1_1_0_0_078.tar
-rwxrwxr-x 1 oracle oinstall 500964 Aug 6 2010 OGG_WinUnix_Rel_Notes_11.1.1.0.0_078.pdf
-rwxrwxr-x 1 oracle oinstall 26726 Aug 2 2010 README.txt
-rw------- 1 oracle oinstall 61250823 Apr 21 18:11 V22228-01 GG 11g.zip
[oracle@gg2 gg11]$ tar -xvof ggs_Linux_x86_ora11g_32bit_v11_1_1_0_0_078.tar
bcpfmt.tpl
bcrypt.txt
chkpt_ora_create.sql
...
[oracle@gg2 gg11]$

 

Variáveis de ambiente

Adicione em seu .bash_profile as linhas nos dois servidores (gg1 e gg2).

GGATE=$ORACLE_BASE/gg11; export GGATE
LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib:$GGATE; export LD_LIBRARY_PATH

O executável ggsci aparace quando descompactamos o ggs_Linux_x86_ora11g_32bit_v11_1_1_0_0_078.tar, ele é o principal utilitário do GoldenGate, com ele é possível configurar como será toda a replicação de dados.

[oracle@gg1 gg11]$ ./ggsci

Oracle GoldenGate Command Interpreter for Oracle
Version 11.1.1.0.0 Build 078
Linux, x86, 32bit (optimized), Oracle 11 on Jul 28 2010 13:22:25
Copyright (C) 1995, 2010, Oracle and/or its affiliates. All rights reserved.
GGSCI (gg1.localdomain) 1>

Algumas vezes ao executar o comando ggsci o seguinte erro é apresentando:

./ggsci: error while loading shared libraries: libnnz11.so: cannot open shared object file: No such file or directory

./ggsci: error while loading shared libraries: libclntsh.so.11.1: cannot open shared object file: No such file or directory

O erro é devido a falta dos arquivos da biblioteca do Oracle libnnz11.so e libclntsh.so.11.1. O erro é pode ser corrigido da seguinte maneira:

[oracle@gg1 gg11]$ ./ggsci
./ggsci: error while loading shared libraries: libnnz11.so: cannot open shared object file: No such file or directory
[oracle@gg1 gg11]$ ln -s $ORACLE_HOME/lib/libnnz10.so $ORACLE_HOME/lib/libnnz11.so
[oracle@gg1 gg11]$ ./ggsci
./ggsci: error while loading shared libraries: libclntsh.so.11.1: cannot open shared object file: No such file or directory
[oracle@gg1 gg11]$ ln -s $ORACLE_HOME/lib/libclntsh.so.10.1 $ORACLE_HOME/lib/libclntsh.so.11.1
[oracle@gg1 gg11]$ ./ggsci
Oracle GoldenGate Command Interpreter for Oracle
Version 11.1.1.0.0 Build 078
Linux, x86, 32bit (optimized), Oracle 11 on Jul 28 2010 13:22:25
Copyright (C) 1995, 2010, Oracle and/or its affiliates. All rights reserved.

GGSCI (gg1.localdomain) 1>

 Configuração do Database

Os procedimentos de configuração do banco de dado executados abaixo, devem ser feitos nos dois database, PONTA1 (SOURCE) e PONTA2 (TARGET). Aqui estarei demonstrando somente a execução do banco ponta1.

1. Assegure que o database está em modo archive

SYS@ponta1> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /oracle/archive/ponta1
Oldest online log sequence 23
Next log sequence to archive 25
Current log sequence 25

2. Desabilite a recyclebin

SYS@ponta1> alter system set recyclebin=off;
System altered.
SYS@ponta1> show parameter bin
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
recyclebin string OFF
SYS@ponta1> purge recyclebin;
Recyclebin purged.

3. Habilite o minimal supplemental logging a nível do database.

SYS@ponta1> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
Database altered.
SYS@ponta1> ALTER SYSTEM SWITCH LOGFILE;
System altered.
SYS@ponta1> SELECT SUPPLEMENTAL_LOG_DATA_MIN FROM V$DATABASE;
SUPPLEME
--------
YES

4. Cria o usuário que será utilizado pelos processos GoldenGate

SYS@ponta1> create user goldengate identified by oracle default tablespace USERS;
User created.
SYS@ponta1> grant dba to goldengate;
Grant succeeded.
SYS@ponta1> grant connect, resource, select any dictionary, FLASHBACK ANY TABLE, SELECT ANY TABLE, CREATE TABLE to goldengate;
Grant succeeded.
SYS@ponta1> grant execute on utl_file to goldengate;
Grant succeeded.

5. Agora é hora de “deixar a casa organizada” para o GoldenGate.  Na verdade essa etapa é uma seqüencia de execuções de scripts.

1ª Script marker_setup.sql

[oracle@gg1 gg11]$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.5.0 - Production on Fri Apr 22 16:37:59 2011

Copyright (c) 1982, 2010, Oracle. All Rights Reserved.

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SYS@ponta1> @$ORACLE_BASE/gg11/marker_setup.sql

Marker setup script

You will be prompted for the name of a schema for the GoldenGate database objects.
NOTE: The schema must be created prior to running this script.
NOTE: Stop all DDL replication before starting this installation.

Enter GoldenGate schema name:goldengate

Marker setup table script complete, running verification script...
Please enter the name of a schema for the GoldenGate database objects:
Setting schema name to GOLDENGATE

MARKER TABLE
-------------------------------
OK

MARKER SEQUENCE
-------------------------------
OK

Script complete.

2ª Script ddl_setup.sql

SYS@ponta1> @$ORACLE_BASE/gg11/ddl_setup.sql

GoldenGate DDL Replication setup script

Verifying that current user has privileges to install DDL Replication...
Checking user sessions...

Check complete.

You will be prompted for the name of a schema for the GoldenGate database objects.
NOTE: For an Oracle 10g source, the system recycle bin must be disabled. For Oracle 11g and later, it can be enabled.
NOTE: The schema must be created prior to running this script.
NOTE: Stop all DDL replication before starting this installation.

Enter GoldenGate schema name:goldengate

You will be prompted for the mode of installation.
To install or reinstall DDL replication, enter INITIALSETUP
To upgrade DDL replication, enter NORMAL
Enter mode of installation:INITIALSETUP

Working, please wait ...
Spooling to file ddl_setup_spool.txt

Using GOLDENGATE as a GoldenGate schema name, INITIALSETUP as a mode of installation.

Working, please wait ...

RECYCLEBIN must be empty.
This installation will purge RECYCLEBIN for all users.
To proceed, enter yes. To stop installation, enter no.

Enter yes or no:yes

DDL replication setup script complete, running verification script...
Please enter the name of a schema for the GoldenGate database objects:
Setting schema name to GOLDENGATE

DDLORA_GETTABLESPACESIZE STATUS:

Line/pos Error
---------- -----------------------------------------------------------------
No errors No errors

CLEAR_TRACE STATUS:

Line/pos Error
---------- -----------------------------------------------------------------
No errors No errors

CREATE_TRACE STATUS:

Line/pos Error
---------- -----------------------------------------------------------------
No errors No errors

TRACE_PUT_LINE STATUS:

Line/pos Error
---------- -----------------------------------------------------------------
No errors No errors

INITIAL_SETUP STATUS:

Line/pos Error
---------- -----------------------------------------------------------------
No errors No errors

DDLVERSIONSPECIFIC PACKAGE STATUS:

Line/pos Error
---------- -----------------------------------------------------------------
No errors No errors

DDLREPLICATION PACKAGE STATUS:

Line/pos Error
---------- -----------------------------------------------------------------
No errors No errors

DDLREPLICATION PACKAGE BODY STATUS:

Line/pos Error
---------- -----------------------------------------------------------------
No errors No errors

DDL HISTORY TABLE
-----------------------------------
OK

DDL HISTORY TABLE(1)
-----------------------------------
OK

DDL DUMP TABLES
-----------------------------------
OK

DDL DUMP COLUMNS
-----------------------------------
OK

DDL DUMP LOG GROUPS
-----------------------------------
OK

DDL DUMP PARTITIONS
-----------------------------------
OK

DDL DUMP PRIMARY KEYS
-----------------------------------
OK

DDL SEQUENCE
-----------------------------------
OK

GGS_TEMP_COLS
-----------------------------------
OK

GGS_TEMP_UK
-----------------------------------
OK

DDL TRIGGER CODE STATUS:

Line/pos Error
---------- -----------------------------------------------------------------
No errors No errors

DDL TRIGGER INSTALL STATUS
-----------------------------------
OK

DDL TRIGGER RUNNING STATUS
-----------------------------------
ENABLED

STAYMETADATA IN TRIGGER
-----------------------------------
OFF

DDL TRIGGER SQL TRACING
-----------------------------------
0

DDL TRIGGER TRACE LEVEL
-----------------------------------
0

LOCATION OF DDL TRACE FILE
--------------------------------------------------------------------------------
/oracle/admin/ponta1/udump/ggs_ddl_trace.log

Analyzing installation status...

STATUS OF DDL REPLICATION
--------------------------------------------------------------------------------
SUCCESSFUL installation of DDL Replication software components

Script complete.

3ª Script role_setup.sql

SYS@ponta1> @$ORACLE_BASE/gg11/role_setup.sql

GGS Role setup script

This script will drop and recreate the role GGS_GGSUSER_ROLE
To use a different role name, quit this script and then edit the params.sql script to change the gg_role parameter to the preferred name. (Do not run the script.)

You will be prompted for the name of a schema for the GoldenGate database objects.
NOTE: The schema must be created prior to running this script.
NOTE: Stop all DDL replication before starting this installation.

Enter GoldenGate schema name:goldengate
Wrote file role_setup_set.txt

PL/SQL procedure successfully completed.

Role setup script complete

Grant this role to each user assigned to the Extract, GGSCI, and Manager processes, by using the following SQL command:

GRANT GGS_GGSUSER_ROLE TO

where is the user assigned to the GoldenGate processes.

SYS@ponta1> GRANT GGS_GGSUSER_ROLE TO goldengate;

Grant succeeded.

4ª Script ddl_enable.sq

SYS@ponta1> @$ORACLE_BASE/gg11/ddl_enable.sql

Trigger altered.

5ª Script ddl_pin

SYS@ponta1> @$ORACLE_BASE/gg11/ddl_pin goldengate

PL/SQL procedure successfully completed.

PL/SQL procedure successfully completed.

PL/SQL procedure successfully completed.

 

Criando o usuário para a replicação

Nesse exemplo, estarei criando e utilizando o usuário REPLICA para demonstrar a transferência de dados do servidor GG1 (SOURCE) para o GG2 (TARGET). A criação do usuário deve ser feita nos dois bancos de dados PONTA1 e PONTA2, aqui estarei demonstrando a criação do banco PONTA1.

[oracle@gg1 ~]$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.5.0 - Production on Sat Apr 23 18:52:06 2011

Copyright (c) 1982, 2010, Oracle.  All Rights Reserved.

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> create user replica identified by oracle; 

User created.

SQL> grant connect, resource to replica;

Grant succeeded.

SQL> create table replica.teste (id number primary key);

Table created.

 Configuração do GoldenGate

Os procedimentos de configuração do GoldenGate executados abaixo, devem ser feitos nos dois hosts, GG1 (SOURCE) e GG2 (TARGET). Aqui estarei demonstrando somente do host gg1.

1. Criação dos subdiretórios do GoldenGate.

[oracle@gg1 ~]$ cd $GGATE
[oracle@gg1 gg11]$ ./ggsci 

Oracle GoldenGate Command Interpreter for Oracle
Version 11.1.1.0.0 Build 078
Linux, x86, 32bit (optimized), Oracle 11 on Jul 28 2010 13:22:25

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

GGSCI (gg1.localdomain) 1> create subdirs

Creating subdirectories under current directory /oracle/gg11

Parameter files /oracle/gg11/dirprm: created
Report files /oracle/gg11/dirrpt: created
Checkpoint files /oracle/gg11/dirchk: created
Process status files /oracle/gg11/dirpcs: created
SQL script files /oracle/gg11/dirsql: created
Database definitions files /oracle/gg11/dirdef: created
Extract data files /oracle/gg11/dirdat: created
Temporary files /oracle/gg11/dirtmp: created
Veridata files /oracle/gg11/dirver: created
Veridata Lock files /oracle/gg11/dirver/lock: created
Veridata Out-Of-Sync files /oracle/gg11/dirver/oos: created
Veridata Out-Of-Sync XML files /oracle/gg11/dirver/oosxml: created
Veridata Parameter files /oracle/gg11/dirver/params: created
Veridata Report files /oracle/gg11/dirver/report: created
Veridata Status files /oracle/gg11/dirver/status: created
Veridata Trace files /oracle/gg11/dirver/trace: created
Stdout files /oracle/gg11/dirout: created

GGSCI (gg1.localdomain) 2>

2. Configuração da porta de comunicação através do MANAGER

GGSCI (gg1.localdomain) 1> info all

Program Status Group Lag Time Since Chkpt

MANAGER STOPPED

GGSCI (gg1.localdomain) 2> edit params mgr
PORT 7889
GGSCI (gg1.localdomain) 7> start manager

Manager started.

GGSCI (gg1.localdomain) 8> info all

Program Status Group Lag Time Since Chkpt

MANAGER RUNNING

3. Configuração do checkpointtable e trandata.

Estarei explicando melhor o funcionamento do CHECKPOINT e TRANDATA em um outro momento, o importante agora saber é que precisamos executar essas duas rotinas nos dois servidores o GG1 (SOURCE) e o GG2 (TARGER). Aqui estarei demonstrando somente a execução do servidor GG1 porém ele deve ser executado nos dois.

GGSCI (gg1.localdomain) 1> dblogin userid goldengate
Password:
Successfully logged into database.
GGSCI (gg1.localdomain) 2> ADD CHECKPOINTTABLE goldengate.checkpoint

Successfully created checkpoint table GOLDENGATE.CHECKPOINT.

GGSCI (gg1.localdomain) 3> add trandata replica.*
Logging of supplemental redo data enabled for table REPLICA.TESTE.

Configuração a replicação

Nesse momento estaremos configurando os processos extract e dump do database source (GG1 do banco PONTA1). Para quem não se lembra (ou não ouviu falar) dos processos internos do GoldenGate não se preocupa, aqui expliquei resumidamente o funcionamento de cada um deles.

* Configuração SERVIDOR SOURCE (server GG1 do banco PONTA1)

1. Configuração do EXTRACT

GGSCI (gg1.localdomain) 1> ADD EXTRACT ext1, TRANLOG, BEGIN now

EXTRACT added.

GGSCI (gg2.localdomain) 2> ADD EXTTRAIL /oracle/gg11/dirdat/lt, EXTRACT ext1

EXTTRAIL added.

GGSCI (gg1.localdomain) 3> edit params ext1
-- Identifica o nome do extract
EXTRACT ext1
-- Informa o login requerido para o database.
USERID goldengate, PASSWORD oracle
-- Informa o local trail para o extract escrever
EXTTRAIL /oracle/gg11/dirdat/lt
GETTRUNCATES
--Mapeamento de todas as alterações de tabelas no usuário replica.
TABLE replica.*;
--Mapeamento de toda operação DDL do banco
DDL

GGSCI (gg1.localdomain) 4>

2. Configuração do PUMP

GGSCI (gg1.localdomain) 1> ADD EXTRACT pump1, EXTTRAILSOURCE /oracle/gg11/dirdat/lt, BEGIN now

EXTRACT added.

GGSCI (gg1.localdomain) 2> ADD RMTTRAIL /oracle/gg11/dirdat/rt, EXTRACT pump1

RMTTRAIL added.

GGSCI (gg1.localdomain) 3> edit params pump1

--Informa o data pump atual.
EXTRACT pump1
-- Especifíca o IP nome do servidor standby, no nosso caso o gg2. E também é informado o manager porta feito acima
RMTHOST 10.0.0.13, MGRPORT 7889
-- Specify the remote trail on the standby system:
RMTTRAIL /oracle/gg11/dirdat/rt
-- Transfere a data sem mapiamento, filtro ou conversão
PASSTHRU
GETTRUNCATES
--Mapeia o usuário replica
TABLE replica.*;

GGSCI (gg1.localdomain) 7> info all

Program Status Group Lag Time Since Chkpt

MANAGER RUNNING

EXTRACT STOPPED EXT1 00:00:00 00:07:46

EXTRACT STOPPED PUMP1 00:00:00 00:03:16

Nesse momento os dois principais processos de replicação do SERVIDOR SOURCE(extract e pump) estão configurados. Observe que através do comando info all é informado que eles ainda não estão em funcionamento (STOPPED). Vamos agora configura o SERVIDOR GG2 (database TARGET). O servidor de destino é mais simples configurar, somente temos que criar o processo REPLICAT. Veja logo abaixo fico fica:

* Configuração SERVIDOR TARGET (server GG2 do banco PONTA2)

1. Configuração do REPLICAT

GGSCI (gg2.localdomain) 1> add replicat rep1, exttrail /oracle/gg11/dirdat/rt, begin now, checkpointtable goldengate.checkpoint
REPLICAT added.

GGSCI (gg2.localdomain) 2> EDIT PARAMS rep1
-- Informa o replicat que estamos trabalhando
REPLICAT rep1
-- Assume que as definições do source e target database são identicos.
ASSUMETARGETDEFS
-- Usuário de conexão do GoldenGate
USERID goldengate, PASSWORD oracle
GETTRUNCATES
--Mapeia o usuário replica.
MAP replica.*, TARGET replica.*;
DDL

GGSCI (gg2.localdomain) 3 >

Agora sim … tudo configurado e pronto para usar. Nesse momento devemos estar com os processos da seguinte maneira:

Servidor SOURCE (Banco PONTA1, host GG1)

GGSCI (gg1.localdomain) 1> info all

Program     Status      Group       Lag           Time Since Chkpt

MANAGER     RUNNING
EXTRACT     STOPPED     EXT1        00:00:00      00:32:12
EXTRACT     STOPPED     PUMP1       00:00:00      00:27:43

Servidor TARGET (Banco PONTA2, host GG2)

GGSCI (gg2.localdomain) 1> info all

Program     Status      Group       Lag           Time Since Chkpt

MANAGER     RUNNING
REPLICAT    STOPPED     REP1        00:00:00      00:05:40

Testes da replicação

Vamos iniciar os processos primeiro no servidor SOURCE depois no servidor TARGET. 

Servidor SOURCE (Banco PONTA1, host GG1)

GGSCI (gg1.localdomain) 1> start er *

Sending START request to MANAGER ...
EXTRACT EXT1 starting

Sending START request to MANAGER ...
EXTRACT PUMP1 starting

GGSCI (gg1.localdomain) 2> info all

Program     Status      Group       Lag           Time Since Chkpt

MANAGER     RUNNING
EXTRACT     RUNNING     EXT1        00:00:00      00:33:58
EXTRACT     RUNNING     PUMP1       00:00:00      00:29:29

Servidor TARGET (Banco PONTA2, host GG2)

GGSCI (gg2.localdomain) 1> start er *

Sending START request to MANAGER ...
REPLICAT REP1 starting

GGSCI (gg2.localdomain) 2> info all

Program     Status      Group       Lag           Time Since Chkpt

MANAGER     RUNNING
REPLICAT    RUNNING     REP1        00:00:37      00:00:01

Agora a parte mais legal, ver o GoldenGate em trabalho e ver a incrível ferramenta que é, veja:

Servidor SOURCE (Banco PONTA1, host GG1)

SQL> select table_name from user_tables;

TABLE_NAME
------------------------------
TESTE

Servidor TARGET (Banco PONTA2, host GG2)

SQL> select table_name from user_tables;

TABLE_NAME
------------------------------
TESTE

Ok … temos nos dois bancos a tabela TESTE no usuário REPLICA, até ai tudo bem. Vamos fazer um teste de replicação de DDL, vou criar a tabela TESTE_2 com o usuário REPLICA no servidor SOURCE (GG1) e ele tem que se ser replicado automáticamente para o banco PONTA2 lá no servidor TARGET (GG2).

Servidor SOURCE (Banco PONTA1, host GG1)

[oracle@gg1 ~]$ sqlplus replica/oracle

SQL*Plus: Release 10.2.0.5.0 - Production on Sun Apr 24 10:49:16 2011

Copyright (c) 1982, 2010, Oracle.  All Rights Reserved.

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> !hostname
gg1.localdomain

SQL> create table teste_2 (
  2  id number primary key,
  3  nome varchar2(50)
  4  );

Table created.

Servidor TARGET (Banco PONTA2, host GG2)

[oracle@gg2 ~]$ sqlplus replica/oracle

SQL*Plus: Release 10.2.0.5.0 - Production on Sun Apr 24 10:50:55 2011

Copyright (c) 1982, 2010, Oracle.  All Rights Reserved.

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> !hostname
gg2.localdomain

SQL> desc teste_2
 Name					   Null?    Type
 ----------------------------------------- -------- ----------------------------
 ID					   NOT NULL NUMBER
 NOME						    VARCHAR2(50)
SQL> select * from teste_2;

no rows selected

Vimos aqui uma replicação realizada de DDL, criamos a tabela TESTE_2 no servidor SOURCE (GG1, database PONTA1) e ela foi criada no servidor TARGET (GG2, database PONTA2).

Observe que ela não tem nenhum dado contido, vamos fazer algumas inserções de dados na tabela TESTE_2 no servidor SOURCE e vamos ver se os dados foram transferidos para o servidor TARGET.

Servidor SOURCE (Banco PONTA1, host GG1)

SQL> show user
USER is "REPLICA"
SQL> !hostname
gg1.localdomain

SQL> insert into teste_2 values (1, 'Flavio');      

1 row created.

SQL> insert into teste_2 values (2, 'Soares');

1 row created.

SQL> insert into teste_2 values (3, 'GoldenGate');

1 row created.

SQL> commit;

Commit complete.

Servidor TARGET (Banco PONTA2, host GG2)

SQL> show user
USER is "REPLICA"
SQL> !hostname
gg2.localdomain

SQL> select * from teste_2;

	ID NOME
---------- --------------------------------------------------
	 1 Flávio
	 2 Soares
	 3 GoldenGate

Nesse post podemos ver a incrível ferramenta de replicação de dados que é o GoldenGate.

O mais impressionante é que com algumas pequenos ajustes, conseguimos trabalhar com versões diferentes entre bancos Oracle, ideal para aquelas migrações de versão onde não tem janela de parada disponível.

Com o GoldenGate também é possível migrar/replicar dados de diferentes plataformas, SqlServer para Oracle ou vice-versa, Mysql para Oracle ou vice-versa, DB2 para Oracle e vice-versa, etc …

Nos próximos posts estarei demonstrando outras funcionalidades da ferramenta … monitoramento, performance e outros atrativos.

Até lá …

Como GoldenGate trabalha?
May 10, 2011

GoldenGate

Como mostra a figura acima, esses são os principais processos e arquivos do Oracle GoldenGate, ele mostra também como é todo o processo de replicação realizado, que estarei explicando mais a frente.

O GoldenGate é composto pelos seguientes componentes

  • Manager
  • Extract
  • Data pump
  • Replicat
  • Trails files
  • Checkpoints
  • Collector

Manager
Manager é um processo do GoldenGate que desempenha a função de monitorar e restartar (quando necessário) os processos GoldenGate. Erros de eventos ou problemas de lentidão são reportados por ele e também desempenha a função de manter (período) os arquivos de trail e logs do GoldenGate.

Ele deve estar sendo executado em cada configuração GoldenGate antes dos processos Extract e Replicat serem iniciado.

Extract
Esse processo executa em cima do source database e tem a responsabilidade de caputrar os dados e gravar na forma de “trail files” que depois serão enviados para o target database.

Data Pump
Quando o extract escreve para um trail file no source database, o data pump lê esses trail´s e envia atráves de uma rede para o database de destino.

Replicat
Ao contrário do extract, o replicat executa em cima do target database. Ele lê os arquivos trail files enviados pelo Data Pump e então replica essas alterações seja ela DDL ou DML para o database de destino.

Trails files
Todas as mudanças realizadas pelo source database é registrados e armazenadas na forma de arquivos em series assim o GoldenGate é capaz de armazenar essas mudanças temporariamente no disco,
esses arquivos são chamados de trail. Um arquivo trail pode existir tanto no source como no target database.

Checkpoints
Checkpoints assegura que as mudanças feitas pelo database source sejam de certa forma sincronizados com a extração do processo Extract. Ele previne também a redundancia de execuções em ambientes bi-direcionais.

Através dele é permitido usar multiplos Extract e Replicat processos para ler o mesmo arquivo trail.

Collector
Quando o Data Pump envia as informações dos trails através da NetWork, o primeiro processo a lêr essa informação é o Collector, ele recebe as mudanças do database que são enviadas pelo TCP/IP e as escreves para os trails files. O processo manager é quem gerência o momento do Collector capturar os dados.

Em um próximo artigo sobre GoldenGate, estarei fazendo a instalação de uma replicação simples, de oracle para oracle.

Até mais