Oracle GoldenGate: Classic Capture vs. Integrated Capture
February 10, 2015

Classic Capture Mode

O extract quando configurado no modo Classic Capture, ele armazena todas as alterações feitas no objeto que você configurou para a sincronização. O Extract mantém a mudança até receber o commit ou rollback da transação. Quando um commit é recebido, o Extract armazena a mudança em forma de trail, ou seja, o Extract escanea os Redo Logsfiles (ou até mesmo archives caso precise) atrás de qualquer transação que realizou commit.

Limitações do Classic Capture Mode:

– Não é possível de utilizar certos datatypes:

  • IOT com mapping table
  • Direct load inserts para IOT tables
  • XML armazenado como binary
  • XMLTypes tables

– O Classic Capture mode não suporta qualquer tipo de compressão de dados:

  • Basic Compress
  • OLTP Compress
  • HCC

– Também não suporta Parallel DML nos Oracle RAC.


Integrated Capture

Presente no GoldenGate na versão 11.2, é chamado de Integrated (integrado) porque opera realmente integrado com o banco de dados Oracle, entendendo inclusive formatos internos como LCR (Logical Change Record), Logminer ou Streams.

Por trabalhar de forma integrada com o banco de dados Oracle, no modo Integrated Capture o RMAN mantém automaticamente todo archives necessários pelos processos Extract quando um processo de delete é executado, da mesma forma que acontece com o Oracle Dataguard.

Benefícios:

– Remove a maioria das limitações do modo Classico:

  • Basic e OLTP Compress é suportado.
  • HCC é suportado.
  • IOT são suportados sem qualquer limitação.
  • XML armazenado como binário.
  • O suporte ao Parallel DML no RAC é também suportado.
  • Point-in-time recovery.
  • Integração com Oracle RAC são também mais fáceis de trabalhar.

Limitações:

– SECUREFILELOBS são capturados do Redo logs somente quando o LOB não está comprimido, encripitado ou duplicado. Caso contrário, eles são capturados pelo tabela fonte.

– Trabalha somente entre banco de dados Oracle

– Os seguintes datatypes não são suportados:

  • ANYDATASET
  • ANYTYPE
  • BFILE
  • MLSLABEL
  • ORDDICOM
  • ROWID
  • TIMEZONE_ABBR
  • URITYPE
  • UROWID

O uso do Classic Capture e Integrated Capture não trabalham mutualmente exclusivos. No mesmo sistema uma coleção de tabelas pode ser replicadas via Classic Capture enquando outras podem ser replicadas via Integrated Capture. Com isso fica fácil, planejar o uso do Integrated Capture para tabelas Comprimidas, quando outras que não são comprimidas podem ser utilizadas via Classic Capture.

Um outro ponto importante, é que de acordo com a Oracle, os futuros relases do Goldengate para a replicação entre apenas os banco de dados Oracle, será entregue apenas via Integrated Capture, enquanto que o Classic Capture será a única alternativa para ambiente não Oracle.

Oracle Goldengate e Flashback Table Feature
September 12, 2013

O Oracle Flashback como você  já deve saber, é uma notável tecnologia capaz de visualizar os estados passados do seu banco de dados e permitir até voltar a esse passado sem a necessidade de utilizar o Point-in-Time Media Recovey.

Essa feature utiliza o Automatic Undo Management para obter o metadata e os históricos das transações, com ela você pode: executar consultas que retornam dados do passado, executar consultas que mostram um histórico de mudanças do seu banco de dados ou até mesmo recuperar dados perdidos de uma maneira rápida e entre outras coisas.

Existem vários tipos de Flashback, cada um para o que você precisa. Por exemplo caso deseje voltar sua tabela para um determinado SCN você deve utilizar o flashback table … to SCN; porém caso precise voltar a um determinado período você simplesmente utiliza o flashback table … to TIMESTAMP. 

Mais o que você provavelmente não sabe se essa tecnologia funciona com o Oracle Goldengate.

Pelo que notei o Goldengate trabalha sem qualquer problema utilizando as seguintes opções do FLASHBACK TABLE:

– FLASHBACK TABLE <table> TO RESTORE POINT

– FLASHBACK TABLE <table> TO TIMESTAMP

– FLASHBACK TABLE <table> TO SCN

Nos testes que fiz a única opção que ele não suporta é o FLASHBACK <table> TO BEFORE DROP. E obviamente ele também não suportou o FLASHBACK DATABASE.

Resolvendo o erro “libnnz10.so: cannot open shared object file” do Goldengate
May 24, 2013

Quando iniciado o utilitário ggsci do Oracle GoldenGate a seguinte mensagem de erro é disparada:

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

