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, GoldenGate fornece um método transparente para executar a replicação de dados em tempo real com consistência de transação garantida entre ambientes heterogêneos.
A Oracle adquiriu a 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.
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
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.
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 novas 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, é sempre muito importante 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 trafiles, 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 trailfiles 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ções que foi realizada no banco de dados, capturada pelo goldengate e armazenada no trailfile. 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 x 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). É importante lembrar que para utilização do Active Data Guard (com a base standby aberta para leitura) é necessário ter o devido licenciamento, e a aquisição desta licença também permite a utilização do GoldenGate.
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 necessidade 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).
Aprenda mais sobre GoldenGate em nosso treinamento:
Fontes:
GoldenGate Administering Oracle GoldenGate for Windows and UNIX
Expert Oracle GoldenGate
