Oracle GoldenGate – Parte I

Neste artigo será apresentado os conceitos básicos sobre o Oracle GoldenGate, detalhes da sua arquitetura e algumas dicas. Como existem muitos artigos que contém quase sempre as mesmas informações, neste apresentaremos além do “feijão com arroz de todos os dias”, um conteúdo adicional diferenciado:

Parte I: Introdução e arquitetura;

Parte II: Comandos para monitoração e troubleshooting com logdump;

Parte III: Certificação e Dicas.

PARTE I: Introdução e arquitetura

BREVE HISTÓRIA

No final dos anos 80, uma pequena empresa de software chamada GoldenGate criou um método diferente de replicar dados entre plataformas de banco de dados. Antes de sua existência, a replicação de dados entre plataformas e fornecedores era, na melhor das hipóteses problemática, devido a necessidade de desenvolver códigos muito complexos. A GoldenGate inventou uma maneira poderosa e inovadora de replicar dados e, ao mesmo tempo, atingir alto desempenho com precisão.

Além disso, a ferramenta GoldenGate fornece um método transparente para executar a replicação de dados em tempo real com consistência e integridade garantida entre ambientes heterogêneos.

A Oracle adquiriu a empresa GoldenGate em 2009 como parte da futura estratégia para implementar tecnologias de replicação dentro do conjunto de produtos de data warehousing e transações em tempo real. Anteriormente, a replicação de dados era realizada usando o Oracle Streams e soluções de replicação de terceiros, como o Quest SharePlex.

O QUE É O ORACLE GOLDENGATE?

O Oracle GoldenGate é uma ferramenta poderosa de replicação lógica de dados, no nível transacional, entre várias plataformas de banco de dados e sistemas operacionais heterogêneas. Embora seja um produto Oracle, é possível utilizar o GoldenGate com diversos outros SGBDs (Sistema Gerenciador de Banco de Dados), como por exemplo: replicar dados do Oracle para SQL Server, ou ainda, quando nenhum dos SGBDs é Oracle, como: origem MySQL e destino DB2, além de permitir replicações para ambientes Big Data, como: Hadoop, Kafka, Hive, Hbase, entre outros.

Sua arquitetura modular oferece a flexibilidade de extrair e replicar dados transacionais utilizando recursos de filtro e transformação de dados, além de comandos DDL em diversas topologias. Desta forma permitindo oferecer suporte a vários requisitos de negócios:

• Continuidade de negócios e alta disponibilidade;
• Carregamento inicial (Initial Load) e migração de banco de dados;
• Integração de dados;
• Suporte à decisão e armazenamento de dados.
  
  

Na figura a seguir, estão as principais topologias utilizadas pelo GoldenGate, lembrando que sempre existirá pelo menos um ambiente de origem e um ambiente de destino:

• Unidirecional: A replicação ocorre em uma única direção, da origem para o destino (Replicação Ativo-Passivo);
  
  
• Bidirecional: A replicação ocorre em ambas as direções, também chamado de replicação Ativo-Ativo, os ambientes são origem e destino ao mesmo tempo;
  
  
• Ponto a Ponto: Também chamada de multidirecional, é parecida com o bidirecional, porém, possui mais de 2 ambientes origem e destino;
  
  
• Broadcast: Parecida com a topologia o unidirecional, porém com mais de um destino;
  
  
• Consolidação: Parecida com o unidirecional, porém com várias origens apontando para o mesmo destino;
  
  
• Distribuição: Parecida com o broadcast, porém, recebendo dados de outro lugar, normalmente não sendo um SGBD, (veremos mais adianta o conceito de Adapters).
  
  

O Oracle GoldenGate é uma ferramenta muito poderosa, e pode ser configurada para os seguintes propósitos:

• Extração estática de dados de um banco de dados para serem carregados em outro banco de dados;
  
  
• Extração e replicação contínuas de operações transacionais utilizando DML e DDL em tempo real e com baixo impacto na performance, para manter os dados de origem e de destino consistentes;
  
  
• Extração dos dados de um banco de dados para um arquivo (flat file) fora do banco de dados.
  
  

O Oracle GoldenGate é composto pelos seguintes componentes:

• Extract
• Data pump
• Replicat
• Trails files
• Checkpoints
• Manager
• Collector
• Wallet & CredentialStore
  
  

A seguir será apresentada uma breve descrição de cada um destes componentes:

• Extract: É o processo responsável pela extração (captura) dos dados executado no ambiente de origem, também chamado de extract primário;
  
  
• Data Pump: É um processo opcional, porém muito recomendado, também chamado de extract secundário. Em uma configuração típica, o extract (primário) captura as transações e armazena em um arquivo local. Em seguida, o processo Data Pump (extract secundário) lê estes arquivos e envia as transações para um arquivo remoto no destino. Quando não utilizado, o extract primário envia os dados diretamente para o destino;
  
  
• Replicat: É o processo responsável por aplicar no destino as transações que foram capturadas na origem;
  
  
• Trail Files: É o arquivo onde as transações são armazenadas fisicamente, quando gerado na origem é chamado de trail local e no destino é chamado de trail remoto;
  
  
• Checkpoints: São mecanismos responsáveis por garantir os pontos de captura, transferência e aplicação das transações entre os ambientes de origem e destino, para que em caso de falha em algum dos processos, o GoldenGate saiba onde parou e reinicia exatamente deste último ponto;
  
  
• Manager: É o processo responsável por gerenciar todos os outros processos do GoldenGate, devendo estar sempre em execução em todos os ambientes envolvidos na replicação;
  
  
• Collector: É o processo responsável por receber as transações no ambiente de destino e salvar nos arquivos de trail remoto. Este processo é iniciado automaticamente quando o data pump está sendo utilizado.
  
  
• Wallet & CredentialStore: São novos recursos da versão 12c, o wallet é utilizado para gerenciamento das chaves de criptografia, e o credentialstore é utilizado para o gerenciamento de logins onde um alias é criado substituindo a necessidade de utilizar usuário e senha nos arquivos de configuração, e login no banco de dados  através do GGSCI.
  
  

