
Oracle GoldenGate oferece a compressão de dados, melhorando assim a taxa de transferência a nível de network, otimizando em muito a movimentação do seu arquivo de trail para o destino.
Com menos gigabytes para transferir, mais velocidade na sincronização do seu ambiente! É com esse conceito que a Oracle fornece o mecanismo de compressão dos arquivos de trail, que uma vez configurado faz automaticamente a descompressão antes de escrever para os arquivos remotos.
Como nem tudo são flores, com o uso de compressão de dados pelo GoldenGate é possível que se tenha um uso adicional de CPU no processo de compressão, descompressão e comparação de dados. Tenho que dizer que em testes feitos, pude perceber uma melhora muito grande na utilização na taxa de transferência comparada a um aumento mínimo de utilização de CPU.
Aqui está um exemplo de um arquivo de parâmetro do Data Pump utilizando a opção COMPRESS:
EXTRACT EPUMP1 PASSTHRU RMTHOST gg2, MGRPORT 7889, COMPRESS RMTTRAIL ./dirdat/e1
Agora você precisa ter uma ideia de quanto o GoldenGate está utilizando de CPU para a compressão de dados e isso é possível através do GETTCPSTATS. Está opção é utilizada para obter estatísticas detalhadas da utilização de rede e das taxas (ratio) de compressões feitas pelo GoldenGate.
GGSCI (gg1) 1> send EXTRACT EPUMP1, GETTCPSTATS
Sending GETTCPSTATS request to EXTRACT EPUMP1 ...
RMTTRAIL ./dirdat/e1000872, RBA 383647567
Stats started 2012/07/14 11:00:19
Inbound Msgs 12423 Bytes 14442, 228 bytes/second
Outbound Msgs 12424 Bytes 33015318, 11916 bytes/second
Recvs 2351
Sends 6479
Avg bytes per recv 6, per msg 12
Avg bytes per send 1267, per msg 1267
Recv Wait Time 3473452, per msg 234, per recv 894
Send Wait Time 34636634, per msg 222, per send 222
Data compression is enabled
Compress CPU Time 0:00:00.000000
Compress time 0:00:08.0346223, Threshold 512
Uncompressed bytes 346347345
Compressed bytes 34635756, 45746856 bytes/second
Olá Pessoal!
Venho útimamente estudando muito Oracle GoldenGate, através de livros, documentos oficiais e não oficiais, tenho aprendido muita coisa com essa ferramente, apesar de pouco documento e livros bons tenho conseguido ir bem, realmente GoldenGate é fantastico, junto com a SUN a empresa GoldenGate foi uma das melhores aquisições feitas pela Oracle nos últimos anos.
Com toda essa dedicação ao GoldenGate, prestei na última sexta a prova Iz0-539 e assim obtive o certificado: “Oracle GoldenGate 10g Certified Specialist”. A prova não foi muito fácil, tanto que o meu score não foi lá aquelas coisas mais foi o suficiente para passar
Apesar de ser uma ferramente incrível, existem poucos especialistas pelo mundo que compartilham informação sobre ele, temos poucos materiais/post/tutoriais pela internet e hoje muito pouco livros existem por aí no mercado. Com isso, pretendo compartilhar muito sobre GoldenGate aqui no blog mostrando diversos assuntos como: implementação, tuning, proccess, director, veridata, migração, replicação heterogenia e etc …
Estou muito feliz com mais essa conquista e de poder compartilhar com vocês.
Abraços
Depois de uma grande espera …
É liberado o release 11.1.1.1 do Oracle GoldenGate, que pode ser feito o download em https://edelivery.oracle.com.
Uma das grandes novidades é o suporte a tablespaces encrypted … confira o restante das novidades na documentação oficial http://download.oracle.com/docs/cd/E22355_01/index.htm
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 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
O que é Oracle GoldenGate?
O produto promove a integração rápida de dados em TEMPO REAL e disponibilidade contínua (24×7) dos dados para sistemas de missão crítica. Atualmente, mais de 5.000 clientes utilizam as tecnologias de integração de dados da Oracle.
Sem parar?
Oracle GoldenGate permite replicar dados em tempo real e disponibilidade contínua de aplicativos. A movimentação de dados é feita em tempo real entre sistemas heterogêneos de origem e destino.
Oracle GoldenGate é um produto comprado pela Oracle em 2009, que permite a transferir dados gerados de um banco A para um banco B, ou até mesmo ao contrário tudo que for gerado no banco B ser transferido para o banco A, isso tudo em tempo real.
Aquele seu banco MYSQL, que já cresceu e você deseja migrar para um banco Oracle também é possível. O Oracle GG migra seu banco de dados inteiro, sem parar, sem tempo de janela, tudo online de quase qualquer RDBMS disponível no mercado para Oracle.
A algum tempo venho estudando essa incrível ferramenta e estarei colocando aqui … conceitos, instalações, configurações e muito mais …
A baixo somente um overview do conceito do GoldenGate.