O erro acontece devida a falta de arquivos de shared libraries, ou mais conhecidos como shared objects que nada mais são do que bibliotecas compostas por muitas dependências carregadas por programas quando iniciados. No nosso caso, o utilitário do GoldenGate ggsci não consegue ser iniciado porque não encontrou a shared object chamada libnnz10.so.

Na maioria dos sistemas operacionais atuais, você pode apontar para diferentes bibliotecas de shared objects para uma particular execução do programa, no Linux por exemplo temos a variável de ambiente chamada LD_LIBRARY_PATH que define o destino onde os shared objects devem ser procuradas. Essa funcionalidade é disponível para outras arquiteturas também, em alguns casos mudasse apenas o nome da variável de ambiente:

IBM AIX -> LIBPATH
HP-UX -> SHLIB_PATH
Sun Solaris -> LD_LIBRARY_PATH
HP Tru64 -> LD_LIBRARY_PATH

Para conferir as dependências dinâmicas de um determinado programa, existe o comando ldd criado por Roland McGrath que informa as shared libraries requeridas por cada programa. Com esse comando, será possível entender o porque da mensagem de erro mostrada acima:

$ ldd ggsci 
	libdl.so.2 => /lib64/libdl.so.2 (0x00000037c7800000)
	libgglog.so => /u01/app/oracle/gg11/libgglog.so (0x00002ac9b503a000)
	libggrepo.so => /u01/app/oracle/gg11/libggrepo.so (0x00002ac9b5278000)
	libdb-5.2.so => /u01/app/oracle/gg11/libdb-5.2.so (0x00002ac9b53d0000)
	libicui18n.so.38 => /u01/app/oracle/gg11/libicui18n.so.38 (0x00002ac9b566b000)
	libicuuc.so.38 => /u01/app/oracle/gg11/libicuuc.so.38 (0x00002ac9b59cb000)
	libicudata.so.38 => /u01/app/oracle/gg11/libicudata.so.38 (0x00002ac9b5d05000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00000037c7c00000)
	libxerces-c.so.28 => /u01/app/oracle/gg11/libxerces-c.so.28 (0x00002ac9b6ce1000)
	libantlr3c.so => /u01/app/oracle/gg11/libantlr3c.so (0x00002ac9b71f9000)
	libnnz10.so => not found
	libclntsh.so.10.1 => not found
	libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00000037dae00000)
	libm.so.6 => /lib64/libm.so.6 (0x00000037c7400000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00000037d6e00000)
	libc.so.6 => /lib64/libc.so.6 (0x00000037c7000000)
	/lib64/ld-linux-x86-64.so.2 (0x00000037c6c00000)

Veja que as shared objects libnnz10.so e libclntsh.so.10.1 não foram encontradas pelo comando ldd, e é justamente elas o problema de iniciar o utilitário ggsci.

Como mencionei a LD_LIBRARY_PATH no Linux, especifica um destino alternativo para as shared libraries. Em um ambiente Oracle, todas as libs necessárias para executar a maioria dos programas Oracle como sqlplus, asmcmd, dbca e etc … encontra-se na pasta chamada lib dentro do próprio Oracle Home do banco de dados. Com isso, precisamos apenas apontar a variável LD_LIBRARY_PATH para onde essas shared libraries do Oracle encontra-se:

$ export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$LD_LIBRARY_PATH
$ echo LD_LIBRARY_PATH
/u01/app/oracle/product/10.2.0/db_1/lib:

Com a LD_LIBRARY_PATH definida, execute o ldd para checar novamente o utilitário do ggsci e ver que agora todas as dependências foram realizadas

[oracle@oracle10g gg11]$ ldd ggsci 
	libdl.so.2 => /lib64/libdl.so.2 (0x00000037c7800000)
	libgglog.so => /u01/app/oracle/gg11/libgglog.so (0x00002acde8b72000)
	libggrepo.so => /u01/app/oracle/gg11/libggrepo.so (0x00002acde8db0000)
	libdb-5.2.so => /u01/app/oracle/gg11/libdb-5.2.so (0x00002acde8f08000)
	libicui18n.so.38 => /u01/app/oracle/gg11/libicui18n.so.38 (0x00002acde91a3000)
	libicuuc.so.38 => /u01/app/oracle/gg11/libicuuc.so.38 (0x00002acde9503000)
	libicudata.so.38 => /u01/app/oracle/gg11/libicudata.so.38 (0x00002acde983d000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00000037c7c00000)
	libxerces-c.so.28 => /u01/app/oracle/gg11/libxerces-c.so.28 (0x00002acdea819000)
	libantlr3c.so => /u01/app/oracle/gg11/libantlr3c.so (0x00002acdead31000)
	libnnz10.so => /u01/app/oracle/product/10.2.0/db_1/lib/libnnz10.so (0x00002acdeae47000)
	libclntsh.so.10.1 => /u01/app/oracle/product/10.2.0/db_1/lib/libclntsh.so.10.1 (0x00002acdeb2e8000
	libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00000037dae00000)
	libm.so.6 => /lib64/libm.so.6 (0x00000037c7400000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00000037d6e00000)
	libc.so.6 => /lib64/libc.so.6 (0x00000037c7000000)
	/lib64/ld-linux-x86-64.so.2 (0x00000037c6c00000)
	libnsl.so.1 => /lib64/libnsl.so.1 (0x00000037cac00000)