O Oracle GoldenGate também possui uma interface de prompt de comandos chamada GoldenGate Software Command Interface (GGSCI). Os comandos do GGSCI são usados para criar configurações de replicação do GoldenGate, além de executar tarefas de administração e monitoração. Na figura abaixo, veremos os comandos “info all” para visualizar todos os processos daquela instalação do GoldenGate e o “info <nome do processo>” para verificar detalhes de um processo específico.

O Oracle GoldenGate é uma ferramenta muito versátil, com várias formas de implementação e configurações, entretanto, é muito importante sempre seguir as melhores práticas e recomendações da Oracle. Uma boa dica é implementar uma padronização com o nome dos processos, que deve ter apenas 8 caracteres, e arquivos de trail file com 2 posições, como por exemplo, utilizando alguma nomenclatura no nome dos processos.

– EXTxxxxx, para o processo Extract

– PMPxxxxx, para o processo Data Pump

– REPxxxxx, para o processo Replicat

– dx, para os arquivos de trail

Um detalhe interessante na figura anterior é o nome dos trail files, veja que um está com o nome maior que o outro. Por que será? Olhando para o nome do processo já é possível ter uma pista.

Na versão 11g do GoldenGate, os trail files possuíam uma sequência de 6 dígitos após os 2 caracteres de identificação. Já na versão 12c, isso foi melhorado e agora os trail files possuem 9 dígitos, isso significa que é possível ter mais quantidade de arquivos trail na versão 12c do que na 11g, ou seja, os dígitos são a quantidade de arquivos de trail que podem ser gerados.

Outra novidade na versão 12c é o tamanho do arquivo, o default agora é 500M. Na versão 11g o tamanho default é de apenas 100M.

LOGDUMP

O Logdump é uma ferramenta muito poderosa para realização de troubleshooting no Oracle GoldenGate. As informações que estão armazenadas nos arquivos de trail só podem ser lidas com o logdump.

No exemplo abaixo, podemos visualizar as informações de uma transação que foi realizada no banco de dados, capturada pelo GoldenGate e armazenada no trail file. Em destaque, podemos verificar algumas informações como:

Data e horário da transação...............: 2018/09/17 00:01:51.000.000 
Tipo de transação.........................: Insert 
Nome da tabela............................: REP_OGG_SOURCE12C.TAB_REPLICA_12C_01 
Tamanho do registro.......................: Len 74 
Posições da transação dentro do trailfile.: RBA 2198

ORACLE GOLDENGATE   v.s.  ORACLE ACTIVE DATAGUARD

Muitas vezes é levantada a questão sobre qual ferramenta utilizar para um cenário de Disater Recovery, Replicação ou mesmo StandBy, principalmente quando o objetivo de ter uma cópia do banco de dados em outro local é apenas para realizar consultas, sem qualquer alteração nos dados. A seguir serão apresentadas algumas diferenças e qualidades entre o GoldenGate e o Active Data Guard (ADG). A licença do Oracle GoldenGate inclui uma licença integral para usar o Active Data Guard.

Quando uso o Oracle Active Data Guard?

O Active Data Guard pode ser utilizado onde a ênfase está na simplicidade, melhor proteção de dados, disponibilidade de dados e maior desempenho:

• Replicação física e segura, o banco de dados standby sempre estará aberto, porém apenas para leitura (read-only), e nenhuma modificação é possível independentemente das transações realizadas no banco de dados de origem (primary).

• Replicação simples, rápida e unidirecional de um banco de dados Oracle completo. Não há a necessidade de habilitar o supplemental logging, nem problemas de performance com tabelas que não possuem primary key ou unique key. Normalmente não é necessário realizar ajustes de performance no banco de dados standby, a configuração padrão (como está na origem) já é o suficiente.

• Transparência de backups – é possível realizar backup tanto no ambiente primary como no standby do Data Guard, sendo estas cópias fisicamente exatas entre si.

• Suporta todos os recursos do Oracle e replica transparentemente todos os tipos de dados e armazenamento, pacotes PL/SQL e DDL sem considerações especiais.
  
  
  

Quando uso o Oracle GoldenGate?

O Oracle GoldenGate pode ser utilizado quando um banco de dados precisar estar aberto para leitura e gravação enquanto a replicação estiver ativa ou para requisitos avançados de replicação além do que é abordado pelo Active Data Guard:

• Quaisquer necessidades de replicações avançadas, como: replicação multimaster e bidirecional, consolidação, replicação cross endian e transformações de dados.

• Migrações de banco de dados quando é necessária uma parada mínima do ambiente (Near-zero downtime).

• Qualquer migração de plataforma não suportada pelo Data Guard (por exemplo, migração de plataforma cross endian)

• Qualquer replicação que seja necessário replicar de uma versão mais recente do Oracle Database para uma versão anterior do Oracle Database (por exemplo, do Oracle Database 11g para o Oracle Database 10g).

Confira clicando aqui como monitorar e saber o que está acontecendo no seu ambiente

Oracle GoldenGate – Parte II

Quer se tornar um especialista em GoldenGate? Faça o Treinamento na GoldenGateBR:

Treinamento Oracle GoldenGate – Módulo I

Treinamento Oracle GoldenGate – Módulo II

Forte abraço a todos!!

Acesse nossos outros posts clicando aqui ou acesse e se inscreva em nosso canal

Gilson Martins