Agora sim, com todas as shared objects encontradas e todas as suas dependencias resolvidas, podemos executar sem qualquer problema o comando ggsci para inicar as operações do Oracle Goldengate:

[oracle@oracle10g gg11]$ ./ggsci 

Oracle GoldenGate Command Interpreter for Oracle
Version 11.2.1.0.6 16211226 OGGCORE_11.2.1.0.6_PLATFORMS_130418.1829_FBO
Linux, x64, 64bit (optimized), Oracle 10g on Apr 18 2013 22:43:23

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



GGSCI (oracle10g.flaviosoares.local) 1> info all

Program     Status      Group       Lag at Chkpt  Time Since Chkpt

MANAGER     RUNNING                                           

GGSCI (oracle10g.flaviosoares.local) 2> 
Oracle Goldengate 11.2.1.0.3 disponível para Linux
October 10, 2012

Hoje procurando pelo download do Oracle Goldengate 11g, eis que sem querer descubro que um novo release foi liberado para Linux x86-64:

Compressão de dados com GoldenGate
July 14, 2012

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
Certificado “Oracle GoldenGate Specialist”
May 7, 2012

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

Oracle GoldenGate 11.1.1.1
May 17, 2011

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

 

Desconsiderando a retenção do RMAN
May 10, 2011

Em algumas situações, há a necessidade de guardar determinado backup além da retenção definida pelo RMAN.

Hoje em dia, existem leis que exigem que determinado backup seja armazenado por um tempo definido. É nesse momento que a desconsiderar a retenção do RMAN faz toda diferença.

No exemplo abaixo, estou demonstrado que o backup do dataflie 4 será armazenado em minha retenção do RMAN como 30 dias ignorando minha retenção padrão, o backup do datafile 4 só será considerada obsolete depois de 30 dias.

RMAN> backup datafile 4 keep until time "sysdate+30"; 

Starting backup at 07-APR-11
current log archived

using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=55 device type=DISK
backup will be obsolete on date 07-MAY-11
archived logs required to recover from this backup will be backed up
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00004 name=/oracle/oradata/orcl/users01.dbf
channel ORA_DISK_1: starting piece 1 at 07-APR-11
channel ORA_DISK_1: finished piece 1 at 07-APR-11
piece handle=/oracle/backup/ORCL_1_4.bkp tag=TAG20110407T222922 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01

using channel ORA_DISK_1
backup will be obsolete on date 07-MAY-11
archived logs required to recover from this backup will be backed up
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current SPFILE in backup set
channel ORA_DISK_1: starting piece 1 at 07-APR-11
channel ORA_DISK_1: finished piece 1 at 07-APR-11
piece handle=/oracle/backup/ORCL_1_5.bkp tag=TAG20110407T222922 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01

current log archived
using channel ORA_DISK_1
backup will be obsolete on date 07-MAY-11
archived logs required to recover from this backup will be backed up
channel ORA_DISK_1: starting archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=7 RECID=5 STAMP=747872969
channel ORA_DISK_1: starting piece 1 at 07-APR-11
channel ORA_DISK_1: finished piece 1 at 07-APR-11
piece handle=/oracle/backup/ORCL_1_6.bkp tag=TAG20110407T222922 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01

using channel ORA_DISK_1
backup will be obsolete on date 07-MAY-11
archived logs required to recover from this backup will be backed up
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current control file in backup set
channel ORA_DISK_1: starting piece 1 at 07-APR-11
channel ORA_DISK_1: finished piece 1 at 07-APR-11
piece handle=/oracle/backup/ORCL_1_7.bkp tag=TAG20110407T222922 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 07-APR-11

 

Veja que até os archives são guardados na retenção e também não são removidos caso seja requisitado a execução os archives obsoletos.
Agora, se você deseja deixar guardado somente o BACKUP ignorando os archives basta executar usar a palavra chave nologs, ou seja ele permite no entando, que o RMAN remova os archives logs que seriam necessário para recuperar o backup.

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

Oracle GoldenGate
May 10, 2011

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.