🔒 BloqueadoMÓDULO 01Pendente
A Nova Era da Replicação
Entenda como o Oracle GoldenGate captura, transporta e aplica mudanças com baixa latência, além de conhecer a função de cada serviço da arquitetura Microservices.
ORACLE GOLDENGATE • MICROSERVICES • DATA REPLICATION
Oracle GoldenGate 26aiEnterprise Academy
Da arquitetura Microservices à operação de ambientes de missão crítica. Uma trilha prática para instalação, configuração, segurança, replicação, monitoramento, diagnóstico e performance.
Domine replicação de dados em nível Enterprise
Uma formação prática baseada em arquitetura, instalação, segurança, captura, replicação, monitoramento, diagnóstico e performance. Identifique-se para liberar os módulos e acompanhar sua evolução.
TRILHA DE APRENDIZAGEM
Módulos da formação
Conteúdo técnico, laboratório e resultado esperado.
🔒 Bloqueado
🔒 BloqueadoMÓDULO 02Pendente
Instalação e Configuração no Oracle Linux
Prepare o sistema operacional, organize os diretórios e instale o GoldenGate Microservices com um padrão adequado para ambientes corporativos.
🔒 BloqueadoMÓDULO 03Pendente
Preparação do Oracle Database
Configure o banco de origem para fornecer todas as informações necessárias à captura e prepare usuários administrativos com privilégios controlados.
🔒 BloqueadoMÓDULO 04Pendente
Bancos e Segurança Avançada
Aplique um modelo seguro de credenciais e prepare Oracle, PostgreSQL e MySQL para replicação controlada.
🔒 BloqueadoMÓDULO 05Pendente
Conexões Seguras e Protocolos
Construa conexões confiáveis entre GoldenGate e bancos, usando aliases, serviços corretos e validações de rede.
🔒 BloqueadoMÓDULO 06Pendente
Criação e Parametrização do Extract
Crie um Extract integrado, registre-o no banco e configure trails, objetos capturados e parâmetros de desempenho.
🔒 BloqueadoMÓDULO 07Pendente
Replicação Homogênea e Heterogênea
Implemente aplicação Oracle-to-Oracle e compreenda os ajustes necessários quando origem e destino utilizam tecnologias diferentes.
🔒 BloqueadoMÓDULO 08Pendente
Arquiteturas Avançadas
Desenhe topologias resilientes e escaláveis, evitando loops, conflitos e concentração de carga.
🔒 BloqueadoMÓDULO 09Pendente
Gestão, Monitoramento e Diagnóstico
Monitore a saúde operacional, detecte lag antes do impacto e organize evidências para troubleshooting.
🔒 BloqueadoMÓDULO 10Pendente
OGG Healthcheck Script
Execute uma avaliação estruturada do ambiente, consolide configurações e identifique riscos antes que se tornem incidentes.
🔒 BloqueadoMÓDULO 11Pendente
Otimização de Performance
Identifique gargalos no pipeline e aplique ajustes mensuráveis sem comprometer consistência.
🔒 BloqueadoMÓDULO 12Pendente
Laboratório Final Integrado
Consolide a formação criando um fluxo completo de replicação, observando seu comportamento e documentando a entrega.
Módulo 01
A Nova Era da Replicação
Fundamentos, arquitetura Microservices e estratégia de dados em tempo real
FORMAÇÃO ENTERPRISE
A Nova Era da Replicação
Entenda como o Oracle GoldenGate captura, transporta e aplica mudanças com baixa latência, além de conhecer a função de cada serviço da arquitetura Microservices.
Abrir apostila original em PDF ↗Competências desenvolvidas
- ✓Diferenciar arquitetura Classic e Microservices
- ✓Explicar o fluxo ponta a ponta de uma transação
- ✓Identificar os serviços administrativos e de transporte
- ✓Relacionar GoldenGate a HA, migração e integração de dados
Critério de conclusão
Leia as explicações, execute os comandos no simulador, compare o resultado esperado e confirme o laboratório.
Resultado esperado
Todos os serviços devem estar RUNNING e o deployment deve aparecer disponível para administração.
1. Por que replicação baseada em log?
A captura baseada nos redo logs reduz impacto na aplicação porque evita consultas contínuas às tabelas. O Extract interpreta as alterações confirmadas e as transforma em registros portáveis nos trail files.
2. Arquitetura Microservices
Service Manager centraliza o ciclo de vida dos deployments. Administration Service gerencia processos, Distribution Service transporta trails, Receiver Service recebe dados e Performance Metrics Service expõe métricas operacionais.
3. Fluxo transacional
Uma alteração confirmada no banco de origem percorre Redo/Archive → Extract → Local Trail → Distribution → Receiver → Remote Trail → Replicat → banco de destino. Checkpoints garantem retomada consistente após falhas.
Visão do fluxo
Oracle Source
→
Redo / Archive
→
Integrated Extract
→
Local Trail
→
Distribution
→
Receiver
→
Remote Trail
→
Replicat
→
Target
Representação didática para apoiar o entendimento da sequência operacional deste módulo.
Laboratório prático
10 comandos e verificações para praticar o conteúdo.
INFO ALLExplicação técnica do comando
O que este comando faz: Apresenta uma visão consolidada dos grupos GoldenGate conhecidos pelo deployment, incluindo Extracts e Replicats, seus estados e o lag registrado no último checkpoint.
Como interpretar e aplicar: É um dos primeiros comandos de triagem operacional. Processos RUNNING indicam atividade, mas a saúde real exige verificar se checkpoints avançam, se o lag permanece estável e se não existem mensagens de erro nos report files. STOPPED pode ser planejado; ABENDED indica encerramento anormal e demanda investigação imediata.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
INFO DEPLOYMENTExplicação técnica do comando
O que este comando faz: Exibe informações de configuração e execução do objeto solicitado, permitindo confirmar existência, tipo, checkpoint, trail associado e estado atual.
Como interpretar e aplicar: Use a saída para comparar a configuração ativa com o desenho esperado. Em processos de captura ou aplicação, observe posição de leitura, horário do checkpoint e parâmetros vinculados. Diferenças entre o cadastro e a documentação podem indicar alteração não controlada ou implantação incompleta.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
STATUS SERVICE MANAGERExplicação técnica do comando
O que este comando faz: Consulta o estado operacional do serviço ou processo indicado, mostrando se ele está disponível para atender requisições.
Como interpretar e aplicar: Um estado RUNNING confirma que o componente iniciou, mas não garante conectividade com banco, ausência de lag ou capacidade de processar carga. A validação completa inclui logs, métricas, conectividade e testes ponta a ponta.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
STATUS ADMINISTRATION SERVICEExplicação técnica do comando
O que este comando faz: Consulta o estado operacional do serviço ou processo indicado, mostrando se ele está disponível para atender requisições.
Como interpretar e aplicar: Um estado RUNNING confirma que o componente iniciou, mas não garante conectividade com banco, ausência de lag ou capacidade de processar carga. A validação completa inclui logs, métricas, conectividade e testes ponta a ponta.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
STATUS DISTRIBUTION SERVICEExplicação técnica do comando
O que este comando faz: Consulta o estado operacional do serviço ou processo indicado, mostrando se ele está disponível para atender requisições.
Como interpretar e aplicar: Um estado RUNNING confirma que o componente iniciou, mas não garante conectividade com banco, ausência de lag ou capacidade de processar carga. A validação completa inclui logs, métricas, conectividade e testes ponta a ponta.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
STATUS RECEIVER SERVICEExplicação técnica do comando
O que este comando faz: Consulta o estado operacional do serviço ou processo indicado, mostrando se ele está disponível para atender requisições.
Como interpretar e aplicar: Um estado RUNNING confirma que o componente iniciou, mas não garante conectividade com banco, ausência de lag ou capacidade de processar carga. A validação completa inclui logs, métricas, conectividade e testes ponta a ponta.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
STATUS PERFORMANCE METRICS SERVICEExplicação técnica do comando
O que este comando faz: Consulta o estado operacional do serviço ou processo indicado, mostrando se ele está disponível para atender requisições.
Como interpretar e aplicar: Um estado RUNNING confirma que o componente iniciou, mas não garante conectividade com banco, ausência de lag ou capacidade de processar carga. A validação completa inclui logs, métricas, conectividade e testes ponta a ponta.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
VIEW GLOBALSExplicação técnica do comando
O que este comando faz: Executa uma operação administrativa ou uma validação relacionada ao conteúdo deste módulo.
Como interpretar e aplicar: O resultado deve ser analisado em conjunto com o estado dos processos, checkpoints, logs e dependências da arquitetura, pois um retorno isolado não comprova que todo o fluxo de replicação está saudável.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
SHOW DEPLOYMENTExplicação técnica do comando
O que este comando faz: Executa uma operação administrativa ou uma validação relacionada ao conteúdo deste módulo.
Como interpretar e aplicar: O resultado deve ser analisado em conjunto com o estado dos processos, checkpoints, logs e dependências da arquitetura, pois um retorno isolado não comprova que todo o fluxo de replicação está saudável.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
GET /services/v2/deploymentsExplicação técnica do comando
O que este comando faz: Consulta um endpoint REST da arquitetura Microservices para obter informações estruturadas sobre deployments, serviços ou recursos administrativos.
Como interpretar e aplicar: A resposta HTTP ajuda a validar disponibilidade, autenticação e conteúdo retornado pela API. Códigos 2xx indicam sucesso; 401/403 apontam autenticação ou autorização; 404 pode indicar endpoint ou versão incorreta; 5xx exige análise do serviço e de seus logs.
Cuidados antes da execução: Evite usar -k em produção, pois ele ignora a validação do certificado TLS. Prefira certificados confiáveis, armazenamento seguro de credenciais e tokens ou mecanismos de autenticação compatíveis com a política da empresa.
Checklist de conclusão
Módulo 02
Instalação e Configuração no Oracle Linux
Pré-requisitos, instalação silenciosa, OGGCA, deployments e systemd
FORMAÇÃO ENTERPRISE
Instalação e Configuração no Oracle Linux
Prepare o sistema operacional, organize os diretórios e instale o GoldenGate Microservices com um padrão adequado para ambientes corporativos.
Abrir apostila original em PDF ↗Competências desenvolvidas
- ✓Validar CPU, memória, swap e filesystem
- ✓Separar software, configuração e dados
- ✓Executar instalação gráfica ou silenciosa
- ✓Criar deployment e automatizar inicialização
Critério de conclusão
Leia as explicações, execute os comandos no simulador, compare o resultado esperado e confirme o laboratório.
Resultado esperado
Service Manager ativo, deployment acessível por HTTPS e diretórios separados para configuração, dados e software.
1. Planejamento de diretórios
Separe OGG_HOME, OGG_VAR_HOME e OGG_ETC_HOME. Isso simplifica patching, backup, rollback e manutenção, pois o binário pode ser atualizado sem remover configurações, wallets, trails ou relatórios.
2. Pré-requisitos do Linux
Valide resolução de nomes, relógio, limites do usuário, espaço, bibliotecas e portas. Em produção, documente dependências e evite instalar o software em filesystems temporários ou sem monitoramento.
3. Deployment e serviços
O OGG Configuration Assistant cria Service Manager e deployments. Para inicialização automática, registre o Service Manager no systemd e valide que todos os serviços retornam após reboot.
Visão do fluxo
OS Validation
→
Directories
→
Software Install
→
OGGCA
→
Service Manager
→
Deployment
→
Health Check
Representação didática para apoiar o entendimento da sequência operacional deste módulo.
Laboratório prático
10 comandos e verificações para praticar o conteúdo.
sudo dnf update -yExplicação técnica do comando
O que este comando faz: Atualiza o sistema ou instala pacotes de sistema operacional necessários ao GoldenGate e às bibliotecas utilizadas pelo produto.
Como interpretar e aplicar: O gerenciador DNF resolve dependências e registra os pacotes instalados. Antes de atualizar servidores corporativos, verifique compatibilidade do kernel e das bibliotecas, repositórios habilitados e necessidade de reinicialização.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
sudo dnf install -y oracle-database-preinstall-23ai unzip libnslExplicação técnica do comando
O que este comando faz: Atualiza o sistema ou instala pacotes de sistema operacional necessários ao GoldenGate e às bibliotecas utilizadas pelo produto.
Como interpretar e aplicar: O gerenciador DNF resolve dependências e registra os pacotes instalados. Antes de atualizar servidores corporativos, verifique compatibilidade do kernel e das bibliotecas, repositórios habilitados e necessidade de reinicialização.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
sudo useradd -m -g oinstall -G dba oggExplicação técnica do comando
O que este comando faz: Cria o usuário de sistema operacional que será responsável pela instalação e operação do GoldenGate.
Como interpretar e aplicar: A separação do usuário de serviço reduz exposição e facilita auditoria. Os grupos atribuídos controlam acesso a arquivos e recursos Oracle; portanto, devem seguir o princípio do menor privilégio e o padrão definido pela equipe de infraestrutura.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
sudo mkdir -p /u01/app/ogg/26.1.0 /u02/ogg/{etc,var,data}Explicação técnica do comando
O que este comando faz: Cria a estrutura de diretórios usada para separar binários, configuração, dados variáveis, trails, logs e arquivos administrativos.
Como interpretar e aplicar: Essa separação melhora patching, backup, monitoramento de espaço e recuperação. O filesystem de trails deve ter capacidade, desempenho e alertas adequados, porque seu esgotamento pode interromper captura ou distribuição.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
sudo chown -R ogg:oinstall /u01/app/ogg /u02/oggExplicação técnica do comando
O que este comando faz: Ajusta proprietário e grupo dos diretórios para que o usuário GoldenGate consiga gravar configurações, logs, checkpoints e trail files.
Como interpretar e aplicar: Permissões incorretas normalmente causam falhas de inicialização ou erros de escrita. Evite permissões amplas como 777; valide proprietário, grupo e modo de acesso conforme a política de segurança.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
ulimit -n 65536Explicação técnica do comando
O que este comando faz: Define ou consulta o limite de descritores de arquivos disponíveis para a sessão do usuário.
Como interpretar e aplicar: GoldenGate pode manter vários trails, sockets e arquivos de relatório abertos. Limites baixos provocam falhas intermitentes sob carga. Para persistência, configure os limites no mecanismo do sistema operacional e valide na sessão efetiva do serviço.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
./runInstaller -silent -responseFile /tmp/oggcore.rsp -waitforcompletionExplicação técnica do comando
O que este comando faz: Executa a instalação silenciosa do software GoldenGate usando um arquivo de respostas previamente preparado.
Como interpretar e aplicar: O modo silencioso torna a instalação reproduzível e adequado à automação. O response file precisa conter ORACLE_HOME, grupo de instalação e opções corretas. Após a execução, revise logs do instalador e inventário Oracle antes de avançar.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
${OGG_HOME}/bin/oggca.sh -silent -responseFile /tmp/oggca.rspExplicação técnica do comando
O que este comando faz: Executa o GoldenGate Configuration Assistant para criar ou alterar Service Manager e deployments Microservices.
Como interpretar e aplicar: O OGGCA define portas, diretórios, credenciais administrativas, certificados e integração com o sistema operacional. Uma configuração incorreta pode gerar conflito de portas ou deployment inacessível; revise o response file e os logs gerados.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
sudo systemctl enable OracleGoldenGateExplicação técnica do comando
O que este comando faz: Gerencia o serviço do GoldenGate no systemd, permitindo habilitar inicialização automática e verificar seu estado no Linux.
Como interpretar e aplicar: O comando enable cria a associação para iniciar no boot; status mostra PID, estado e mensagens recentes. Confirme que o unit file aponta para os caminhos corretos e que o serviço retorna após reinicialização controlada.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
sudo systemctl status OracleGoldenGateExplicação técnica do comando
O que este comando faz: Gerencia o serviço do GoldenGate no systemd, permitindo habilitar inicialização automática e verificar seu estado no Linux.
Como interpretar e aplicar: O comando enable cria a associação para iniciar no boot; status mostra PID, estado e mensagens recentes. Confirme que o unit file aponta para os caminhos corretos e que o serviço retorna após reinicialização controlada.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
sudo ./registerServiceManager.sh /u02/ogg/etc/confExplicação técnica do comando
O que este comando faz: Registra o Service Manager como daemon do systemd, apontando para o diretório de configuração gerado pelo OGGCA durante a implantação.
Como interpretar e aplicar: É executado uma única vez, como root, logo após a criação do Service Manager pelo assistente gráfico ou silencioso. O script fica disponível em $OGG_HOME/bin assim que o Service Manager é criado.
Cuidados antes da execução: Confirme o caminho exato do diretório de configuração antes de rodar; um caminho incorreto registra um daemon apontando para o lugar errado, exigindo remoção manual do serviço no systemd.
sudo systemctl start OracleGoldenGateExplicação técnica do comando
O que este comando faz: Inicia efetivamente o daemon já habilitado, subindo o Service Manager e, em cascata, os deployments configurados para início automático.
Como interpretar e aplicar: Execute depois do systemctl enable; o comando normalmente não retorna saída — a confirmação vem do systemctl status em seguida, que deve mostrar active (running).
Cuidados antes da execução: Se o serviço não subir, verifique journalctl -u OracleGoldenGate antes de qualquer alteração manual nos arquivos de configuração.
Laboratório Guiado — Instalação Oficial (com telas reais)
Sequência completa, com capturas de tela reais do OUI, do OGGCA e da console web, baseada no roteiro oficial de laboratório.
1Selecionar o tipo de instalação (OUI)
Na primeira tela do instalador gráfico, escolha a opção padrão de banco de dados suportado para esta versão do GoldenGate — é aqui que a arquitetura Microservices é confirmada implicitamente pelo pacote selecionado.
2Implantação do Service Manager (OGGCA)
No assistente de configuração, informe o Home do Software ($OGG_HOME), o Home de Implantação do Service Manager, o host/porta base (9000) e ative a opção de registrar como daemon do sistema.
3Administrador do Service Manager
Defina o usuário administrativo do Service Manager (ex: srv_manager) e uma senha forte, mantendo ativada a política de senha forte do assistente.
4Implantação do usuário e portas do Deployment
Nomeie o Deployment conforme o ambiente (ex: oracle_deploy) e confirme a sequência de portas: Administration Service, Distribution Service, Receiver Service e Performance Metrics Service, além do TNS_ADMIN e do esquema de replicação.
5Registro como daemon do systemd
Ao confirmar o registro como serviço do sistema, o assistente exibe as três etapas que serão executadas automaticamente: interrupção temporária da implantação, exibição do script de registro e inicialização do daemon em segundo plano.
6Login na Console Web
Com o Service Manager ativo, acesse a URL do Administration Service no navegador e autentique-se com o usuário administrativo criado no assistente.
7Validar o Dashboard inicial
Após o login, o Administration Service exibe o painel consolidado de processos (Extrações, Replicações, Caminhos de Distribuição e Receptor) — todos zerados neste primeiro acesso, confirmando que a instalação está pronta para receber os primeiros Extracts e Replicats.
Checklist de conclusão
Módulo 03
Preparação do Oracle Database
Logging, Multitenant, privilégios e consistência de captura
FORMAÇÃO ENTERPRISE
Preparação do Oracle Database
Configure o banco de origem para fornecer todas as informações necessárias à captura e prepare usuários administrativos com privilégios controlados.
Abrir apostila original em PDF ↗Competências desenvolvidas
- ✓Habilitar ARCHIVELOG e FORCE LOGGING
- ✓Configurar supplemental logging
- ✓Criar usuário comum para CDB/PDB
- ✓Validar parâmetros para Integrated Capture
Critério de conclusão
Leia as explicações, execute os comandos no simulador, compare o resultado esperado e confirme o laboratório.
Resultado esperado
Banco em ARCHIVELOG, FORCE LOGGING habilitado, supplemental logging ativo e usuário GoldenGate autorizado em todos os containers necessários.
1. Logging obrigatório
ARCHIVELOG preserva redo arquivado e FORCE LOGGING reduz o risco de operações NOLOGGING. Supplemental logging adiciona colunas necessárias para localizar e reconstruir mudanças no destino.
2. Privilégios mínimos
Use DBMS_GOLDENGATE_AUTH para conceder privilégios adequados. Evite SYS ou SYSTEM na operação diária e armazene credenciais no Credential Store.
3. Multitenant
Em ambientes CDB/PDB, o usuário comum normalmente usa prefixo C##. O registro do Extract precisa considerar containers e PDBs capturados, mantendo consistência entre nomes de serviço e aliases.
Visão do fluxo
CDB
→
PDBs
→
Redo Threads
→
LogMiner Server
→
Integrated Extract
→
Trail
Representação didática para apoiar o entendimento da sequência operacional deste módulo.
Laboratório prático
10 comandos e verificações para praticar o conteúdo.
ARCHIVE LOG LIST;Explicação técnica do comando
O que este comando faz: Executa uma operação administrativa ou uma validação relacionada ao conteúdo deste módulo.
Como interpretar e aplicar: O resultado deve ser analisado em conjunto com o estado dos processos, checkpoints, logs e dependências da arquitetura, pois um retorno isolado não comprova que todo o fluxo de replicação está saudável.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
SELECT force_logging, supplemental_log_data_min FROM v$database;Explicação técnica do comando
O que este comando faz: Executa uma consulta de diagnóstico para confirmar parâmetros, usuários, containers, volume ou estado dos objetos envolvidos na replicação.
Como interpretar e aplicar: A consulta é somente leitura, mas sua interpretação depende do contexto. Compare valores com o requisito do GoldenGate e com a arquitetura do ambiente. Em RAC ou Multitenant, confirme se a visão e o container consultados representam todo o escopo necessário.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
ALTER DATABASE FORCE LOGGING;Explicação técnica do comando
O que este comando faz: Altera uma configuração do Oracle Database necessária à captura consistente ou ao suporte operacional do GoldenGate.
Como interpretar e aplicar: Mudanças como FORCE LOGGING, supplemental logging e ENABLE_GOLDENGATE_REPLICATION influenciam geração de redo e recursos internos. Valide escopo, persistência e impacto em desempenho, além de confirmar o valor após a alteração.
Cuidados antes da execução: Comandos ALTER modificam o ambiente. Exigem autorização, evidência de pré-check, backup ou estratégia de retorno e execução conforme processo de mudança da empresa.
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;Explicação técnica do comando
O que este comando faz: Altera uma configuração do Oracle Database necessária à captura consistente ou ao suporte operacional do GoldenGate.
Como interpretar e aplicar: Mudanças como FORCE LOGGING, supplemental logging e ENABLE_GOLDENGATE_REPLICATION influenciam geração de redo e recursos internos. Valide escopo, persistência e impacto em desempenho, além de confirmar o valor após a alteração.
Cuidados antes da execução: Comandos ALTER modificam o ambiente. Exigem autorização, evidência de pré-check, backup ou estratégia de retorno e execução conforme processo de mudança da empresa.
ALTER SYSTEM SET ENABLE_GOLDENGATE_REPLICATION=TRUE SCOPE=BOTH;Explicação técnica do comando
O que este comando faz: Altera uma configuração do Oracle Database necessária à captura consistente ou ao suporte operacional do GoldenGate.
Como interpretar e aplicar: Mudanças como FORCE LOGGING, supplemental logging e ENABLE_GOLDENGATE_REPLICATION influenciam geração de redo e recursos internos. Valide escopo, persistência e impacto em desempenho, além de confirmar o valor após a alteração.
Cuidados antes da execução: Comandos ALTER modificam o ambiente. Exigem autorização, evidência de pré-check, backup ou estratégia de retorno e execução conforme processo de mudança da empresa.
CREATE USER c##ggadmin IDENTIFIED BY "StrongPassword#1" CONTAINER=ALL;Explicação técnica do comando
O que este comando faz: Cria uma identidade dedicada para conexão, captura, aplicação ou replicação lógica.
Como interpretar e aplicar: Usuários exclusivos permitem auditoria e rotação de credenciais. A senha exibida é apenas exemplo e deve ser substituída por segredo forte, armazenado em cofre ou Credential Store. Conceda somente os privilégios exigidos.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
GRANT CREATE SESSION, SET CONTAINER TO c##ggadmin CONTAINER=ALL;Explicação técnica do comando
O que este comando faz: Concede ao usuário os privilégios necessários para executar funções GoldenGate no banco.
Como interpretar e aplicar: DBMS_GOLDENGATE_AUTH centraliza privilégios específicos e é preferível a concessões indiscriminadas. Em CDB/PDB, confirme o container e o parâmetro CONTAINER para evitar falta ou excesso de autorização.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
EXEC DBMS_GOLDENGATE_AUTH.GRANT_ADMIN_PRIVILEGE('C##GGADMIN',CONTAINER=>'ALL');Explicação técnica do comando
O que este comando faz: Concede ao usuário os privilégios necessários para executar funções GoldenGate no banco.
Como interpretar e aplicar: DBMS_GOLDENGATE_AUTH centraliza privilégios específicos e é preferível a concessões indiscriminadas. Em CDB/PDB, confirme o container e o parâmetro CONTAINER para evitar falta ou excesso de autorização.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
SELECT name, open_mode FROM v$pdbs;Explicação técnica do comando
O que este comando faz: Executa uma consulta de diagnóstico para confirmar parâmetros, usuários, containers, volume ou estado dos objetos envolvidos na replicação.
Como interpretar e aplicar: A consulta é somente leitura, mas sua interpretação depende do contexto. Compare valores com o requisito do GoldenGate e com a arquitetura do ambiente. Em RAC ou Multitenant, confirme se a visão e o container consultados representam todo o escopo necessário.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
SELECT username, common FROM cdb_users WHERE username='C##GGADMIN';Explicação técnica do comando
O que este comando faz: Executa uma consulta de diagnóstico para confirmar parâmetros, usuários, containers, volume ou estado dos objetos envolvidos na replicação.
Como interpretar e aplicar: A consulta é somente leitura, mas sua interpretação depende do contexto. Compare valores com o requisito do GoldenGate e com a arquitetura do ambiente. Em RAC ou Multitenant, confirme se a visão e o container consultados representam todo o escopo necessário.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;Explicação técnica do comando
O que este comando faz: Coloca o banco em modo ARCHIVELOG quando ele ainda estiver em NOARCHIVELOG — pré-requisito obrigatório para o Extract acessar logs históricos em caso de atraso na captura.
Como interpretar e aplicar: Só é necessário se ARCHIVE LOG LIST mostrar No Archive Mode. A sequência exige parar e reabrir o banco, portanto deve ser executada em janela de manutenção formalmente aprovada.
Cuidados antes da execução: Nunca execute em produção sem uma janela aprovada, backup recente e um plano de rollback. Confirme previamente que há espaço em disco suficiente para os archives que passarão a ser gerados.
ALTER SYSTEM SET UNDO_RETENTION=86400 SCOPE=BOTH;Explicação técnica do comando
O que este comando faz: Aumenta a retenção de UNDO para 24 horas (86400 segundos), reduzindo o risco do erro ORA-01555 (Snapshot too old) durante o Flashback Query que o Extract usa para reconstruir imagens consistentes de linha.
Como interpretar e aplicar: Ajuste o valor conforme o volume transacional real do ambiente e monitore V$UNDOSTAT para calcular a média de UPS (Undo Per Second) e dimensionar corretamente o tablespace de UNDO.
Cuidados antes da execução: Retenções muito altas aumentam o consumo do tablespace de UNDO — dimensione-o previamente com a fórmula (UNDO_RETENTION × UPS) + Overhead antes de elevar este parâmetro em produção.
GRANT OGG_CAPTURE TO ggadmin CONTAINER=ALL;Explicação técnica do comando
O que este comando faz: Concede, no Oracle AI Database 26ai, a role nativa que substitui o antigo pacote DBMS_GOLDENGATE_AUTH, autorizando o usuário a operar como Extract (captura de DML e DDL na origem).
Como interpretar e aplicar: Execute conectado como SYSDBA no CDB$ROOT, logo após criar o usuário com GRANT CONNECT, RESOURCE. É o padrão recomendado a partir do 26ai, substituindo a abordagem legada baseada em procedure.
Cuidados antes da execução: Em bancos 26ai, tentar usar DBMS_GOLDENGATE_AUTH.GRANT_ADMIN_PRIVILEGE não concede privilégio algum — apenas emite um aviso. Use sempre as roles nativas OGG_* nesta versão.
GRANT OGG_APPLY, OGG_APPLY_PROCREP TO ggadmin;Explicação técnica do comando
O que este comando faz: Concede as roles que autorizam o usuário a atuar como Replicat no destino (OGG_APPLY) e, quando necessário, a replicar chamadas de packages e procedures Oracle (OGG_APPLY_PROCREP).
Como interpretar e aplicar: Execute no PDB de destino, combinando com grants explícitos de SELECT, INSERT, UPDATE, DELETE nas tabelas de negócio que o Replicat efetivamente irá alterar.
Cuidados antes da execução: Conceda OGG_APPLY_PROCREP apenas quando o ambiente realmente replicar lógica procedural — evite conceder roles além do estritamente necessário para o cenário em produção.
ALTER USER ggadmin SET CONTAINER_DATA = ALL CONTAINER = CURRENT;Explicação técnica do comando
O que este comando faz: Permite que um usuário comum, quando o Extract é registrado no container Root (cenário de Downstream Capture), enxergue e opere dados de todos os containers do CDB.
Como interpretar e aplicar: Use apenas em arquiteturas Downstream Capture; no modelo per-PDB Extract — recomendado pela Oracle para 26ai — este passo normalmente não é necessário, pois o usuário conecta diretamente ao PDB.
Cuidados antes da execução: Amplia o escopo de visibilidade do usuário entre PDBs distintos — avalie cuidadosamente o impacto de segurança e conformidade antes de aplicar em ambientes multi-tenant compartilhados.
Passo a Passo — Preparação Completa do Banco (Parte I e II)
Sequência recomendada para deixar o Oracle Database pronto para o GoldenGate 26ai, da ativação de logging às roles corretas de privilégio.
1Habilitar a replicação e o modo ARCHIVELOG
Ative ENABLE_GOLDENGATE_REPLICATION e confirme com ARCHIVE LOG LIST que o banco está em modo ARCHIVELOG (ou aplique a sequência SHUTDOWN/STARTUP MOUNT/ARCHIVELOG/OPEN ao lado).
2Ativar FORCE LOGGING e SUPPLEMENTAL LOG DATA
Garanta que toda alteração seja gravada no redo, mesmo operações NOLOGGING, e que o log suplementar mínimo esteja ativo a nível de banco.
3Ajustar UNDO_RETENTION
Configure uma retenção de UNDO compatível com a duração das maiores transações do ambiente, evitando ORA-01555 durante o Flashback Query do Extract.
4Criar o usuário administrador do GoldenGate
Crie o usuário (ex: ggadmin ou c##ggadmin) com CREATE USER ... CONTAINER=ALL e conceda CONNECT, RESOURCE como base.
5Conceder as roles corretas para a versão do banco
No Oracle AI Database 26ai, use as roles nativas OGG_CAPTURE (origem) e OGG_APPLY / OGG_APPLY_PROCREP (destino). Em Oracle 21c ou inferior, aplique a matriz de privilégios granulares (CREATE SESSION, RESOURCE, SELECT ANY DICTIONARY, ALTER SYSTEM e, apenas no Replicat, INSERT/UPDATE/DELETE ANY TABLE).
6Tratar o cenário Multitenant (CDB/PDB)
Prefira o modelo per-PDB Extract, conectando diretamente ao Pluggable Database. Evite hífen/traço em nomes de usuário, PDB ou GLOBAL_NAME — o OGG retorna o erro OGG-08221 / ORA-44004 (invalid qualified SQL name) nesses casos.
7Validar o resultado
Confirme com SELECT name, open_mode FROM v$pdbs; e SELECT username, common FROM cdb_users WHERE username='GGADMIN'; que o usuário existe, é comum (se aplicável) e o PDB está READ WRITE.
Checklist de conclusão
Módulo 04
Bancos e Segurança Avançada
Privilégios, wallets, TLS e preparação heterogênea
FORMAÇÃO ENTERPRISE
Bancos e Segurança Avançada
Aplique um modelo seguro de credenciais e prepare Oracle, PostgreSQL e MySQL para replicação controlada.
Abrir apostila original em PDF ↗Competências desenvolvidas
- ✓Proteger senhas com Credential Store
- ✓Entender TLS e mTLS entre serviços
- ✓Preparar PostgreSQL para logical decoding
- ✓Preparar MySQL com binlog ROW e GTID
Critério de conclusão
Leia as explicações, execute os comandos no simulador, compare o resultado esperado e confirme o laboratório.
Resultado esperado
Aliases disponíveis sem senha em texto claro, certificados válidos e bancos heterogêneos configurados para geração dos logs necessários.
1. Credential Store e Wallet
Credenciais não devem permanecer em arquivos de parâmetros. O Credential Store mantém aliases criptografados, enquanto wallets suportam identidades e certificados usados na comunicação HTTPS e mTLS.
2. PostgreSQL
Logical replication exige wal_level=logical, slots e privilégios de replicação. É importante dimensionar retenção de WAL para impedir consumo de disco quando o consumidor estiver indisponível.
3. MySQL
O GoldenGate depende de binary logs no formato ROW. GTID, server_id único e retenção adequada facilitam continuidade, troubleshooting e recuperação após indisponibilidades.
Visão do fluxo
Identity
→
Credential Store
→
Wallet
→
TLS/mTLS
→
Database Privileges
→
Audit
Representação didática para apoiar o entendimento da sequência operacional deste módulo.
Laboratório prático
10 comandos e verificações para praticar o conteúdo.
ADD CREDENTIALSTOREExplicação técnica do comando
O que este comando faz: Cria, consulta ou altera o Credential Store, que mantém credenciais protegidas e disponibiliza aliases para os processos GoldenGate.
Como interpretar e aplicar: O alias permite usar USERIDALIAS em vez de senha em texto claro nos parâmetros. Após inclusão ou rotação, teste DBLOGIN e confirme que os processos continuam conectando. Proteja também os arquivos de wallet no sistema operacional.
Cuidados antes da execução: Nunca reutilize as senhas de exemplo. Evite registrar comandos com senha em históricos de shell, tickets ou capturas de tela; prefira entrada segura e mecanismos corporativos de segredo.
ALTER CREDENTIALSTORE ADD USER c##ggadmin@ORCL ALIAS gg_oracle PASSWORD StrongPassword#1Explicação técnica do comando
O que este comando faz: Cria, consulta ou altera o Credential Store, que mantém credenciais protegidas e disponibiliza aliases para os processos GoldenGate.
Como interpretar e aplicar: O alias permite usar USERIDALIAS em vez de senha em texto claro nos parâmetros. Após inclusão ou rotação, teste DBLOGIN e confirme que os processos continuam conectando. Proteja também os arquivos de wallet no sistema operacional.
Cuidados antes da execução: Nunca reutilize as senhas de exemplo. Evite registrar comandos com senha em históricos de shell, tickets ou capturas de tela; prefira entrada segura e mecanismos corporativos de segredo.
INFO CREDENTIALSTOREExplicação técnica do comando
O que este comando faz: Exibe informações de configuração e execução do objeto solicitado, permitindo confirmar existência, tipo, checkpoint, trail associado e estado atual.
Como interpretar e aplicar: Use a saída para comparar a configuração ativa com o desenho esperado. Em processos de captura ou aplicação, observe posição de leitura, horário do checkpoint e parâmetros vinculados. Diferenças entre o cadastro e a documentação podem indicar alteração não controlada ou implantação incompleta.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
ALTER CREDENTIALSTORE REPLACE USER c##ggadmin@ORCL ALIAS gg_oracle PASSWORD NewPassword#2Explicação técnica do comando
O que este comando faz: Cria, consulta ou altera o Credential Store, que mantém credenciais protegidas e disponibiliza aliases para os processos GoldenGate.
Como interpretar e aplicar: O alias permite usar USERIDALIAS em vez de senha em texto claro nos parâmetros. Após inclusão ou rotação, teste DBLOGIN e confirme que os processos continuam conectando. Proteja também os arquivos de wallet no sistema operacional.
Cuidados antes da execução: Nunca reutilize as senhas de exemplo. Evite registrar comandos com senha em históricos de shell, tickets ou capturas de tela; prefira entrada segura e mecanismos corporativos de segredo.
orapki wallet create -wallet /u02/ogg/etc/wallet -auto_loginExplicação técnica do comando
O que este comando faz: Cria ou inspeciona uma Oracle Wallet utilizada para certificados, chaves e comunicação TLS ou mTLS.
Como interpretar e aplicar: A wallet deve conter a cadeia de confiança e, quando necessário, certificado e chave privada da identidade. Verifique validade, emissor, hostname e permissões dos arquivos. Certificados expirados podem indisponibilizar endpoints Microservices.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
orapki wallet display -wallet /u02/ogg/etc/walletExplicação técnica do comando
O que este comando faz: Cria ou inspeciona uma Oracle Wallet utilizada para certificados, chaves e comunicação TLS ou mTLS.
Como interpretar e aplicar: A wallet deve conter a cadeia de confiança e, quando necessário, certificado e chave privada da identidade. Verifique validade, emissor, hostname e permissões dos arquivos. Certificados expirados podem indisponibilizar endpoints Microservices.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
ALTER SYSTEM SET wal_level = logical;Explicação técnica do comando
O que este comando faz: Altera uma configuração do Oracle Database necessária à captura consistente ou ao suporte operacional do GoldenGate.
Como interpretar e aplicar: Mudanças como FORCE LOGGING, supplemental logging e ENABLE_GOLDENGATE_REPLICATION influenciam geração de redo e recursos internos. Valide escopo, persistência e impacto em desempenho, além de confirmar o valor após a alteração.
Cuidados antes da execução: Comandos ALTER modificam o ambiente. Exigem autorização, evidência de pré-check, backup ou estratégia de retorno e execução conforme processo de mudança da empresa.
CREATE ROLE gguser WITH LOGIN REPLICATION PASSWORD 'StrongPassword#1';Explicação técnica do comando
O que este comando faz: Cria uma identidade dedicada para conexão, captura, aplicação ou replicação lógica.
Como interpretar e aplicar: Usuários exclusivos permitem auditoria e rotação de credenciais. A senha exibida é apenas exemplo e deve ser substituída por segredo forte, armazenado em cofre ou Credential Store. Conceda somente os privilégios exigidos.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
SHOW VARIABLES LIKE 'binlog_format';Explicação técnica do comando
O que este comando faz: Consulta ou configura parâmetros persistentes do MySQL necessários à captura baseada em binary log.
Como interpretar e aplicar: O formato ROW registra as alterações por linha e oferece a informação mais adequada para replicação. Confirme também server_id, GTID, retenção dos binlogs e impacto do reinício. O valor persistente deve ser validado após nova conexão ou restart.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
SET PERSIST binlog_format='ROW';Explicação técnica do comando
O que este comando faz: Consulta ou configura parâmetros persistentes do MySQL necessários à captura baseada em binary log.
Como interpretar e aplicar: O formato ROW registra as alterações por linha e oferece a informação mais adequada para replicação. Confirme também server_id, GTID, retenção dos binlogs e impacto do reinício. O valor persistente deve ser validado após nova conexão ou restart.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
wal_level = logical
max_replication_slots = 5Explicação técnica do comando
O que este comando faz: Parâmetros obrigatórios no postgresql.conf para habilitar a decodificação lógica do WAL e reservar slots de replicação dedicados para os Extracts do GoldenGate.
Como interpretar e aplicar: Após editar, reinicie o serviço PostgreSQL — wal_level exige reinício. Cada Extract registrado consumirá um slot dedicado, então dimensione max_replication_slots com folga.
Cuidados antes da execução: Slots de replicação não consumidos retêm WAL indefinidamente e podem encher o disco — monitore pg_replication_slots e remova slots órfãos de Extracts descontinuados.
ALTER TABLE schema.tabela REPLICA IDENTITY FULL;Explicação técnica do comando
O que este comando faz: Garante que o WAL do PostgreSQL contenha a imagem completa da linha antes da alteração, requisito para o OGG capturar corretamente operações de UPDATE e DELETE.
Como interpretar e aplicar: Aplique em cada tabela que será replicada, antes de registrar o Extract com REGISTER EXTRACT. Sem isso, updates e deletes podem falhar silenciosamente na captura.
Cuidados antes da execução: REPLICA IDENTITY FULL aumenta o volume gravado no WAL — avalie o impacto de I/O em tabelas muito voláteis e monitore o crescimento do WAL após a mudança.
SELECT * FROM pg_replication_slots;Explicação técnica do comando
O que este comando faz: Lista os slots de replicação ativos no PostgreSQL, permitindo confirmar que o slot criado pelo REGISTER EXTRACT do OGG existe e está ativo.
Como interpretar e aplicar: Verifique a coluna slot_name (deve corresponder ao Extract) e active=true. Um slot inativo por muito tempo retém WAL e é um sinal de alerta imediato.
Cuidados antes da execução: Slots órfãos, de Extracts removidos sem o devido cleanup, devem ser descartados manualmente com pg_drop_replication_slot para liberar espaço em disco.
binlog_row_image = FULL
binlog_row_metadata = FULLExplicação técnica do comando
O que este comando faz: Parâmetros do my.cnf que garantem que o binlog do MySQL grave a imagem completa da linha e os metadados de schema — este último é requisito do OGG 26ai para captura de DDL.
Como interpretar e aplicar: Adicione junto de binlog_format = ROW e reinicie o MySQL. Sem binlog_row_metadata = FULL, alterações de schema (DDL) simplesmente não serão replicadas.
Cuidados antes da execução: Esses parâmetros aumentam o tamanho dos arquivos de binlog — monitore o espaço em disco e a política de expire_logs_days para evitar esgotamento de armazenamento.
gtid_mode = ON
enforce_gtid_consistency = ONExplicação técnica do comando
O que este comando faz: Habilita identificadores globais de transação (GTID) no MySQL, permitindo que o Extract recupere a posição exata de captura mesmo após um failover de nó, sem perda de dados.
Como interpretar e aplicar: Aplique antes de iniciar a captura. Ambientes já em produção podem exigir uma janela de manutenção para migrar de replicação baseada em posição para GTID.
Cuidados antes da execução: Todos os nós do cluster ou replica set devem ter GTID habilitado de forma consistente — divergência entre nós quebra a garantia de posicionamento do Extract.
CREATE USER 'gguser'@'%' IDENTIFIED BY 'senha_segura';
GRANT REPLICATION SLAVE ON *.* TO 'gguser'@'%';Explicação técnica do comando
O que este comando faz: Cria o usuário dedicado de replicação no MySQL com o privilégio mínimo necessário (REPLICATION SLAVE) para o Extract ler o binlog.
Como interpretar e aplicar: Combine com GRANT SELECT nas tabelas de negócio se o Extract também precisar consultar dados diretamente; restrinja o host (evite % irrestrito em produção).
Cuidados antes da execução: Nunca reutilize um usuário administrativo genérico para a captura de replicação — mantenha um usuário dedicado para facilitar auditoria e revogação de acesso.
openssl req -new -x509 -days 365 -keyout rootCA_key.pem -out rootCA_cert.pemExplicação técnica do comando
O que este comando faz: Gera a Root CA (autoridade certificadora raiz) que assinará os certificados de todos os serviços Microservices, base do mTLS obrigatório em ambientes OGG 26ai de produção.
Como interpretar e aplicar: Guarde a chave privada (rootCA_key.pem) em local seguro e restrito. O certificado público (rootCA_cert.pem) será importado no Service Manager pela aba "Certificate Management".
Cuidados antes da execução: Defina um processo de renovação e monitoramento de validade — certificados expirados derrubam silenciosamente a comunicação mTLS entre Distribution Service e Receiver Service.
Passo a Passo — Preparação de Bancos Heterogêneos (MySQL e PostgreSQL)
Checklist combinado de Oracle, MySQL e PostgreSQL para deixar os três motores prontos para captura e aplicação segura via GoldenGate 26ai.
1Oracle — habilitar motores de captura
Ative ENABLE_GOLDENGATE_REPLICATION, FORCE LOGGING e SUPPLEMENTAL LOG DATA, depois conceda a role OGG_CAPTURE ao usuário administrador (ver Módulo 03).
2MySQL — ativar binlog em modo ROW completo
Configure binlog_format=ROW, binlog_row_image=FULL e binlog_row_metadata=FULL no my.cnf e reinicie o serviço.
3MySQL — habilitar GTID e criar usuário de replicação
Ative gtid_mode e enforce_gtid_consistency, depois crie um usuário dedicado com REPLICATION SLAVE.
4PostgreSQL — configurar wal_level e slots
Defina wal_level = logical e max_replication_slots no postgresql.conf e reinicie o serviço.
5PostgreSQL — REPLICA IDENTITY e registro do Extract
Aplique REPLICA IDENTITY FULL nas tabelas alvo e registre o Extract com o plugin nativo: REGISTER EXTRACT ex_pg PGPLUGINTYPE pgoutput; (detalhado no Módulo 06).
6Blindagem TLS/mTLS
Gere a Root CA com openssl req, importe-a no Service Manager e confirme que TLS 1.3 está ativo em todos os serviços Microservices.
7Credential Store e aliases
Cadastre cada conexão com ADD CREDENTIALSTORE e ALTER CREDENTIALSTORE ADD USER ... ALIAS ..., e confirme na console web o ícone azul de conexão validada em "DB Connections".
Checklist de conclusão
Módulo 05
Conexões Seguras e Protocolos
USERIDALIAS, Oracle Net, TCP/IP, BEQ e diagnóstico
FORMAÇÃO ENTERPRISE
Conexões Seguras e Protocolos
Construa conexões confiáveis entre GoldenGate e bancos, usando aliases, serviços corretos e validações de rede.
Abrir apostila original em PDF ↗Competências desenvolvidas
- ✓Configurar tnsnames.ora para CDB e PDB
- ✓Usar DBLOGIN com USERIDALIAS
- ✓Diagnosticar listener, DNS e firewall
- ✓Escolher protocolo conforme arquitetura
Critério de conclusão
Leia as explicações, execute os comandos no simulador, compare o resultado esperado e confirme o laboratório.
Resultado esperado
DBLOGIN concluído com sucesso, container correto identificado e endpoints HTTPS respondendo sem falhas de resolução ou autenticação.
1. Resolução de serviço
O alias TNS deve apontar para o serviço correto, não apenas para o SID. Em Multitenant, separe serviços para root e PDB, garantindo que cada processo se conecte ao container esperado.
2. Protocolos
TCP/IP é o padrão para conexões remotas. BEQ pode ser utilizado localmente em cenários específicos, mas reduz portabilidade. IPC pode atender comunicação local de baixa latência, desde que bem documentada.
3. Troubleshooting
Valide DNS, rota, firewall, listener, SERVICE_NAME e autenticação. Erros ORA-12154, ORA-12514 e ORA-12541 indicam problemas diferentes e devem ser tratados pela camada correta.
Visão do fluxo
GoldenGate
→
Credential Alias
→
Oracle Net
→
Listener
→
Service
→
CDB/PDB
Representação didática para apoiar o entendimento da sequência operacional deste módulo.
Laboratório prático
10 comandos e verificações para praticar o conteúdo.
tnsping ORCLExplicação técnica do comando
O que este comando faz: Valida se o alias Oracle Net pode ser resolvido e se o endereço de rede configurado responde.
Como interpretar e aplicar: O sucesso do tnsping confirma resolução do descriptor e alcance do listener, mas não autenticação nem existência do serviço solicitado. Complete o teste com conexão SQL ou DBLOGIN.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
lsnrctl statusExplicação técnica do comando
O que este comando faz: Consulta o Oracle Listener para verificar endpoints, serviços registrados e estado do processo de escuta.
Como interpretar e aplicar: Compare SERVICE_NAME, host e porta com o tnsnames.ora. ORA-12514 geralmente indica serviço não registrado; ORA-12541 aponta ausência ou inacessibilidade do listener.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
sqlplus c##ggadmin@ORCLExplicação técnica do comando
O que este comando faz: Executa uma operação administrativa ou uma validação relacionada ao conteúdo deste módulo.
Como interpretar e aplicar: O resultado deve ser analisado em conjunto com o estado dos processos, checkpoints, logs e dependências da arquitetura, pois um retorno isolado não comprova que todo o fluxo de replicação está saudável.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
DBLOGIN USERIDALIAS gg_oracleExplicação técnica do comando
O que este comando faz: Estabelece uma sessão do Admin Client com o banco usando o alias protegido no Credential Store.
Como interpretar e aplicar: O sucesso confirma resolução de serviço, autenticação e acesso básico. Em Multitenant, valide o container conectado antes de registrar Extract, adicionar TRANDATA ou executar operações administrativas.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
DBLOGIN USERIDALIAS gg_oracle DOMAIN OracleGoldenGateExplicação técnica do comando
O que este comando faz: Estabelece uma sessão do Admin Client com o banco usando o alias protegido no Credential Store.
Como interpretar e aplicar: O sucesso confirma resolução de serviço, autenticação e acesso básico. Em Multitenant, valide o container conectado antes de registrar Extract, adicionar TRANDATA ou executar operações administrativas.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
INFO CREDENTIALSTOREExplicação técnica do comando
O que este comando faz: Exibe informações de configuração e execução do objeto solicitado, permitindo confirmar existência, tipo, checkpoint, trail associado e estado atual.
Como interpretar e aplicar: Use a saída para comparar a configuração ativa com o desenho esperado. Em processos de captura ou aplicação, observe posição de leitura, horário do checkpoint e parâmetros vinculados. Diferenças entre o cadastro e a documentação podem indicar alteração não controlada ou implantação incompleta.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
SELECT sys_context('USERENV','CON_NAME') FROM dual;Explicação técnica do comando
O que este comando faz: Executa uma consulta de diagnóstico para confirmar parâmetros, usuários, containers, volume ou estado dos objetos envolvidos na replicação.
Como interpretar e aplicar: A consulta é somente leitura, mas sua interpretação depende do contexto. Compare valores com o requisito do GoldenGate e com a arquitetura do ambiente. Em RAC ou Multitenant, confirme se a visão e o container consultados representam todo o escopo necessário.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
nc -vz dbserver.example.com 1521Explicação técnica do comando
O que este comando faz: Testa conectividade TCP básica até o host e a porta informados.
Como interpretar e aplicar: Sucesso confirma rota e abertura da porta, mas não valida protocolo, autenticação ou aplicação. Falha pode envolver DNS, firewall, security list, listener ou serviço indisponível.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
openssl s_client -connect oggserver.example.com:16000 -showcertsExplicação técnica do comando
O que este comando faz: Abre uma conexão TLS de diagnóstico e exibe certificados apresentados pelo endpoint.
Como interpretar e aplicar: Analise subject, issuer, validade, cadeia e correspondência do hostname. A conexão pode funcionar mesmo com cadeia incompleta dependendo das opções, portanto valide também com o cliente real e truststore usado pelo serviço.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
curl -k -u oggadmin https://oggserver.example.com:16000/services/v2/deploymentsExplicação técnica do comando
O que este comando faz: Consulta um endpoint REST da arquitetura Microservices para obter informações estruturadas sobre deployments, serviços ou recursos administrativos.
Como interpretar e aplicar: A resposta HTTP ajuda a validar disponibilidade, autenticação e conteúdo retornado pela API. Códigos 2xx indicam sucesso; 401/403 apontam autenticação ou autorização; 404 pode indicar endpoint ou versão incorreta; 5xx exige análise do serviço e de seus logs.
Cuidados antes da execução: Evite usar -k em produção, pois ele ignora a validação do certificado TLS. Prefira certificados confiáveis, armazenamento seguro de credenciais e tokens ou mecanismos de autenticação compatíveis com a política da empresa.
dbbeq =
(DESCRIPTION=
(ADDRESS=(PROTOCOL=beq)
(ENVS='ORACLE_SID=sales,ORACLE_HOME=/app/db_home/oracle,LD_LIBRARY_PATH=/app/db_home/oracle/lib')
(PROGRAM=/app/db_home/oracle/bin/oracle)(ARGV0=oraclesales)
(ARGS='(DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))'))
(CONNECT_DATA=(SID=sales)))Explicação técnica do comando
O que este comando faz: Cria um descritor de conexão Bequeath (BEQ) no tnsnames.ora, permitindo que o Extract se conecte diretamente ao binário do Oracle sem passar pelo Listener de rede.
Como interpretar e aplicar: Use quando o OGG estiver instalado no mesmo servidor físico do banco. A Oracle recomenda BEQ ou TCP e desaconselha fortemente o protocolo IPC, que apresenta falhas intermitentes na notificação de DDL do Extract integrado.
Cuidados antes da execução: Não pode haver nenhum espaço em branco dentro das aspas do parâmetro ENVS — um único espaço entre as variáveis quebra a sintaxe do SQL*Net e a conexão falha.
cdb23_pdbeast =
(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=DBEAST)(PORT=1521))
(CONNECT_DATA=(SERVICE_NAME=cdb1_pdbeast.rdbms.oracle.com)))Explicação técnica do comando
O que este comando faz: Mapeia, via protocolo TCP, a conexão direta a um PDB específico — o padrão recomendado quando o OGG está em servidor apartado do banco ou em ambientes Multitenant distribuídos.
Como interpretar e aplicar: Crie uma entrada por PDB envolvido (origem e destino) e referencie o alias correspondente no Credential Store e no USERIDALIAS do processo.
Cuidados antes da execução: Mantenha consistência de nomes entre o tnsnames.ora, o Credential Store e os arquivos .prm — divergências de nome são a causa mais comum de erro de resolução de conexão.
EXTRACT EX_HR
USERIDALIAS ggeast DOMAIN OracleGoldenGate
EXTTRAIL east/ea
TABLE hr.*;Explicação técnica do comando
O que este comando faz: Demonstra como um arquivo de parâmetros de produção fica extremamente enxuto e seguro ao usar o Credential Store — nenhuma senha ou string de conexão aparece em texto puro.
Como interpretar e aplicar: O USERIDALIAS resolve, em tempo de execução, o usuário, a senha e a connection string cadastrados sob o alias ggeast no cofre de credenciais.
Cuidados antes da execução: Nunca substitua USERIDALIAS por USERID/PASSWORD em ambientes produtivos — essa é a principal falha apontada em auditorias de segurança de ambientes GoldenGate.
ERROR OGG-08221 Cannot register or unregister EXTRACT extract_name because of the following SQL error: OCI Error ORA-44004: invalid qualified SQL name.Explicação técnica do comando
O que este comando faz: Erro típico quando o nome do usuário do banco de dados contém hífen ou traço (ex: OGG-ADMIN) — o Oracle não aceita esse caractere em nomes SQL qualificados.
Como interpretar e aplicar: Ao encontrar esse erro no VIEW REPORT ou nos logs de registro do Extract, verifique imediatamente o nome do usuário cadastrado no Credential Store e no banco.
Cuidados antes da execução: A correção é recriar o usuário utilizando apenas letras, números ou underscore (ex: ogg_admin) — nunca hífen ou traço em nomes de objetos de infraestrutura.
Passo a Passo — Cadastro de Credenciais na Console Web (com tela real)
Fluxo padrão de mercado para cadastrar e validar uma nova conexão de banco de dados diretamente pela interface Microservices.
1Acessar DB Connections na console web
No Administration Service, abra o menu lateral e clique em "Conexões de Banco de Dados" (DB Connections), depois no botão "+" para adicionar uma nova conexão.
2Preencher Credential Domain, Alias, Tipo e credenciais
Informe o domínio (ex: OracleGoldenGate), o alias amigável usado nos arquivos .prm, o tipo de conexão (DSN ou Servidor/Porta) e o usuário/senha do banco de destino — no exemplo real abaixo, um destino MySQL.
3Validar a conexão (ícone azul)
Após salvar, clique no ícone de conexão (formato de tomada) ao lado do alias. Se credenciais, porta e privilégios estiverem corretos, o ícone muda de cinza para azul instantaneamente.
4Usar o alias nos processos
Substitua toda referência de senha nos arquivos .prm por USERIDALIAS <alias> DOMAIN <domínio> — nunca informe usuário e senha diretamente em produção.
Checklist de conclusão
Módulo 06
Criação e Parametrização do Extract
Registro, Integrated Extract, trails e parâmetros de captura
FORMAÇÃO ENTERPRISE
Criação e Parametrização do Extract
Crie um Extract integrado, registre-o no banco e configure trails, objetos capturados e parâmetros de desempenho.
Abrir apostila original em PDF ↗Competências desenvolvidas
- ✓Registrar Extract no banco
- ✓Criar local trail com tamanho adequado
- ✓Definir TABLE e exclusões
- ✓Validar checkpoint, SCN e status
Critério de conclusão
Leia as explicações, execute os comandos no simulador, compare o resultado esperado e confirme o laboratório.
Resultado esperado
Extract RUNNING, registrado como Integrated Capture, escrevendo no trail e sem diferença crescente entre checkpoint e fim do log.
1. Integrated Extract
A captura integrada utiliza o LogMiner Server do Oracle, oferecendo suporte consistente a RAC, ASM, compressão e tipos avançados. O processo deve ser registrado no banco antes da execução.
2. Trail files
Trails desacoplam captura, transporte e aplicação. Defina prefixos exclusivos, capacidade de disco, retenção e monitoramento. Nunca compartilhe o mesmo trail de escrita entre Extracts distintos.
3. Parâmetros
USERIDALIAS protege credenciais. EXTTRAIL define a saída, TRANLOGOPTIONS ajusta comportamento de captura e TABLE determina o escopo. Use padrões amplos com cautela para evitar objetos inesperados.
Visão do fluxo
Redo
→
LogMiner
→
Extract E_ORA1
→
Local Trail ea
→
Checkpoint
Representação didática para apoiar o entendimento da sequência operacional deste módulo.
Laboratório prático
12 comandos e verificações para praticar o conteúdo.
DBLOGIN USERIDALIAS gg_oracleExplicação técnica do comando
O que este comando faz: Estabelece uma sessão do Admin Client com o banco usando o alias protegido no Credential Store.
Como interpretar e aplicar: O sucesso confirma resolução de serviço, autenticação e acesso básico. Em Multitenant, valide o container conectado antes de registrar Extract, adicionar TRANDATA ou executar operações administrativas.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
REGISTER EXTRACT E_ORA1 DATABASE CONTAINER (ORCLPDB1)Explicação técnica do comando
O que este comando faz: Registra o Extract integrado no Oracle Database para que ele utilize a infraestrutura de captura integrada e o LogMiner Server.
Como interpretar e aplicar: O registro associa o grupo ao banco e, quando aplicável, aos PDBs capturados. Deve ocorrer com conexão e privilégios corretos. Registros duplicados ou órfãos precisam ser tratados cuidadosamente durante recriação ou rollback.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
ADD EXTRACT E_ORA1, INTEGRATED TRANLOG, BEGIN NOWExplicação técnica do comando
O que este comando faz: Cria o grupo de captura e define o modo integrado, a origem dos logs e o ponto inicial de processamento.
Como interpretar e aplicar: BEGIN NOW inicia a partir do momento da criação, não realizando carga histórica. Para migração, sincronize o ponto de corte com initial load ou instanciamento do destino. Confirme nome, modo e checkpoint após criar.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
ADD EXTTRAIL ./dirdat/ea, EXTRACT E_ORA1, MEGABYTES 500Explicação técnica do comando
O que este comando faz: Associa ao Extract um local trail onde as alterações capturadas serão gravadas em formato GoldenGate.
Como interpretar e aplicar: O prefixo identifica a sequência de arquivos e MEGABYTES limita o tamanho individual. Planeje filesystem, retenção e monitoramento. O trail desacopla captura e transporte e é essencial para recuperação consistente.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
EDIT PARAMS E_ORA1Explicação técnica do comando
O que este comando faz: Abre ou consulta o arquivo de parâmetros do grupo GoldenGate.
Como interpretar e aplicar: O arquivo define conexão, trails, objetos e opções de desempenho. Toda alteração deve ser versionada, revisada e comparada com o padrão aprovado. Depois de editar, valide sintaxe e reinicie somente quando necessário.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
USERIDALIAS gg_oracleExplicação técnica do comando
O que este comando faz: Executa uma operação administrativa ou uma validação relacionada ao conteúdo deste módulo.
Como interpretar e aplicar: O resultado deve ser analisado em conjunto com o estado dos processos, checkpoints, logs e dependências da arquitetura, pois um retorno isolado não comprova que todo o fluxo de replicação está saudável.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
EXTTRAIL ./dirdat/eaExplicação técnica do comando
O que este comando faz: Executa uma operação administrativa ou uma validação relacionada ao conteúdo deste módulo.
Como interpretar e aplicar: O resultado deve ser analisado em conjunto com o estado dos processos, checkpoints, logs e dependências da arquitetura, pois um retorno isolado não comprova que todo o fluxo de replicação está saudável.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
TRANLOGOPTIONS INTEGRATEDPARAMS (MAX_SGA_SIZE 2048, PARALLELISM 4)Explicação técnica do comando
O que este comando faz: Executa uma operação administrativa ou uma validação relacionada ao conteúdo deste módulo.
Como interpretar e aplicar: O resultado deve ser analisado em conjunto com o estado dos processos, checkpoints, logs e dependências da arquitetura, pois um retorno isolado não comprova que todo o fluxo de replicação está saudável.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
TABLE APP.*;Explicação técnica do comando
O que este comando faz: Define o escopo de objetos capturados ou o mapeamento entre tabelas de origem e destino.
Como interpretar e aplicar: Padrões com asterisco simplificam configuração, mas podem incluir objetos novos sem avaliação. COLMAP realiza transformação de colunas e exige testes de tipos, chaves, defaults, timezone e regras de negócio.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
START EXTRACT E_ORA1Explicação técnica do comando
O que este comando faz: Inicia ou interrompe controladamente o processo GoldenGate indicado.
Como interpretar e aplicar: Após START, confirme RUNNING, avanço de checkpoint e ausência de erros. Antes de STOP, avalie backlog, dependências e janela operacional. Em manutenção, registre posições para facilitar validação posterior.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
INFO EXTRACT E_ORA1, DETAILExplicação técnica do comando
O que este comando faz: Exibe informações de configuração e execução do objeto solicitado, permitindo confirmar existência, tipo, checkpoint, trail associado e estado atual.
Como interpretar e aplicar: Use a saída para comparar a configuração ativa com o desenho esperado. Em processos de captura ou aplicação, observe posição de leitura, horário do checkpoint e parâmetros vinculados. Diferenças entre o cadastro e a documentação podem indicar alteração não controlada ou implantação incompleta.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
SEND EXTRACT E_ORA1, LOGENDExplicação técnica do comando
O que este comando faz: Envia uma solicitação de controle ou diagnóstico para um processo em execução sem alterar seu arquivo de parâmetros.
Como interpretar e aplicar: A opção LOGEND, por exemplo, verifica se o Extract alcançou o fim atual do log. O retorno ajuda a distinguir processo ocioso de processo atrasado. Consulte a sintaxe específica da versão antes do uso.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
CONNECT http://192.168.56.110:9001 DEPLOYMENT oracle_deploy AS srv_manager PASSWORD "********"Explicação técnica do comando
O que este comando faz: Autentica o Admin Client — sucessor do GGSCI clássico — no Administration Server do deployment via HTTP/HTTPS, abrindo uma sessão de comandos remota.
Como interpretar e aplicar: É sempre o primeiro comando de qualquer sessão de linha de comando no OGG Microservices. Troque host, porta, nome do deployment e usuário conforme o ambiente de destino.
Cuidados antes da execução: Prefira HTTPS em produção. Nunca deixe a senha em scripts versionados — use variáveis de ambiente, cofre externo ou prompt interativo ao automatizar chamadas do Admin Client.
ALTER CREDENTIALSTORE ADD USER oggadmin@192.168.56.110:1521/PDB_SOURCE ALIAS ogg_source PASSWORD ********Explicação técnica do comando
O que este comando faz: Cadastra, no cofre de credenciais do deployment, o usuário, host, porta e serviço do PDB de origem sob o alias ogg_source, que será referenciado no Extract.
Como interpretar e aplicar: Execute uma vez por ambiente de origem; repita o mesmo padrão para o destino trocando o alias (ex: ogg_target) e a connection string correspondente.
Cuidados antes da execução: Trate esta credencial como sensível mesmo dentro do cofre — restrinja quem tem acesso administrativo ao deployment e rotacione a senha periodicamente.
ADD TRANDATA HR.employees, ALLCOLSExplicação técnica do comando
O que este comando faz: Ativa o Supplemental Logging estrito a nível de tabela, instruindo o Oracle a gravar no redo todas as colunas necessárias para reconstrução completa da linha alterada.
Como interpretar e aplicar: Execute para cada tabela mapeada antes de iniciar o Extract; use SCHEMATRANDATA quando quiser aplicar o mesmo conceito a um schema inteiro de uma só vez.
Cuidados antes da execução: Sem este passo, o Replicat pode aplicar updates parciais no destino ou falhar ao montar a linha completa — é um dos pré-requisitos mais frequentemente esquecidos.
REGISTER EXTRACT ext_src, DATABASEExplicação técnica do comando
O que este comando faz: Registra formalmente o Extract integrado no dicionário de dados do Oracle, vinculando-o ao LogMiner interno para leitura nativa e performática do redo.
Como interpretar e aplicar: Execute logo após ADD EXTRACT e antes de ADD EXTTRAIL. É obrigatório para Extracts do tipo INTEGRATED TRANLOG.
Cuidados antes da execução: Se o Extract precisar ser recriado do zero, execute UNREGISTER EXTRACT no processo anterior antes de registrar novamente, evitando conflitos de assinatura no dicionário de dados.
ALTER EXTRACT EX_HR, BEGIN 2026-05-23T12:00:00ZExplicação técnica do comando
O que este comando faz: Reposiciona o ponteiro de leitura do Extract para um ponto específico no tempo, em formato ISO 8601, permitindo reprocessar transações do passado.
Como interpretar e aplicar: Use em cenários de recuperação, desde que os archives correspondentes ainda existam no banco de origem. O GoldenGate emite um alerta confirmando que o ponteiro de I/O foi alterado.
Cuidados antes da execução: Transações já aplicadas no destino são automaticamente filtradas para evitar duplicidade, mas sempre valide o resultado com STATS e LAG após o reposicionamento em produção.
DDL INCLUDE MAPPEDExplicação técnica do comando
O que este comando faz: Habilita a captura de comandos DDL (ex: ALTER TABLE, CREATE) para os objetos incluídos no escopo mapeado pelo parâmetro TABLE do Extract.
Como interpretar e aplicar: Adicione no arquivo .prm, normalmente logo após USERIDALIAS/EXTTRAIL. Combine com SOURCECATALOG quando o Extract atuar a nível de CDB em vez de per-PDB.
Cuidados antes da execução: A replicação de DDL exige que origem e destino tenham estruturas compatíveis — sempre teste em homologação antes de habilitar em um ambiente de produção.
Laboratório Guiado — Fluxo Completo via Admin Client (Oracle → Oracle)
Roteiro oficial, do provisionamento de privilégios ao teste de carga de prova, usando exclusivamente o Admin Client em modo Integrated Extract / Parallel Replicat.
1Preparar privilégios de origem e destino
No PDB de origem, instale o schema de exemplo (HR) e conceda DML/ALTER ao usuário do GoldenGate: GRANT SELECT, INSERT, UPDATE, DELETE ON HR.EMPLOYEES TO oggadmin; No destino, crie a estrutura espelho da tabela antes de iniciar a replicação.
2Conectar ao Deployment e criar o cofre de senhas
Abra o Admin Client, conecte-se ao Administration Server e cadastre os aliases de origem e destino no Credential Store (ver comandos CONNECT e ALTER CREDENTIALSTORE ao lado).
3Habilitar o rastreamento de linha (TRANDATA)
Antes de capturar, ative o Supplemental Logging estrito da tabela alvo com ADD TRANDATA.
4Criar e parametrizar o Extract
Adicione o processo com início imediato, registre-o no dicionário e vincule a trilha física local:
ADD EXTRACT ext_src, INTEGRATED TRANLOG, BEGIN NOW
REGISTER EXTRACT ext_src, DATABASE
ADD EXTTRAIL ./ex, EXTRACT ext_src, MEGABYTES 5005Editar o arquivo de parâmetros do Extract
Abra o editor com EDIT PARAMS ext_src e escreva as diretivas de captura:
EXTRACT ext_src
USERIDALIAS ogg_source DOMAIN OracleGoldenGate
EXTTRAIL ./ex
DDL INCLUDE MAPPED
TABLE HR.employees;6Iniciar o Extract e validar
Salve o arquivo, ative o processo e confirme o status RUNNING:
START EXTRACT ext_src
INFO ALL7Login no destino e tabela de checkpoint
Troque o foco de banco para o destino e crie a tabela de controle de checkpoints:
DBLOGIN USERIDALIAS ogg_target DOMAIN OracleGoldenGate
ADD CHECKPOINTTABLE oggadmin.ogg_checkpoints8Criar e parametrizar o Replicat Paralelo
Instancie o processo de aplicação associado à trilha e à tabela de checkpoint, com paralelismo de mapeamento e aplicação:
ADD REPLICAT rptgt, PARALLEL, EXTTRAIL ex, CHECKPOINTTABLE oggadmin.ogg_checkpoints9Parametrizar, iniciar e testar
Configure BATCHSQL e o paralelismo, mapeie a tabela, inicie o processo e confirme com um INSERT de teste na origem seguido de SELECT no destino:
REPLICAT rptgt
USERIDALIAS ogg_target DOMAIN OracleGoldenGate
BATCHSQL
MAP_PARALLELISM 2
APPLY_PARALLELISM 4
MAP HR.employees, TARGET HR.employees;Checklist de conclusão
Módulo 07
Replicação Homogênea e Heterogênea
Replicat, mapeamento, conversões e validação
FORMAÇÃO ENTERPRISE
Replicação Homogênea e Heterogênea
Implemente aplicação Oracle-to-Oracle e compreenda os ajustes necessários quando origem e destino utilizam tecnologias diferentes.
Abrir apostila original em PDF ↗Competências desenvolvidas
- ✓Criar Integrated Replicat
- ✓Configurar MAP e TARGET
- ✓Tratar diferenças de tipos de dados
- ✓Validar contagem e consistência
Critério de conclusão
Leia as explicações, execute os comandos no simulador, compare o resultado esperado e confirme o laboratório.
Resultado esperado
Replicat RUNNING, checkpoints avançando, lag controlado e objetos de origem reconciliados com o destino.
1. Aplicação integrada
Integrated Replicat coordena transações com o inbound server do Oracle e pode aplicar em paralelo respeitando dependências. Isso melhora throughput em cargas com boa independência transacional.
2. Mapeamento
MAP e TARGET definem origem e destino. COLMAP permite renomear, transformar e preencher colunas. KEYCOLS pode ser necessário quando a tabela não possui chave adequada.
3. Heterogeneidade
Tipos de dados, timezone, charset, precisão numérica e regras de collation precisam ser testados. Uma replicação tecnicamente ativa pode ainda produzir diferenças sem uma matriz de compatibilidade.
Visão do fluxo
Remote Trail
→
Replicat R_ORA1
→
Mapping
→
Target Database
→
Reconciliation
Representação didática para apoiar o entendimento da sequência operacional deste módulo.
Laboratório prático
12 comandos e verificações para praticar o conteúdo.
DBLOGIN USERIDALIAS gg_targetExplicação técnica do comando
O que este comando faz: Estabelece uma sessão do Admin Client com o banco usando o alias protegido no Credential Store.
Como interpretar e aplicar: O sucesso confirma resolução de serviço, autenticação e acesso básico. Em Multitenant, valide o container conectado antes de registrar Extract, adicionar TRANDATA ou executar operações administrativas.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
ADD CHECKPOINTTABLE GGADMIN.GG_CHECKPOINTExplicação técnica do comando
O que este comando faz: Cria a tabela de checkpoint utilizada pelo Replicat para persistir sua posição de leitura e estado transacional.
Como interpretar e aplicar: A tabela permite retomada após falhas sem reaplicar ou perder operações. Deve estar em schema controlado, protegido e incluído na estratégia de backup. Evite compartilhamento inadequado entre ambientes.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
ADD REPLICAT R_ORA1, INTEGRATED, EXTTRAIL ./dirdat/ea, CHECKPOINTTABLE GGADMIN.GG_CHECKPOINTExplicação técnica do comando
O que este comando faz: Cria o processo de aplicação que lê o trail e executa as operações correspondentes no banco de destino.
Como interpretar e aplicar: No modo integrado, o Replicat trabalha com o inbound server do Oracle e pode aplicar transações em paralelo. O checkpoint table registra progresso de forma confiável; valide schema, trail e ponto inicial.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
EDIT PARAMS R_ORA1Explicação técnica do comando
O que este comando faz: Abre ou consulta o arquivo de parâmetros do grupo GoldenGate.
Como interpretar e aplicar: O arquivo define conexão, trails, objetos e opções de desempenho. Toda alteração deve ser versionada, revisada e comparada com o padrão aprovado. Depois de editar, valide sintaxe e reinicie somente quando necessário.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
USERIDALIAS gg_targetExplicação técnica do comando
O que este comando faz: Executa uma operação administrativa ou uma validação relacionada ao conteúdo deste módulo.
Como interpretar e aplicar: O resultado deve ser analisado em conjunto com o estado dos processos, checkpoints, logs e dependências da arquitetura, pois um retorno isolado não comprova que todo o fluxo de replicação está saudável.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
MAP SRC.*, TARGET TGT.*;Explicação técnica do comando
O que este comando faz: Define o escopo de objetos capturados ou o mapeamento entre tabelas de origem e destino.
Como interpretar e aplicar: Padrões com asterisco simplificam configuração, mas podem incluir objetos novos sem avaliação. COLMAP realiza transformação de colunas e exige testes de tipos, chaves, defaults, timezone e regras de negócio.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
MAP SRC.CUSTOMER, TARGET TGT.CUSTOMER, COLMAP (USEDEFAULTS, UPDATED_AT=@DATENOW());Explicação técnica do comando
O que este comando faz: Define o escopo de objetos capturados ou o mapeamento entre tabelas de origem e destino.
Como interpretar e aplicar: Padrões com asterisco simplificam configuração, mas podem incluir objetos novos sem avaliação. COLMAP realiza transformação de colunas e exige testes de tipos, chaves, defaults, timezone e regras de negócio.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
DBOPTIONS INTEGRATEDPARAMS (PARALLELISM 4)Explicação técnica do comando
O que este comando faz: Executa uma operação administrativa ou uma validação relacionada ao conteúdo deste módulo.
Como interpretar e aplicar: O resultado deve ser analisado em conjunto com o estado dos processos, checkpoints, logs e dependências da arquitetura, pois um retorno isolado não comprova que todo o fluxo de replicação está saudável.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
START REPLICAT R_ORA1Explicação técnica do comando
O que este comando faz: Inicia ou interrompe controladamente o processo GoldenGate indicado.
Como interpretar e aplicar: Após START, confirme RUNNING, avanço de checkpoint e ausência de erros. Antes de STOP, avalie backlog, dependências e janela operacional. Em manutenção, registre posições para facilitar validação posterior.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
INFO REPLICAT R_ORA1, DETAILExplicação técnica do comando
O que este comando faz: Exibe informações de configuração e execução do objeto solicitado, permitindo confirmar existência, tipo, checkpoint, trail associado e estado atual.
Como interpretar e aplicar: Use a saída para comparar a configuração ativa com o desenho esperado. Em processos de captura ou aplicação, observe posição de leitura, horário do checkpoint e parâmetros vinculados. Diferenças entre o cadastro e a documentação podem indicar alteração não controlada ou implantação incompleta.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
STATS REPLICAT R_ORA1, TOTALExplicação técnica do comando
O que este comando faz: Apresenta estatísticas de operações processadas, como inserts, updates, deletes e total de registros.
Como interpretar e aplicar: Use as estatísticas para confirmar atividade, comparar throughput e detectar objetos sem movimento esperado. Zerar estatísticas pode facilitar medição em uma janela, mas preserve evidências quando houver incidente.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
LAG REPLICAT R_ORA1Explicação técnica do comando
O que este comando faz: Mede a diferença temporal entre a posição processada e os dados disponíveis, ajudando a identificar atraso na captura ou aplicação.
Como interpretar e aplicar: Lag momentâneo pode ocorrer em picos; tendência crescente indica que o processo não acompanha a carga. Correlacione com CPU, I/O, rede, transações longas, locks, volume e taxa de geração de redo.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
ADD DISTPATH to_mysql, SOURCE trail://192.168.56.110:9002/services/v2/sources?trail=lt, TARGET ws://192.168.56.115:8003/services/v2/targets?trail=rt, TEXT, OPTION NOAUTOSTARTExplicação técnica do comando
O que este comando faz: Cria o Distribution Path — o "bombeador de rede" que liga a trilha local de origem ao Receiver Service remoto via WebSocket, essencial em replicação entre servidores distintos (heterogênea ou não).
Como interpretar e aplicar: Aponte SOURCE para o Distribution Service local (porta padrão 9002) e TARGET para o Receiver Service do servidor de destino (porta padrão 9003). A opção NOAUTOSTART evita o início automático antes da validação.
Cuidados antes da execução: Confirme portas e regras de firewall entre os servidores antes de ativar. Um Path mal configurado gera falha silenciosa de transporte, sem sinalizar erro claro diretamente no Extract.
START DISTPATH to_mysqlExplicação técnica do comando
O que este comando faz: Inicializa o bombeador de rede criado no comando anterior, começando efetivamente a transmitir os dados da trilha local para o servidor remoto.
Como interpretar e aplicar: Execute somente após validar host, porta e a credencial de rede (Credential Store, domínio Network). Acompanhe o resultado com INFO DISTPATH.
Cuidados antes da execução: Reinícios de rede ou do servidor remoto podem exigir reiniciar o Path manualmente — configure alertas de conectividade para detectar interrupções rapidamente.
ALTER CREDENTIALSTORE ADD USER srv_manager PASSWORD ******** ALIAS network_mysql DOMAIN NetworkExplicação técnica do comando
O que este comando faz: Cadastra uma credencial do tipo Network no cofre, usada exclusivamente para autenticar a comunicação entre o Distribution Service local e o Administration Service remoto.
Como interpretar e aplicar: Crie esse alias antes de configurar o Distribution Path que aponta para o servidor remoto — ele é diferente do domínio padrão usado para credenciais de banco de dados.
Cuidados antes da execução: Mantenha o DOMAIN Network isolado do domínio OracleGoldenGate padrão — misturar os dois cofres dificulta auditoria e rotação de credenciais.
ADD PATH path2pg, SOURCE EXTTRAIL pg, TARGET PROTOCOL WSS, TARGET https://192.168.56.120:7003/services/v2/targets, TARGET EXTTRAIL pgExplicação técnica do comando
O que este comando faz: Variante do Distribution Path usando protocolo WSS (WebSocket Secure) para transportar a trilha até um Receiver Service protegido por TLS — comum em replicação heterogênea Oracle → PostgreSQL.
Como interpretar e aplicar: Gere a trilha remota com o mesmo prefixo (pg) usado na origem para simplificar o rastreamento. Confirme previamente o certificado do servidor de destino.
Cuidados antes da execução: WSS exige que o Receiver Service remoto tenha certificado TLS válido — falhas de handshake aparecem no VIEW REPORT do próprio Path, não no Extract nem no Replicat.
START REPLICAT reppg, ATCSN 1624963Explicação técnica do comando
O que este comando faz: Inicia o Replicat instruindo-o a aplicar apenas transações commitadas após o SCN informado — a técnica padrão para encadear uma carga inicial (exportada até aquele SCN) com a replicação online, sem duplicar nem perder dados.
Como interpretar e aplicar: Obtenha o SCN de corte com SELECT CURRENT_SCN FROM V$DATABASE; antes de exportar a carga inicial na origem, e use exatamente o mesmo valor aqui.
Cuidados antes da execução: Um SCN incorreto causa duplicidade de dados (SCN antigo demais) ou perda de transações (SCN recente demais) — confira o valor duas vezes antes de iniciar em produção.
VIEW REPORT ext_srcExplicação técnica do comando
O que este comando faz: Exibe o relatório detalhado de execução do processo — o primeiro lugar a olhar quando um Extract ou Replicat entra em ABENDED.
Como interpretar e aplicar: Procure por linhas com ERROR ou WARNING próximas ao horário da falha; o relatório também mostra estatísticas de throughput e o último checkpoint válido antes do erro.
Cuidados antes da execução: Relatórios crescem rapidamente em ambientes de alto volume — configure rotação ou arquivamento periódico para não esgotar o disco de OGG_VAR_HOME.
Laboratório Guiado — Carga Inicial com Zero Downtime (Console Web)
Roteiro completo, com 10 telas reais da console Microservices, para migrar dados existentes sem parar a aplicação: dois Extracts e dois Replicats trabalhando em conjunto.
1Criar e iniciar o Extract Online (CDC)
Na seção Extracts da console web, clique em "+" (Add Extract), selecione Integrated Extract e defina Process Name EX_CDC, Intent Continuous, Begin "Now" e Trail Name (duas letras, ex: aa).
2Definir o mapeamento e criar/executar
No editor de parâmetros gerado automaticamente, adicione a tabela mapeada (ex: TABLE HR.employees;) e clique em "Criar e Executar". Valide visualmente que o card do EX_CDC fica verde (Running).
3Criar o Extract de Carga Inicial (Initial Load)
Ainda em Extracts, clique em "+", mude o tipo para Initial Load Extract e defina Process Name (ex: EX_INI) e a descrição do lote a ser capturado.
4Parametrizar a carga inicial
No arquivo de parâmetros, aponte o EXTFILE local e a tabela a carregar, depois clique apenas em "Criar" (sem iniciar ainda — o destino precisa estar pronto primeiro).
5Criar o Replicat de Carga Inicial
Na seção Replicats, clique em "+", selecione o tipo Nonintegrated/Integrada conforme o cenário e defina Process Name (ex: R_INI).
6Apontar trilha e credenciais do Replicat de carga
Informe a Trilha de Replicat (mesma usada pelo Extract de carga), a credencial de destino e a tabela de checkpoint criada anteriormente.
7Mapear a tabela de destino e criar
No editor de parâmetros, defina o MAP de origem para o nome da tabela de destino e confirme com "Criar" (mantendo o processo parado até a hora da execução).
8Configurar o Replicat Online (CDC Applier)
Crie um segundo Replicat (ex: R_CDC) do tipo Parallel Replicat, apontando para a trilha contínua gerada pelo EX_CDC e para a mesma tabela de checkpoint.
9Ajustar parâmetros de transição (HANDLECOLLISIONS)
No editor, adicione BATCHSQL, o paralelismo desejado e a diretiva HANDLECOLLISIONS — que evita erro de chave duplicada durante a janela de transição entre carga inicial e CDC.
10Orquestrar a execução e remover HANDLECOLLISIONS depois
Inicie o EX_INI (que para sozinho ao terminar), depois o R_INI (idem), e só então o R_CDC — que assume o fluxo contínuo. Após o Lag chegar a zero, edite o R_CDC e substitua HANDLECOLLISIONS por NOHANDLECOLLISIONS antes de reiniciar, evitando mascarar erros legítimos no futuro.
Passo a Passo — Replicação Heterogênea (Oracle → MySQL e Oracle → PostgreSQL)
Visão condensada do fluxo entre servidores e plataformas distintas, com Distribution Path/WSS ligando os Administration Services de origem e destino.
1Preparar a origem (Oracle)
Confirme FORCE LOGGING e SUPPLEMENTAL LOG DATA já ativos e habilite o log da tabela específica: ADD TRANDATA HR.DEPARTMENTS, ALLCOLS.
2Preparar o destino MySQL
Crie a base e a tabela equivalente e conceda os privilégios mínimos ao usuário de aplicação: GRANT SELECT, INSERT, UPDATE, DELETE ON RH.* TO 'oggadmin'@'%';
3Preparar o destino PostgreSQL (alternativa)
Crie usuário, database e schema dedicados, conceda privilégios nas tabelas e crie a tabela de destino equivalente em oggschema.
4Catalogar as credenciais nos dois servidores
Em cada Administration Service (origem e destino), cadastre o alias de conexão ao respectivo banco via ALTER CREDENTIALSTORE.
5Configurar a captura na origem
Crie o Extract, registre-o, defina a trilha local e o mapeamento — igual ao fluxo homogêneo, porém apontando apenas a(s) tabela(s) do cenário heterogêneo.
6Criar o caminho de rede (Distribution/Path)
Use ADD DISTPATH (destino MySQL) ou ADD PATH ... TARGET PROTOCOL WSS (destino PostgreSQL) para transportar a trilha até o Receiver Service remoto — ver comandos ao lado.
7Configurar a entrega no destino
No servidor remoto, crie a tabela de checkpoint e o Replicat, mapeando o formato de 3 partes do Oracle (PDB.schema.tabela) para o formato de 2 partes de MySQL/PostgreSQL (database.tabela).
8Validar com um INSERT real
Insira um registro na origem e confirme, em segundos, que ele aparece na tabela de destino — a prova definitiva de que o pipeline heterogêneo está funcionando.
Checklist de conclusão
Módulo 08
Arquiteturas Avançadas
Active-Active, isolamento de carga, múltiplos grupos e alta disponibilidade
FORMAÇÃO ENTERPRISE
Arquiteturas Avançadas
Desenhe topologias resilientes e escaláveis, evitando loops, conflitos e concentração de carga.
Abrir apostila original em PDF ↗Competências desenvolvidas
- ✓Comparar Active-Passive e Active-Active
- ✓Separar grupos por criticidade ou volume
- ✓Prevenir loops e conflitos
- ✓Dimensionar CPU, memória, I/O e rede
Critério de conclusão
Leia as explicações, execute os comandos no simulador, compare o resultado esperado e confirme o laboratório.
Resultado esperado
Grupos isolados por carga, ausência de recaptura de transações replicadas e plano de failover documentado e testado.
1. Active-Active
Dois ambientes podem receber escrita, mas isso exige estratégia de chaves, detecção de conflito, prevenção de loops e regras claras de propriedade dos dados. Nem toda aplicação é candidata.
2. Escalabilidade horizontal
Dividir objetos entre Extracts e Replicats reduz domínio de falha e permite tuning específico. A divisão deve considerar dependência transacional para evitar inconsistência entre tabelas relacionadas.
3. Alta disponibilidade
Service Manager, filesystem, VIP/DNS e banco precisam fazer parte do desenho. Reiniciar processos em outro host sem acesso aos mesmos checkpoints e trails pode causar perda ou duplicação.
Visão do fluxo
Site A
→
Extract A
→
Bi-directional Trails
→
Replicat B
→
Site B
→
Conflict Handling
Representação didática para apoiar o entendimento da sequência operacional deste módulo.
Laboratório prático
12 comandos e verificações para praticar o conteúdo.
INFO ALLExplicação técnica do comando
O que este comando faz: Apresenta uma visão consolidada dos grupos GoldenGate conhecidos pelo deployment, incluindo Extracts e Replicats, seus estados e o lag registrado no último checkpoint.
Como interpretar e aplicar: É um dos primeiros comandos de triagem operacional. Processos RUNNING indicam atividade, mas a saúde real exige verificar se checkpoints avançam, se o lag permanece estável e se não existem mensagens de erro nos report files. STOPPED pode ser planejado; ABENDED indica encerramento anormal e demanda investigação imediata.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
ADD EXTRACT E_FIN, INTEGRATED TRANLOG, BEGIN NOWExplicação técnica do comando
O que este comando faz: Cria o grupo de captura e define o modo integrado, a origem dos logs e o ponto inicial de processamento.
Como interpretar e aplicar: BEGIN NOW inicia a partir do momento da criação, não realizando carga histórica. Para migração, sincronize o ponto de corte com initial load ou instanciamento do destino. Confirme nome, modo e checkpoint após criar.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
ADD EXTRACT E_SALES, INTEGRATED TRANLOG, BEGIN NOWExplicação técnica do comando
O que este comando faz: Cria o grupo de captura e define o modo integrado, a origem dos logs e o ponto inicial de processamento.
Como interpretar e aplicar: BEGIN NOW inicia a partir do momento da criação, não realizando carga histórica. Para migração, sincronize o ponto de corte com initial load ou instanciamento do destino. Confirme nome, modo e checkpoint após criar.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
ADD REPLICAT R_FIN, INTEGRATED, EXTTRAIL ./dirdat/faExplicação técnica do comando
O que este comando faz: Cria o processo de aplicação que lê o trail e executa as operações correspondentes no banco de destino.
Como interpretar e aplicar: No modo integrado, o Replicat trabalha com o inbound server do Oracle e pode aplicar transações em paralelo. O checkpoint table registra progresso de forma confiável; valide schema, trail e ponto inicial.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
ADD REPLICAT R_SALES, INTEGRATED, EXTTRAIL ./dirdat/saExplicação técnica do comando
O que este comando faz: Cria o processo de aplicação que lê o trail e executa as operações correspondentes no banco de destino.
Como interpretar e aplicar: No modo integrado, o Replicat trabalha com o inbound server do Oracle e pode aplicar transações em paralelo. O checkpoint table registra progresso de forma confiável; valide schema, trail e ponto inicial.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
TRANLOGOPTIONS EXCLUDEUSER ggadminExplicação técnica do comando
O que este comando faz: Executa uma operação administrativa ou uma validação relacionada ao conteúdo deste módulo.
Como interpretar e aplicar: O resultado deve ser analisado em conjunto com o estado dos processos, checkpoints, logs e dependências da arquitetura, pois um retorno isolado não comprova que todo o fluxo de replicação está saudável.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
DBOPTIONS SETTAG 00Explicação técnica do comando
O que este comando faz: Executa uma operação administrativa ou uma validação relacionada ao conteúdo deste módulo.
Como interpretar e aplicar: O resultado deve ser analisado em conjunto com o estado dos processos, checkpoints, logs e dependências da arquitetura, pois um retorno isolado não comprova que todo o fluxo de replicação está saudável.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
MAP APP.*, TARGET APP.*, FILTER (@GETENV('TRANSACTION','CSN') > 0);Explicação técnica do comando
O que este comando faz: Define o escopo de objetos capturados ou o mapeamento entre tabelas de origem e destino.
Como interpretar e aplicar: Padrões com asterisco simplificam configuração, mas podem incluir objetos novos sem avaliação. COLMAP realiza transformação de colunas e exige testes de tipos, chaves, defaults, timezone e regras de negócio.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
SEND EXTRACT E_FIN, STATUSExplicação técnica do comando
O que este comando faz: Envia uma solicitação de controle ou diagnóstico para um processo em execução sem alterar seu arquivo de parâmetros.
Como interpretar e aplicar: A opção LOGEND, por exemplo, verifica se o Extract alcançou o fim atual do log. O retorno ajuda a distinguir processo ocioso de processo atrasado. Consulte a sintaxe específica da versão antes do uso.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
SEND REPLICAT R_FIN, STATUSExplicação técnica do comando
O que este comando faz: Envia uma solicitação de controle ou diagnóstico para um processo em execução sem alterar seu arquivo de parâmetros.
Como interpretar e aplicar: A opção LOGEND, por exemplo, verifica se o Extract alcançou o fim atual do log. O retorno ajuda a distinguir processo ocioso de processo atrasado. Consulte a sintaxe específica da versão antes do uso.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
LAG EXTRACT E_FINExplicação técnica do comando
O que este comando faz: Mede a diferença temporal entre a posição processada e os dados disponíveis, ajudando a identificar atraso na captura ou aplicação.
Como interpretar e aplicar: Lag momentâneo pode ocorrer em picos; tendência crescente indica que o processo não acompanha a carga. Correlacione com CPU, I/O, rede, transações longas, locks, volume e taxa de geração de redo.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
LAG REPLICAT R_FINExplicação técnica do comando
O que este comando faz: Mede a diferença temporal entre a posição processada e os dados disponíveis, ajudando a identificar atraso na captura ou aplicação.
Como interpretar e aplicar: Lag momentâneo pode ocorrer em picos; tendência crescente indica que o processo não acompanha a carga. Correlacione com CPU, I/O, rede, transações longas, locks, volume e taxa de geração de redo.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
EXTRACT ext_int
USERIDALIAS ogg_connection_profile
EXTTRAIL ./dirdat/et
TABLE crm.clientes_anexos;Explicação técnica do comando
O que este comando faz: Isola, em um Extract dedicado, uma tabela volumosa ou com colunas LOB que está gerando lentidão para as demais, evitando que ela "engarrafe" toda a captura.
Como interpretar e aplicar: Crie um segundo Extract padrão (ext_std) com EXCLUDE TABLE para essa mesma tabela, cobrindo todo o restante do schema. Replique a mesma divisão no Replicat com MAP/EXCLUDE.
Cuidados antes da execução: Nunca separe tabelas com relacionamento de chave estrangeira (FK) em grupos de processo diferentes — isso causa ORA-02291 no destino ao tentar inserir o registro filho antes do pai.
EXTRACT ext_std
USERIDALIAS ogg_connection_profile
EXTTRAIL ./dirdat/st
TABLE crm.*, EXCLUDE TABLE crm.clientes_anexos;Explicação técnica do comando
O que este comando faz: Complementa o Extract isolado, capturando todas as demais tabelas do schema exceto a que já está sendo tratada separadamente em ext_int.
Como interpretar e aplicar: Mantenha os dois Extracts (ext_int e ext_std) e seus respectivos Replicats sincronizados na documentação de arquitetura, incluindo o critério de particionamento usado.
Cuidados antes da execução: Documente sempre o critério de particionamento de tabelas por grupo — é a causa mais comum de inconsistência quando um novo DBA assume a operação do ambiente.
SELECT round(bytes/1024/1024/1024,1) AS gb_por_processo FROM v$sgainfo WHERE name = 'Streams Pool Size';Explicação técnica do comando
O que este comando faz: Ajuda a estimar o consumo de memória do Streams Pool, insumo do cálculo de Swap Total recomendado antes de escalar múltiplos grupos de Extract/Replicat em paralelo.
Como interpretar e aplicar: Combine o resultado com a estimativa de 25–55 MB de RAM real por processo clássico para dimensionar o Swap Total = valor arredondado (GB) × quantidade de processos planejados.
Cuidados antes da execução: Revise este dimensionamento sempre que adicionar novos grupos de processo — falhas de out-of-memory silenciosas em produção são frequentemente causadas por escalar processos sem recalcular a memória disponível.
Os 4 Pilares da Arquitetura Paralela
Diagrama de referência para desenhar múltiplos Extracts, Trail Files, DISTPATHs e Replicats trabalhando em conjunto.
💡 Dica de campo: em servidores Windows, o número de grupos ativos é limitado pelo Desktop Heap não-interativo. Acima de ~60 grupos combinados, use Spread Deployment — múltiplos Deployments sob o mesmo Service Manager — em vez de um único GoldenGate Home sobrecarregado.
Checklist de conclusão
Módulo 09
Gestão, Monitoramento e Diagnóstico
Métricas, heartbeat, relatórios, logs e resposta a incidentes
FORMAÇÃO ENTERPRISE
Gestão, Monitoramento e Diagnóstico
Monitore a saúde operacional, detecte lag antes do impacto e organize evidências para troubleshooting.
Abrir apostila original em PDF ↗Competências desenvolvidas
- ✓Interpretar lag de checkpoint e de registro
- ✓Ativar Heartbeat Tables
- ✓Analisar reports e discard files
- ✓Estruturar diagnóstico de processo ABENDED
Critério de conclusão
Leia as explicações, execute os comandos no simulador, compare o resultado esperado e confirme o laboratório.
Resultado esperado
Heartbeat ativo, métricas coletadas e procedimento de diagnóstico capaz de identificar o estágio exato do atraso ou falha.
1. Métricas essenciais
Monitore status, throughput, lag, taxa de operações, crescimento de trails, CPU, memória, I/O e conectividade. Uma única métrica não explica todo o pipeline.
2. Heartbeat
Heartbeat Tables geram registros periódicos que atravessam o fluxo e medem latência ponta a ponta. Elas ajudam a separar atraso real de ausência de transações na origem.
3. Resposta a incidentes
Ao encontrar ABENDED, preserve report, ggserr.log, parâmetros e posição de checkpoint. Corrija a causa antes de reiniciar; reinicializações repetidas podem ocultar evidências e ampliar o problema.
Visão do fluxo
Metrics
→
Alert
→
Triage
→
Evidence
→
Root Cause
→
Recovery
→
Postmortem
Representação didática para apoiar o entendimento da sequência operacional deste módulo.
Laboratório prático
13 comandos e verificações para praticar o conteúdo.
INFO ALLExplicação técnica do comando
O que este comando faz: Apresenta uma visão consolidada dos grupos GoldenGate conhecidos pelo deployment, incluindo Extracts e Replicats, seus estados e o lag registrado no último checkpoint.
Como interpretar e aplicar: É um dos primeiros comandos de triagem operacional. Processos RUNNING indicam atividade, mas a saúde real exige verificar se checkpoints avançam, se o lag permanece estável e se não existem mensagens de erro nos report files. STOPPED pode ser planejado; ABENDED indica encerramento anormal e demanda investigação imediata.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
INFO EXTRACT E_ORA1, DETAILExplicação técnica do comando
O que este comando faz: Exibe informações de configuração e execução do objeto solicitado, permitindo confirmar existência, tipo, checkpoint, trail associado e estado atual.
Como interpretar e aplicar: Use a saída para comparar a configuração ativa com o desenho esperado. Em processos de captura ou aplicação, observe posição de leitura, horário do checkpoint e parâmetros vinculados. Diferenças entre o cadastro e a documentação podem indicar alteração não controlada ou implantação incompleta.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
INFO REPLICAT R_ORA1, DETAILExplicação técnica do comando
O que este comando faz: Exibe informações de configuração e execução do objeto solicitado, permitindo confirmar existência, tipo, checkpoint, trail associado e estado atual.
Como interpretar e aplicar: Use a saída para comparar a configuração ativa com o desenho esperado. Em processos de captura ou aplicação, observe posição de leitura, horário do checkpoint e parâmetros vinculados. Diferenças entre o cadastro e a documentação podem indicar alteração não controlada ou implantação incompleta.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
LAG EXTRACT E_ORA1Explicação técnica do comando
O que este comando faz: Mede a diferença temporal entre a posição processada e os dados disponíveis, ajudando a identificar atraso na captura ou aplicação.
Como interpretar e aplicar: Lag momentâneo pode ocorrer em picos; tendência crescente indica que o processo não acompanha a carga. Correlacione com CPU, I/O, rede, transações longas, locks, volume e taxa de geração de redo.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
LAG REPLICAT R_ORA1Explicação técnica do comando
O que este comando faz: Mede a diferença temporal entre a posição processada e os dados disponíveis, ajudando a identificar atraso na captura ou aplicação.
Como interpretar e aplicar: Lag momentâneo pode ocorrer em picos; tendência crescente indica que o processo não acompanha a carga. Correlacione com CPU, I/O, rede, transações longas, locks, volume e taxa de geração de redo.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
STATS EXTRACT E_ORA1, TOTALExplicação técnica do comando
O que este comando faz: Apresenta estatísticas de operações processadas, como inserts, updates, deletes e total de registros.
Como interpretar e aplicar: Use as estatísticas para confirmar atividade, comparar throughput e detectar objetos sem movimento esperado. Zerar estatísticas pode facilitar medição em uma janela, mas preserve evidências quando houver incidente.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
STATS REPLICAT R_ORA1, TOTALExplicação técnica do comando
O que este comando faz: Apresenta estatísticas de operações processadas, como inserts, updates, deletes e total de registros.
Como interpretar e aplicar: Use as estatísticas para confirmar atividade, comparar throughput e detectar objetos sem movimento esperado. Zerar estatísticas pode facilitar medição em uma janela, mas preserve evidências quando houver incidente.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
VIEW REPORT E_ORA1Explicação técnica do comando
O que este comando faz: Executa uma operação administrativa ou uma validação relacionada ao conteúdo deste módulo.
Como interpretar e aplicar: O resultado deve ser analisado em conjunto com o estado dos processos, checkpoints, logs e dependências da arquitetura, pois um retorno isolado não comprova que todo o fluxo de replicação está saudável.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
VIEW REPORT R_ORA1Explicação técnica do comando
O que este comando faz: Executa uma operação administrativa ou uma validação relacionada ao conteúdo deste módulo.
Como interpretar e aplicar: O resultado deve ser analisado em conjunto com o estado dos processos, checkpoints, logs e dependências da arquitetura, pois um retorno isolado não comprova que todo o fluxo de replicação está saudável.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
VIEW GGSEVTExplicação técnica do comando
O que este comando faz: Executa uma operação administrativa ou uma validação relacionada ao conteúdo deste módulo.
Como interpretar e aplicar: O resultado deve ser analisado em conjunto com o estado dos processos, checkpoints, logs e dependências da arquitetura, pois um retorno isolado não comprova que todo o fluxo de replicação está saudável.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
ADD HEARTBEATTABLEExplicação técnica do comando
O que este comando faz: Executa uma operação administrativa ou uma validação relacionada ao conteúdo deste módulo.
Como interpretar e aplicar: O resultado deve ser analisado em conjunto com o estado dos processos, checkpoints, logs e dependências da arquitetura, pois um retorno isolado não comprova que todo o fluxo de replicação está saudável.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
INFO HEARTBEATTABLEExplicação técnica do comando
O que este comando faz: Exibe informações de configuração e execução do objeto solicitado, permitindo confirmar existência, tipo, checkpoint, trail associado e estado atual.
Como interpretar e aplicar: Use a saída para comparar a configuração ativa com o desenho esperado. Em processos de captura ou aplicação, observe posição de leitura, horário do checkpoint e parâmetros vinculados. Diferenças entre o cadastro e a documentação podem indicar alteração não controlada ou implantação incompleta.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
SEND REPLICAT R_ORA1, STATUSExplicação técnica do comando
O que este comando faz: Envia uma solicitação de controle ou diagnóstico para um processo em execução sem alterar seu arquivo de parâmetros.
Como interpretar e aplicar: A opção LOGEND, por exemplo, verifica se o Extract alcançou o fim atual do log. O retorno ajuda a distinguir processo ocioso de processo atrasado. Consulte a sintaxe específica da versão antes do uso.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
VIEW HEARTBEAT HISTORY FOR ALLExplicação técnica do comando
O que este comando faz: Exibe o histórico de latência ponta a ponta calculado pelas Heartbeat Tables, separando o lag de checkpoint (captura na origem) do lag de aplicação (chegada no destino).
Como interpretar e aplicar: Use depois de configurar ADD HEARTBEATTABLE; a tabela resultante (GG_LAG) traz as colunas INCOMING_LAG e OUTGOING_LAG, essenciais para diferenciar onde está o gargalo.
Cuidados antes da execução: Se o lag crescer apenas no Replicat, o gargalo normalmente está no banco de destino — não no GoldenGate em si. Investigue contenção, índices e I/O no alvo antes de tunar o processo.
STATUS EXTRACT E_ORA1Explicação técnica do comando
O que este comando faz: Consulta rapidamente se um processo específico está RUNNING, STOPPED ou ABENDED, sem o detalhamento completo retornado pelo INFO.
Como interpretar e aplicar: Ideal para scripts de monitoramento externos (cron, Zabbix, Prometheus, Grafana via StatsD) que só precisam do status binário do processo para gerar um alerta.
Cuidados antes da execução: Combine sempre com LAG e STATS para confirmar que "rodando" também significa "saudável" — um processo RUNNING com lag crescente ainda é um problema em produção.
df -hExplicação técnica do comando
O que este comando faz: Comando de sistema operacional que verifica o espaço livre em disco — a causa mais comum e mais simples de paradas inesperadas do GoldenGate.
Como interpretar e aplicar: Execute antes de qualquer investigação mais profunda no OGG, prestando atenção especial aos filesystems de OGG_VAR_HOME e do diretório dos trail files.
Cuidados antes da execução: Automatize um alerta de disco (ex: 85% de uso) para evitar que o ambiente pare por falta de espaço durante a madrugada, sem ninguém monitorando ativamente.
systemctl status OracleGoldenGateExplicação técnica do comando
O que este comando faz: Confirma, a nível de sistema operacional, se o daemon do Service Manager está ativo (active running) após um boot ou reinício do servidor.
Como interpretar e aplicar: É o primeiro comando a rodar quando nenhum serviço do OGG responde via console web ou Admin Client — antes de suspeitar de problemas dentro do próprio GoldenGate.
Cuidados antes da execução: Se o status não for "active (running)", verifique journalctl -u OracleGoldenGate antes de tentar reiniciar manualmente os serviços.
Checklist de conclusão
Módulo 10
OGG Healthcheck Script
Coleta automatizada, relatório HTML e evidências para suporte
FORMAÇÃO ENTERPRISE
OGG Healthcheck Script
Execute uma avaliação estruturada do ambiente, consolide configurações e identifique riscos antes que se tornem incidentes.
Abrir apostila original em PDF ↗Competências desenvolvidas
- ✓Preparar coleta sem expor credenciais
- ✓Interpretar severidades e achados
- ✓Comparar configurações com boas práticas
- ✓Montar pacote técnico para suporte
Critério de conclusão
Leia as explicações, execute os comandos no simulador, compare o resultado esperado e confirme o laboratório.
Resultado esperado
Relatório gerado, achados priorizados e pacote de evidências sanitizado, íntegro e pronto para revisão técnica.
1. Escopo da coleta
O health check reúne versão, processos, parâmetros, banco, sistema operacional, trails, métricas e logs. Revise o script antes da execução e aplique o princípio de menor privilégio.
2. Interpretação
Classifique achados por criticidade, impacto, evidência e recomendação. Nem todo alerta exige mudança imediata; valide contexto, janela e dependências.
3. Evidências
Mantenha relatório, horário da coleta, topologia, versões e mudanças recentes. Antes de enviar arquivos a terceiros, remova senhas, tokens, endereços sensíveis e dados de negócio.
Visão do fluxo
Collect
→
Normalize
→
Analyze
→
HTML Report
→
Risk Register
→
Action Plan
Representação didática para apoiar o entendimento da sequência operacional deste módulo.
Laboratório prático
10 comandos e verificações para praticar o conteúdo.
chmod +x ogghealthcheck.shExplicação técnica do comando
O que este comando faz: Executa uma operação administrativa ou uma validação relacionada ao conteúdo deste módulo.
Como interpretar e aplicar: O resultado deve ser analisado em conjunto com o estado dos processos, checkpoints, logs e dependências da arquitetura, pois um retorno isolado não comprova que todo o fluxo de replicação está saudável.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
./ogghealthcheck.shExplicação técnica do comando
O que este comando faz: Executa uma operação administrativa ou uma validação relacionada ao conteúdo deste módulo.
Como interpretar e aplicar: O resultado deve ser analisado em conjunto com o estado dos processos, checkpoints, logs e dependências da arquitetura, pois um retorno isolado não comprova que todo o fluxo de replicação está saudável.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
./ogghealthcheck.sh --deployment DEPLOYMENT1Explicação técnica do comando
O que este comando faz: Executa uma operação administrativa ou uma validação relacionada ao conteúdo deste módulo.
Como interpretar e aplicar: O resultado deve ser analisado em conjunto com o estado dos processos, checkpoints, logs e dependências da arquitetura, pois um retorno isolado não comprova que todo o fluxo de replicação está saudável.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
find . -maxdepth 2 -type f -name "*report*" -o -name "*.log"Explicação técnica do comando
O que este comando faz: Executa uma operação administrativa ou uma validação relacionada ao conteúdo deste módulo.
Como interpretar e aplicar: O resultado deve ser analisado em conjunto com o estado dos processos, checkpoints, logs e dependências da arquitetura, pois um retorno isolado não comprova que todo o fluxo de replicação está saudável.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
unzip -l OGGHC_*.zipExplicação técnica do comando
O que este comando faz: Executa uma operação administrativa ou uma validação relacionada ao conteúdo deste módulo.
Como interpretar e aplicar: O resultado deve ser analisado em conjunto com o estado dos processos, checkpoints, logs e dependências da arquitetura, pois um retorno isolado não comprova que todo o fluxo de replicação está saudável.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
grep -RniE "critical|warning|abended|lag" OGGHC_*Explicação técnica do comando
O que este comando faz: Executa uma operação administrativa ou uma validação relacionada ao conteúdo deste módulo.
Como interpretar e aplicar: O resultado deve ser analisado em conjunto com o estado dos processos, checkpoints, logs e dependências da arquitetura, pois um retorno isolado não comprova que todo o fluxo de replicação está saudável.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
grep -Rni "PASSWORD" OGGHC_*Explicação técnica do comando
O que este comando faz: Executa uma operação administrativa ou uma validação relacionada ao conteúdo deste módulo.
Como interpretar e aplicar: O resultado deve ser analisado em conjunto com o estado dos processos, checkpoints, logs e dependências da arquitetura, pois um retorno isolado não comprova que todo o fluxo de replicação está saudável.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
tar -czf ogghc_sanitized_bundle.tar.gz OGGHC_*Explicação técnica do comando
O que este comando faz: Executa uma operação administrativa ou uma validação relacionada ao conteúdo deste módulo.
Como interpretar e aplicar: O resultado deve ser analisado em conjunto com o estado dos processos, checkpoints, logs e dependências da arquitetura, pois um retorno isolado não comprova que todo o fluxo de replicação está saudável.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
sha256sum ogghc_sanitized_bundle.tar.gzExplicação técnica do comando
O que este comando faz: Executa uma operação administrativa ou uma validação relacionada ao conteúdo deste módulo.
Como interpretar e aplicar: O resultado deve ser analisado em conjunto com o estado dos processos, checkpoints, logs e dependências da arquitetura, pois um retorno isolado não comprova que todo o fluxo de replicação está saudável.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
du -sh OGGHC_*Explicação técnica do comando
O que este comando faz: Executa uma operação administrativa ou uma validação relacionada ao conteúdo deste módulo.
Como interpretar e aplicar: O resultado deve ser analisado em conjunto com o estado dos processos, checkpoints, logs e dependências da arquitetura, pois um retorno isolado não comprova que todo o fluxo de replicação está saudável.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
cd $OGG_HOME/lib/sql/healthcheckExplicação técnica do comando
O que este comando faz: Navega até o diretório oficial onde a Oracle distribui os scripts SQL do Healthcheck (OGGHC) junto com o próprio instalador do GoldenGate 26ai.
Como interpretar e aplicar: É o primeiro passo antes de qualquer coleta — os scripts não precisam de download separado, eles já vêm dentro do OGG_HOME instalado.
Cuidados antes da execução: Confirme que está no OGG_HOME correto quando houver múltiplas instalações no mesmo servidor (Spread Deployment) antes de executar qualquer script.
sqlplus / as sysdbaExplicação técnica do comando
O que este comando faz: Conecta ao banco de dados com privilégios SYSDBA — requisito da Oracle para executar o Healthcheck com acesso completo às views internas necessárias ao diagnóstico.
Como interpretar e aplicar: O script precisa acessar views X$, disponíveis apenas para SYSDBA. Usuários comuns geram relatórios incompletos, ocultando seções críticas de performance.
Cuidados antes da execução: Use esta sessão apenas para o ciclo de diagnóstico e encerre-a logo após a desinstalação dos objetos, evitando sessões SYSDBA abertas desnecessariamente.
@ogghc_install.sqlExplicação técnica do comando
O que este comando faz: Instala as packages PL/SQL necessárias no banco de dados para viabilizar a coleta de dados do Healthcheck.
Como interpretar e aplicar: Execute uma única vez por ciclo de troubleshooting, sempre antes do @ogghc_run.sql.
Cuidados antes da execução: Em bancos com Oracle Data Vault ou políticas de segurança restritivas, confirme com o time de segurança antes de instalar objetos adicionais no dicionário de dados.
@ogghc_run.sqlExplicação técnica do comando
O que este comando faz: Executa a coleta completa e gera o relatório HTML final, consolidando centenas de queries internas em um único arquivo navegável pelo browser.
Como interpretar e aplicar: O tempo de execução varia de minutos a dezenas de minutos, dependendo do tamanho do dicionário e da atividade do banco. O nome do arquivo gerado inclui a instância e um timestamp.
Cuidados antes da execução: Execute fora do horário de pico de produção sempre que possível — a coleta gera carga adicional temporária de leitura no banco de dados.
@ogghc_deinstall.sqlExplicação técnica do comando
O que este comando faz: Remove todos os objetos PL/SQL criados pelo Healthcheck, devolvendo o dicionário de dados ao estado original.
Como interpretar e aplicar: Execute sempre ao final do ciclo de troubleshooting, como boa prática de governança e conformidade de auditoria.
Cuidados antes da execução: Pular esta etapa deixa objetos residentes no banco — audite periodicamente ambientes onde o Healthcheck é executado com frequência para garantir que a limpeza está sendo feita.
As 5 Macro-Seções do Relatório OGGHC
Conhecer a função de cada seção do HTML gerado acelera drasticamente o diagnóstico em situações críticas (Severidade 1).
💡 Dica de ouro: para localizar o SQL agressor de um Replicat lento, vá direto em Tools → Truncates e cruze o ASH (V$ACTIVE_SESSION_HISTORY) com a SQLAREA — economiza horas de investigação manual em logs.
Checklist de conclusão
Módulo 11
Otimização de Performance
Throughput, paralelismo, CACHEMGR, BATCHSQL e grandes transações
FORMAÇÃO ENTERPRISE
Otimização de Performance
Identifique gargalos no pipeline e aplique ajustes mensuráveis sem comprometer consistência.
Abrir apostila original em PDF ↗Competências desenvolvidas
- ✓Localizar o estágio limitante
- ✓Dimensionar paralelismo de captura e aplicação
- ✓Tratar tabelas de alto volume
- ✓Validar ganho com baseline antes/depois
Critério de conclusão
Leia as explicações, execute os comandos no simulador, compare o resultado esperado e confirme o laboratório.
Resultado esperado
Gargalo identificado por evidência, ganho comparado com baseline e parâmetros documentados com justificativa e plano de rollback.
1. Método de tuning
Comece com baseline: taxa de transações, lag, CPU, I/O, rede e tamanho médio das operações. Ajustar parâmetros sem identificar o gargalo pode apenas deslocar o problema.
2. Captura e transporte
Avalie geração de redo, leitura de archive, cache, tamanho de trail, latência e bandwidth. Em RAC, acompanhe todos os threads de redo e disponibilidade dos archives.
3. Aplicação
Parallel Replicat, Integrated Replicat e BATCHSQL podem aumentar throughput. O benefício depende da independência entre transações, chaves adequadas e capacidade do banco destino.
Visão do fluxo
Baseline
→
Find Bottleneck
→
Tune One Variable
→
Load Test
→
Compare
→
Standardize
Representação didática para apoiar o entendimento da sequência operacional deste módulo.
Laboratório prático
12 comandos e verificações para praticar o conteúdo.
STATS EXTRACT E_ORA1, TOTALExplicação técnica do comando
O que este comando faz: Apresenta estatísticas de operações processadas, como inserts, updates, deletes e total de registros.
Como interpretar e aplicar: Use as estatísticas para confirmar atividade, comparar throughput e detectar objetos sem movimento esperado. Zerar estatísticas pode facilitar medição em uma janela, mas preserve evidências quando houver incidente.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
STATS REPLICAT R_ORA1, TOTALExplicação técnica do comando
O que este comando faz: Apresenta estatísticas de operações processadas, como inserts, updates, deletes e total de registros.
Como interpretar e aplicar: Use as estatísticas para confirmar atividade, comparar throughput e detectar objetos sem movimento esperado. Zerar estatísticas pode facilitar medição em uma janela, mas preserve evidências quando houver incidente.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
LAG EXTRACT E_ORA1Explicação técnica do comando
O que este comando faz: Mede a diferença temporal entre a posição processada e os dados disponíveis, ajudando a identificar atraso na captura ou aplicação.
Como interpretar e aplicar: Lag momentâneo pode ocorrer em picos; tendência crescente indica que o processo não acompanha a carga. Correlacione com CPU, I/O, rede, transações longas, locks, volume e taxa de geração de redo.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
LAG REPLICAT R_ORA1Explicação técnica do comando
O que este comando faz: Mede a diferença temporal entre a posição processada e os dados disponíveis, ajudando a identificar atraso na captura ou aplicação.
Como interpretar e aplicar: Lag momentâneo pode ocorrer em picos; tendência crescente indica que o processo não acompanha a carga. Correlacione com CPU, I/O, rede, transações longas, locks, volume e taxa de geração de redo.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
SEND EXTRACT E_ORA1, CACHEMGR CACHESTATSExplicação técnica do comando
O que este comando faz: Envia uma solicitação de controle ou diagnóstico para um processo em execução sem alterar seu arquivo de parâmetros.
Como interpretar e aplicar: A opção LOGEND, por exemplo, verifica se o Extract alcançou o fim atual do log. O retorno ajuda a distinguir processo ocioso de processo atrasado. Consulte a sintaxe específica da versão antes do uso.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
CACHEMGR CACHESIZE 8GBExplicação técnica do comando
O que este comando faz: Executa uma operação administrativa ou uma validação relacionada ao conteúdo deste módulo.
Como interpretar e aplicar: O resultado deve ser analisado em conjunto com o estado dos processos, checkpoints, logs e dependências da arquitetura, pois um retorno isolado não comprova que todo o fluxo de replicação está saudável.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
BATCHSQLExplicação técnica do comando
O que este comando faz: Executa uma operação administrativa ou uma validação relacionada ao conteúdo deste módulo.
Como interpretar e aplicar: O resultado deve ser analisado em conjunto com o estado dos processos, checkpoints, logs e dependências da arquitetura, pois um retorno isolado não comprova que todo o fluxo de replicação está saudável.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
DBOPTIONS INTEGRATEDPARAMS (PARALLELISM 8, MAX_PARALLELISM 32)Explicação técnica do comando
O que este comando faz: Executa uma operação administrativa ou uma validação relacionada ao conteúdo deste módulo.
Como interpretar e aplicar: O resultado deve ser analisado em conjunto com o estado dos processos, checkpoints, logs e dependências da arquitetura, pois um retorno isolado não comprova que todo o fluxo de replicação está saudável.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
TRANSACTIONTIMEOUT 10mExplicação técnica do comando
O que este comando faz: Executa uma operação administrativa ou uma validação relacionada ao conteúdo deste módulo.
Como interpretar e aplicar: O resultado deve ser analisado em conjunto com o estado dos processos, checkpoints, logs e dependências da arquitetura, pois um retorno isolado não comprova que todo o fluxo de replicação está saudável.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
MAP SRC.BIG_TABLE, TARGET TGT.BIG_TABLE, KEYCOLS(ID);Explicação técnica do comando
O que este comando faz: Define o escopo de objetos capturados ou o mapeamento entre tabelas de origem e destino.
Como interpretar e aplicar: Padrões com asterisco simplificam configuração, mas podem incluir objetos novos sem avaliação. COLMAP realiza transformação de colunas e exige testes de tipos, chaves, defaults, timezone e regras de negócio.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
MAP SRC.BIG_TABLE, TARGET TGT.BIG_TABLE, FILTER (@RANGE(1,4,ID));Explicação técnica do comando
O que este comando faz: Define o escopo de objetos capturados ou o mapeamento entre tabelas de origem e destino.
Como interpretar e aplicar: Padrões com asterisco simplificam configuração, mas podem incluir objetos novos sem avaliação. COLMAP realiza transformação de colunas e exige testes de tipos, chaves, defaults, timezone e regras de negócio.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
INFO REPLICAT R_ORA1, DETAILExplicação técnica do comando
O que este comando faz: Exibe informações de configuração e execução do objeto solicitado, permitindo confirmar existência, tipo, checkpoint, trail associado e estado atual.
Como interpretar e aplicar: Use a saída para comparar a configuração ativa com o desenho esperado. Em processos de captura ou aplicação, observe posição de leitura, horário do checkpoint e parâmetros vinculados. Diferenças entre o cadastro e a documentação podem indicar alteração não controlada ou implantação incompleta.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
CACHEMGR CACHESIZE 32G, CACHEDIRECTORY /u02/ogg_fast_cacheExplicação técnica do comando
O que este comando faz: Redimensiona o Cache Manager para comportar transações abertas de longa duração sem estourar a RAM física, apontando o overflow para um disco rápido dedicado.
Como interpretar e aplicar: Ajuste o valor conforme o alerta OGG-01842 (CACHESIZE PER DYNAMIC DETERMINATION) registrado no log do processo. O diretório informado deve residir obrigatoriamente em SSD/NVMe.
Cuidados antes da execução: Apontar CACHEDIRECTORY para um disco lento (ou volume de rede comum) anula completamente o ganho do parâmetro e pode piorar a performance geral do processo.
CHECKPOINTSECS 60Explicação técnica do comando
O que este comando faz: Controla a frequência, em segundos, de gravação dos checkpoints de recuperação do processo, permitindo reduzir I/O em troca de um reprocessamento maior em caso de abend.
Como interpretar e aplicar: Aumente o intervalo em ambientes de altíssimo throughput onde o I/O de checkpoint compete diretamente com o I/O de escrita dos trail files. Não se aplica ao Integrated Replicat.
Cuidados antes da execução: Valores muito altos aumentam o tempo de recuperação após uma falha — equilibre sempre com o SLA de RTO (tempo de recuperação) acordado para o ambiente.
GROUPTRANSOPS 1500Explicação técnica do comando
O que este comando faz: Agrupa múltiplas transações pequenas em uma transação maior antes de aplicar no destino, reduzindo drasticamente a frequência de commits e o I/O gerado no banco alvo.
Como interpretar e aplicar: Eleve o padrão (250) para a faixa de 1000–2000 em cargas com muitos INSERTs/UPDATEs sequenciais pequenos. Combine sempre com BATCHSQL para o melhor resultado.
Cuidados antes da execução: Valores excessivos aumentam a janela de exposição em caso de falha durante a transação agrupada — teste o impacto em homologação antes de aplicar em produção.
ALTER TABLE ogg.ggschkpt PCTFREE 90;Explicação técnica do comando
O que este comando faz: Reduz drasticamente o número de linhas por bloco na tabela de checkpoint do Replicat, eliminando a contenção de Buffer Busy Waits e GC Buffer Busy comum em clusters Oracle RAC.
Como interpretar e aplicar: Aplique antes de iniciar os Replicats pela primeira vez em ambientes RAC. Se os processos já estiverem rodando com a tabela populada, será necessário recriá-la ou executar um REORG completo.
Cuidados antes da execução: É um dos ajustes mais negligenciados em implantações RAC — negligenciá-lo é causa recorrente de chamados de severidade alta relacionados a contenção no interconnect do cluster.
Checklist de conclusão
Módulo 12
Laboratório Final Integrado
Construção, falha controlada, recuperação e validação ponta a ponta
FORMAÇÃO ENTERPRISE
Laboratório Final Integrado
Consolide a formação criando um fluxo completo de replicação, observando seu comportamento e documentando a entrega.
Abrir apostila original em PDF ↗Competências desenvolvidas
- ✓Preparar origem e destino
- ✓Criar Extract, trails e Replicat
- ✓Simular indisponibilidade controlada
- ✓Validar consistência e produzir relatório
Critério de conclusão
Leia as explicações, execute os comandos no simulador, compare o resultado esperado e confirme o laboratório.
Resultado esperado
Pipeline completo recuperado sem perda, dados reconciliados e documentação final contendo arquitetura, evidências e lições aprendidas.
1. Construção
Implemente o pipeline seguindo checklist: banco, usuário, credencial, captura, transporte, aplicação e heartbeat. Registre cada decisão e resultado.
2. Teste de falha
Interrompa um processo no laboratório, gere transações controladas, observe crescimento de lag e retome o fluxo. Confirme que checkpoints preservaram continuidade.
3. Aceite técnico
Compare contagens e amostras, valide lag, revise logs e entregue topologia, parâmetros, evidências e recomendações. O laboratório termina com um relatório executivo e técnico.
Visão do fluxo
Prepare
→
Build
→
Generate Workload
→
Stop Process
→
Observe Lag
→
Recover
→
Reconcile
→
Document
Representação didática para apoiar o entendimento da sequência operacional deste módulo.
Laboratório prático
12 comandos e verificações para praticar o conteúdo.
INFO ALLExplicação técnica do comando
O que este comando faz: Apresenta uma visão consolidada dos grupos GoldenGate conhecidos pelo deployment, incluindo Extracts e Replicats, seus estados e o lag registrado no último checkpoint.
Como interpretar e aplicar: É um dos primeiros comandos de triagem operacional. Processos RUNNING indicam atividade, mas a saúde real exige verificar se checkpoints avançam, se o lag permanece estável e se não existem mensagens de erro nos report files. STOPPED pode ser planejado; ABENDED indica encerramento anormal e demanda investigação imediata.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
STOP REPLICAT R_ORA1Explicação técnica do comando
O que este comando faz: Inicia ou interrompe controladamente o processo GoldenGate indicado.
Como interpretar e aplicar: Após START, confirme RUNNING, avanço de checkpoint e ausência de erros. Antes de STOP, avalie backlog, dependências e janela operacional. Em manutenção, registre posições para facilitar validação posterior.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
LAG REPLICAT R_ORA1Explicação técnica do comando
O que este comando faz: Mede a diferença temporal entre a posição processada e os dados disponíveis, ajudando a identificar atraso na captura ou aplicação.
Como interpretar e aplicar: Lag momentâneo pode ocorrer em picos; tendência crescente indica que o processo não acompanha a carga. Correlacione com CPU, I/O, rede, transações longas, locks, volume e taxa de geração de redo.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
START REPLICAT R_ORA1Explicação técnica do comando
O que este comando faz: Inicia ou interrompe controladamente o processo GoldenGate indicado.
Como interpretar e aplicar: Após START, confirme RUNNING, avanço de checkpoint e ausência de erros. Antes de STOP, avalie backlog, dependências e janela operacional. Em manutenção, registre posições para facilitar validação posterior.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
STATS EXTRACT E_ORA1, TOTALExplicação técnica do comando
O que este comando faz: Apresenta estatísticas de operações processadas, como inserts, updates, deletes e total de registros.
Como interpretar e aplicar: Use as estatísticas para confirmar atividade, comparar throughput e detectar objetos sem movimento esperado. Zerar estatísticas pode facilitar medição em uma janela, mas preserve evidências quando houver incidente.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
STATS REPLICAT R_ORA1, TOTALExplicação técnica do comando
O que este comando faz: Apresenta estatísticas de operações processadas, como inserts, updates, deletes e total de registros.
Como interpretar e aplicar: Use as estatísticas para confirmar atividade, comparar throughput e detectar objetos sem movimento esperado. Zerar estatísticas pode facilitar medição em uma janela, mas preserve evidências quando houver incidente.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
INFO EXTRACT E_ORA1, DETAILExplicação técnica do comando
O que este comando faz: Exibe informações de configuração e execução do objeto solicitado, permitindo confirmar existência, tipo, checkpoint, trail associado e estado atual.
Como interpretar e aplicar: Use a saída para comparar a configuração ativa com o desenho esperado. Em processos de captura ou aplicação, observe posição de leitura, horário do checkpoint e parâmetros vinculados. Diferenças entre o cadastro e a documentação podem indicar alteração não controlada ou implantação incompleta.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
INFO REPLICAT R_ORA1, DETAILExplicação técnica do comando
O que este comando faz: Exibe informações de configuração e execução do objeto solicitado, permitindo confirmar existência, tipo, checkpoint, trail associado e estado atual.
Como interpretar e aplicar: Use a saída para comparar a configuração ativa com o desenho esperado. Em processos de captura ou aplicação, observe posição de leitura, horário do checkpoint e parâmetros vinculados. Diferenças entre o cadastro e a documentação podem indicar alteração não controlada ou implantação incompleta.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
SEND REPLICAT R_ORA1, STATUSExplicação técnica do comando
O que este comando faz: Envia uma solicitação de controle ou diagnóstico para um processo em execução sem alterar seu arquivo de parâmetros.
Como interpretar e aplicar: A opção LOGEND, por exemplo, verifica se o Extract alcançou o fim atual do log. O retorno ajuda a distinguir processo ocioso de processo atrasado. Consulte a sintaxe específica da versão antes do uso.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
SELECT COUNT(*) FROM SRC.CUSTOMER;Explicação técnica do comando
O que este comando faz: Executa uma consulta de diagnóstico para confirmar parâmetros, usuários, containers, volume ou estado dos objetos envolvidos na replicação.
Como interpretar e aplicar: A consulta é somente leitura, mas sua interpretação depende do contexto. Compare valores com o requisito do GoldenGate e com a arquitetura do ambiente. Em RAC ou Multitenant, confirme se a visão e o container consultados representam todo o escopo necessário.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
SELECT COUNT(*) FROM TGT.CUSTOMER;Explicação técnica do comando
O que este comando faz: Executa uma consulta de diagnóstico para confirmar parâmetros, usuários, containers, volume ou estado dos objetos envolvidos na replicação.
Como interpretar e aplicar: A consulta é somente leitura, mas sua interpretação depende do contexto. Compare valores com o requisito do GoldenGate e com a arquitetura do ambiente. Em RAC ou Multitenant, confirme se a visão e o container consultados representam todo o escopo necessário.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
VIEW REPORT R_ORA1Explicação técnica do comando
O que este comando faz: Executa uma operação administrativa ou uma validação relacionada ao conteúdo deste módulo.
Como interpretar e aplicar: O resultado deve ser analisado em conjunto com o estado dos processos, checkpoints, logs e dependências da arquitetura, pois um retorno isolado não comprova que todo o fluxo de replicação está saudável.
Cuidados antes da execução: Execute primeiro em laboratório, confirme a sintaxe suportada pela sua versão e registre o estado anterior. Em produção, utilize usuário com privilégio mínimo, janela aprovada e plano de retorno.
Checklist de conclusão
Avaliação final
Quiz de certificação
25 perguntas · É necessário obter pelo menos 80% e concluir os 12 módulos.
1. Qual serviço gerencia deployments e serviços?
2. Qual processo captura mudanças?
3. Qual recurso remove senhas dos parameter files?
4. Qual opção habilita suporte do banco ao GoldenGate?
5. Qual componente aplica dados no destino?
6. Qual recurso mede latência ponta a ponta?
7. Qual arquivo desacopla captura e aplicação?
8. O que deve ocorrer antes de tuning?
9. Qual formato MySQL é recomendado?
10. Qual comando verifica lag?
11. No Oracle AI Database 26ai, qual role substitui o antigo DBMS_GOLDENGATE_AUTH.GRANT_ADMIN_PRIVILEGE para autorizar um Extract?
12. Qual script deve ser executado após o OGGCA para registrar o Service Manager como daemon do systemd?
13. No PostgreSQL, qual comando garante que o WAL contenha a imagem completa da linha para permitir UPDATE/DELETE corretos?
14. Qual parâmetro do MySQL é obrigatório no OGG 26ai para que alterações de schema (DDL) sejam replicadas corretamente?
15. Por que a Oracle recomenda evitar o protocolo IPC para conexão do Extract com o banco?
16. O erro OGG-08221 / ORA-44004 (invalid qualified SQL name) geralmente é causado por:
17. Qual comando registra formalmente um Extract integrado no dicionário de dados do Oracle, vinculando-o ao LogMiner?
18. Para encadear uma carga inicial com a replicação online sem duplicar dados, qual opção do START REPLICAT deve ser usada?
19. Em uma replicação entre servidores distintos, qual objeto transporta a trilha local até o Receiver Service remoto?
20. Qual é a sequência correta para executar o Healthcheck oficial da Oracle (OGGHC)?
21. Qual parâmetro agrupa várias transações pequenas em uma maior antes de aplicar no destino, reduzindo commits?
22. Em clusters Oracle RAC, qual ajuste na tabela de checkpoint do Replicat reduz a contenção de Buffer Busy Waits?
23. Qual comando exibe o histórico de latência separando o lag de captura do lag de aplicação?
24. O que é o MCP (Model Context Protocol) no contexto de IA aplicada ao GoldenGate?
25. O Oracle GoldenGate MCP Server oficial (open source) é, segundo a própria Oracle:
Conclusão
Certificado
Certificado bloqueado
Identifique o aluno, conclua os módulos e obtenha pelo menos 80% no quiz.
Consulta rápida
Glossário Técnico
46 termos essenciais do Oracle GoldenGate 26ai. Busque por nome ou clique em um termo para abrir o módulo correspondente.
Service Manager
Processo raiz que gerencia deployments e serviços do OGG Microservices — é o primeiro componente instalado e registrado como daemon do sistema.
Ver no Módulo 02 →Deployment
Instância isolada de configuração e processos do GoldenGate, com seu próprio conjunto de portas, credenciais e diretórios.
Ver no Módulo 02 →Administration Service
Serviço responsável pela configuração de Extracts e Replicats, além de expor a console web e a API REST do deployment.
Ver no Módulo 02 →Distribution Service
Serviço que transporta trilhas (trail files) pela rede até o Receiver Service de um servidor remoto.
Ver no Módulo 07 →Receiver Service
Serviço que recebe a trilha remota enviada pelo Distribution Service de outro servidor.
Ver no Módulo 07 →Performance Metrics Service
Serviço que coleta métricas via StatsD, usado para dashboards de monitoramento em tempo real.
Ver no Módulo 09 →Extract
Processo que captura mudanças (DML/DDL) na origem, lendo o redo log ou log de transações do banco.
Ver no Módulo 06 →Replicat
Processo que aplica as mudanças capturadas pelo Extract no banco de destino.
Ver no Módulo 06 →Trail File
Arquivo binário intermediário que armazena as mudanças capturadas antes de serem transportadas e aplicadas.
Ver no Módulo 06 →Distribution Path
Objeto criado com ADD DISTPATH/ADD PATH que liga a trilha local ao Receiver Service remoto pela rede.
Ver no Módulo 07 →Data Stream
Mecanismo do GoldenGate para integração orientada a eventos com destinos de streaming/mensageria (ex: Kafka, Iceberg).
Ver no Módulo 07 →Credential Store
Cofre de credenciais do OGG que elimina senhas em texto puro dos arquivos de parâmetros.
Ver no Módulo 04 →USERIDALIAS
Parâmetro que referencia um alias do Credential Store dentro do arquivo .prm, em vez de usuário/senha em texto puro.
Ver no Módulo 05 →Supplemental Logging
Registro adicional no redo log, necessário para que o Extract reconstrua a linha completa alterada.
Ver no Módulo 03 →ARCHIVELOG
Modo do Oracle Database que preserva os redo logs já gravados, permitindo leitura posterior pelo Extract em caso de atraso.
Ver no Módulo 03 →OGG_CAPTURE
Role nativa do Oracle AI Database 26ai que autoriza um usuário a atuar como Extract, substituindo o antigo DBMS_GOLDENGATE_AUTH.
Ver no Módulo 03 →OGG_APPLY
Role nativa do Oracle AI Database 26ai que autoriza um usuário a atuar como Replicat no banco de destino.
Ver no Módulo 03 →Integrated Extract
Modo de captura que usa o LogMiner nativo do Oracle para leitura performática do redo.
Ver no Módulo 06 →Parallel Replicat
Modo de aplicação que distribui a carga entre múltiplos processos internos (coordenador + appliers) para maior throughput.
Ver no Módulo 06 →Checkpoint Table
Tabela no banco de destino usada pelo Replicat para controlar seu progresso e permitir recuperação após uma falha.
Ver no Módulo 06 →TRANDATA
Configuração ativada com ADD TRANDATA que liga o log suplementar em nível de tabela ou schema.
Ver no Módulo 06 →DDL Replication
Captura e aplicação de comandos de definição de dados (ALTER, CREATE), além do DML tradicional.
Ver no Módulo 06 →BEQ (Bequeath)
Protocolo de conexão direta ao binário do Oracle, sem passar pelo Listener de rede — usado quando o OGG está no mesmo servidor do banco.
Ver no Módulo 05 →mTLS
Autenticação mútua por certificado entre os serviços Microservices do OGG, garantindo que ambos os lados da comunicação sejam validados.
Ver no Módulo 04 →Root CA
Autoridade certificadora raiz usada para assinar os certificados dos serviços em ambientes com TLS/mTLS habilitado.
Ver no Módulo 04 →WAL (Write-Ahead Log)
Log de transações do PostgreSQL, decodificado logicamente (logical decoding) pelo Extract para captura de mudanças.
Ver no Módulo 04 →REPLICA IDENTITY FULL
Configuração de tabela do PostgreSQL que grava a imagem completa da linha no WAL, exigida para UPDATE/DELETE corretos.
Ver no Módulo 04 →GTID
Identificador global de transação do MySQL, usado pelo Extract para reposicionamento confiável mesmo após um failover.
Ver no Módulo 04 →Binlog
Log binário do MySQL — a fonte de captura de mudanças usada pelo Extract nesse motor de banco.
Ver no Módulo 04 →Initial Load
Carga inicial de dados já existentes, usada para sincronizar origem e destino antes do CDC assumir o fluxo contínuo.
Ver no Módulo 07 →CDC (Change Data Capture)
Captura contínua de mudanças em tempo real, aplicada após a carga inicial ter sincronizado a base.
Ver no Módulo 07 →ATCSN
Opção do START REPLICAT que aplica apenas transações commitadas após um SCN específico, evitando duplicidade na transição carga inicial → CDC.
Ver no Módulo 07 →HANDLECOLLISIONS
Parâmetro do Replicat que evita erro de chave duplicada durante a janela de transição entre carga inicial e CDC online.
Ver no Módulo 07 →Replicação Heterogênea
Replicação entre plataformas de banco diferentes, como Oracle → MySQL ou Oracle → PostgreSQL.
Ver no Módulo 07 →Spread Deployment
Arquitetura com múltiplos Deployments sob o mesmo Service Manager, usada para escalar horizontalmente em vez de sobrecarregar um único Home.
Ver no Módulo 08 →Cache Manager
Componente que gerencia em memória e disco o cache de transações abertas de longa duração do Extract.
Ver no Módulo 11 →Lag
Atraso entre a origem e o destino, medido pelo GoldenGate em segundos — o principal indicador de saúde de uma replicação.
Ver no Módulo 09 →Heartbeat Table
Mecanismo de monitoramento que injeta e mede registros de latência ponta a ponta entre origem e destino.
Ver no Módulo 09 →VIEW REPORT
Comando que exibe o relatório detalhado de execução de um processo — o primeiro lugar a olhar em caso de ABENDED.
Ver no Módulo 09 →OGGHC (Healthcheck)
Conjunto de scripts SQL oficiais da Oracle (ogghc_install/run/deinstall.sql) para diagnóstico completo do ambiente.
Ver no Módulo 10 →GROUPTRANSOPS
Parâmetro que agrupa múltiplas transações pequenas em uma maior antes de aplicar no destino, reduzindo commits.
Ver no Módulo 11 →CHECKPOINTSECS
Parâmetro que controla a frequência de gravação de checkpoints de recuperação do processo.
Ver no Módulo 11 →BATCHSQL
Recurso que agrupa múltiplas instruções SQL em lotes para reduzir round-trips ao banco de destino.
Ver no Módulo 11 →Admin Client
Interface de linha de comando — sucessora do GGSCI clássico — usada para operar o OGG Microservices via API REST.
Ver no Módulo 06 →MCP (Model Context Protocol)
Padrão aberto que permite que assistentes e agentes de IA descubram e usem ferramentas (tools) para operar sistemas como o GoldenGate.
Ver em IA & MCP →AI Microservice
Novo serviço do GoldenGate 26ai que permite gerar embeddings e conectar a provedores de LLM como Gemini, OpenAI e OCI Generative AI.
Ver em IA & MCP →Central de Links
Recursos Oficiais
Documentação, tutoriais e materiais oficiais da Oracle, organizados por assunto — tudo alinhado ao conteúdo desta formação.
📘 Documentação Principal
- Oracle GoldenGate 26ai — Get StartedPortal oficial de documentação da versão 26ai
- Microservices Architecture DocumentationGuia completo da arquitetura usada neste curso
- Command Line Interface ReferenceReferência completa de comandos do Admin Client
- Release Notes 26aiNovidades, deprecações e mudanças da versão
🔌 API e Integração
🎓 Tutoriais e Certificação
📰 Blog e Novidades
🤖 IA, MCP e Automação
Kit de operação
Scripts de Monitoramento e Diagnóstico
Scripts prontos, comentados e baseados nos comandos ensinados nesta formação. Baixe, adapte os parâmetros de conexão e use em seus próprios crons e pipelines de monitoramento.
💡 Estes scripts são templates funcionais, prontos para adaptar e usar em produção — os comandos e a lógica já são reais. Antes do primeiro uso no seu ambiente, ajuste credenciais (idealmente via cofre de senhas), caminhos (OGG_VAR_HOME, deployment) e confirme com o time de segurança as políticas de rede/e-mail da empresa. Use o botão "Simular execução" para ver um exemplo de saída no terminal antes mesmo de baixar.
📡 Monitoramento
Verificação contínua de saúde dos processos, lag e infraestrutura.
check_lag.sh — Bash + Admin Client
Verifica o LAG de todos os Extracts e Replicats e alerta quando o atraso ultrapassa o limite configurado. Ideal para rodar a cada poucos minutos via cron.
#!/bin/bash
# ============================================================================
# check_lag.sh — Verifica o LAG de todos os Extracts e Replicats via
# Admin Client, alertando quando o atraso ultrapassa o limite definido.
#
# Uso: ./check_lag.sh <deployment_url> <deployment_name> <usuario> <limite_segundos>
# Exemplo: ./check_lag.sh http://192.168.56.110:9001 oracle_deploy srv_manager 300
#
# Requisitos: Admin Client (adminclient) no PATH, acesso ao deployment.
# ============================================================================
set -euo pipefail
DEPLOY_URL="${1:?Informe a URL do deployment}"
DEPLOY_NAME="${2:?Informe o nome do deployment}"
ADMIN_USER="${3:?Informe o usu...find_stopped_processes.sh — Bash + Admin Client
Retorna código de saída diferente de zero se algum processo estiver STOPPED ou ABENDED — pronto para integrar com Zabbix, Prometheus ou qualquer sistema de alertas.
#!/bin/bash
# ============================================================================
# find_stopped_processes.sh — Consulta rapidamente processos que não estão
# RUNNING (STOPPED ou ABENDED), ideal para integração com cron/Zabbix/
# Prometheus. Retorna código de saída != 0 se encontrar algum problema,
# facilitando o uso em pipelines de monitoramento.
#
# Uso: ./find_stopped_processes.sh <deployment_url> <deployment_name> <usuario>
# ============================================================================
set -euo pipefail
DEPLOY_URL="${1:?Informe a URL do deployment}"
DEPLOY_NAME="${2:?Informe o nome do deployment}"
ADMIN_USER="${3:?Informe o usuário administrativo}"
OUTPUT=$(ad...check_disk_space.sh — Bash
Verifica o espaço livre em OGG_VAR_HOME e no diretório de trail files — a causa mais comum e mais simples de paradas inesperadas do GoldenGate.
#!/bin/bash
# ============================================================================
# check_disk_space.sh — Verifica o espaço livre nos filesystems críticos do
# GoldenGate (OGG_VAR_HOME e diretório de trail files), alertando abaixo
# do limite configurado. Causa mais comum e mais simples de paradas
# inesperadas de Extract/Replicat.
#
# Uso: ./check_disk_space.sh [limite_percentual_alerta]
# Exemplo: ./check_disk_space.sh 85
# ============================================================================
set -euo pipefail
THRESHOLD="${1:-85}"
PATHS_TO_CHECK=("${OGG_VAR_HOME:-/u02/ogg/var}" "${OGG_ETC_HOME:-/u02/ogg/etc}")
echo "== Verificação de espaço em disco (alerta acima de ${THR...heartbeat_report.sql — SQL*Plus
Consulta as 50 medições mais recentes de latência ponta a ponta registradas pelas Heartbeat Tables, separando lag de captura e de aplicação.
-- ============================================================================ -- heartbeat_report.sql — Consulta o histórico de latência ponta a ponta -- registrado pelas Heartbeat Tables do GoldenGate, separando o lag de -- captura (origem) do lag de aplicação (destino). Execute conectado ao -- schema administrador do GoldenGate (ex: ggadmin). -- -- Pré-requisito: ADD HEARTBEATTABLE já configurado (ver Módulo 09). -- ============================================================================ SET LINESIZE 200 SET PAGESIZE 50 COLUMN source_db FORMAT A15 COLUMN target_db FORMAT A15 COLUMN incoming_lag FORMAT A14 COLUMN outgoing_lag FORMAT A14 COLUMN last_updated F...
📊 Relatórios
Consolidam múltiplas fontes de dados em um único documento para revisão ou arquivamento.
daily_health_summary.sh — Bash + Admin Client
Resumo diário consolidado (serviço systemd + disco + status de processos), pensado para rodar via cron no início do expediente.
#!/bin/bash
# ============================================================================
# daily_health_summary.sh — Gera um resumo diário consolidado (status de
# processos + espaço em disco + serviço systemd), útil para rodar via cron
# no início do dia e revisar rapidamente a saúde do ambiente.
#
# Uso: ./daily_health_summary.sh <deployment_url> <deployment_name> <usuario>
# Sugestão de crontab: 0 7 * * * /caminho/daily_health_summary.sh ... >> /var/log/ogg_daily.log 2>&1
# ============================================================================
set -euo pipefail
DEPLOY_URL="${1:?Informe a URL do deployment}"
DEPLOY_NAME="${2:?Informe o nome do deployment}"
ADMIN_USER="${3:?Informe...generate_html_report.sh — Bash + Admin Client
Gera um relatório HTML navegável e pronto para anexar em e-mail ou publicar em um servidor web interno, com status de processos, disco e serviço.
#!/bin/bash
# ============================================================================
# generate_html_report.sh — Gera um relatório HTML consolidado do ambiente
# (processos, lag, disco e serviço) pronto para anexar em e-mail ou publicar
# em um servidor web interno. Reaproveita as mesmas fontes de dados do
# daily_health_summary.sh, mas em formato navegável.
#
# Uso: ./generate_html_report.sh <deployment_url> <deployment_name> <usuario> [saida.html]
# ============================================================================
set -euo pipefail
DEPLOY_URL="${1:?Informe a URL do deployment}"
DEPLOY_NAME="${2:?Informe o nome do deployment}"
ADMIN_USER="${3:?Informe o usuário administrat...weekly_growth_report.sql — SQL*Plus
Analisa o crescimento das tabelas de checkpoint/heartbeat e o volume de medições da última semana — útil para relatórios de capacidade.
-- ============================================================================
-- weekly_growth_report.sql — Analisa o crescimento da tabela de checkpoint
-- e o volume de mudanças processadas na última semana, útil para relatórios
-- de capacidade e para justificar upgrades de infraestrutura.
--
-- Execute conectado ao schema administrador do GoldenGate (ex: ggadmin).
-- ============================================================================
SET LINESIZE 200
SET PAGESIZE 50
COLUMN table_name FORMAT A28
COLUMN size_mb FORMAT 999,999.99
COLUMN num_rows FORMAT 999,999,999
PROMPT === Tamanho das tabelas de checkpoint e heartbeat ===
SELECT
segment_name AS table_na...🔔 Notificação
Avisam a equipe automaticamente quando algo precisa de atenção, sem exigir que alguém fique olhando um dashboard.
send_email_alert.sh — Bash + mail/mailx
Envia um e-mail de alerta quando processos com problema (STOPPED/ABENDED) são encontrados. Requer um MTA local configurado (Postfix, sSMTP).
#!/bin/bash
# ============================================================================
# send_email_alert.sh — Envia um e-mail de alerta quando processos com
# problema (STOPPED/ABENDED) são encontrados. Usa o comando `mail`/`mailx`
# padrão do sistema operacional (configure um MTA local como Postfix/
# sSMTP antes de usar em produção).
#
# Uso: ./send_email_alert.sh <deployment_url> <deployment_name> <usuario> <destinatario@empresa.com>
# Sugestão de crontab: */10 * * * * /caminho/send_email_alert.sh ... 2>&1
# ============================================================================
set -euo pipefail
DEPLOY_URL="${1:?Informe a URL do deployment}"
DEPLOY_NAME="${2:?Informe o nome do...notify_webhook.sh — Bash + curl
Envia uma notificação JSON para um webhook genérico (Slack, Microsoft Teams, Discord) quando processos com problema são encontrados — mais rápido que e-mail para equipes plantonistas.
#!/bin/bash
# ============================================================================
# notify_webhook.sh — Envia uma notificação para um webhook genérico
# (Slack, Microsoft Teams, Discord ou qualquer endpoint que aceite JSON)
# quando processos com problema são encontrados. Mais rápido que e-mail
# para equipes que monitoram um canal de operações em tempo real.
#
# Uso: ./notify_webhook.sh <deployment_url> <deployment_name> <usuario> <webhook_url>
# Exemplo Slack: https://hooks.slack.com/services/XXX/YYY/ZZZ
# ============================================================================
set -euo pipefail
DEPLOY_URL="${1:?Informe a URL do deployment}"
DEPLOY_NAME="${2:?Informe o nome d...🗄️ Backup e Housekeeping
Preserva o histórico de configuração e evita acúmulo de arquivos antigos.
backup_parameter_files.sh — Bash
Faz backup versionado (com timestamp) dos arquivos .prm antes de mudanças planejadas, mantendo automaticamente apenas os 30 backups mais recentes.
#!/bin/bash
# ============================================================================
# backup_parameter_files.sh — Faz backup versionado (com timestamp) dos
# arquivos de parâmetros (.prm) e credenciais de referência antes de uma
# mudança planejada — prática essencial de controle de mudanças.
#
# Uso: ./backup_parameter_files.sh [diretorio_origem] [diretorio_destino]
# Sugestão de crontab: 0 2 * * * /caminho/backup_parameter_files.sh
# ============================================================================
set -euo pipefail
SRC_DIR="${1:-${OGG_ETC_HOME:-/u02/ogg/etc}}"
DEST_DIR="${2:-/u02/ogg/backups}"
STAMP=$(date +%Y%m%d_%H%M%S)
TARGET="${DEST_DIR}/params_${STAMP}"
mkdir -p "...Além do curso tradicional
IA & MCP no Oracle GoldenGate
Como assistentes e agentes de IA (Claude, ChatGPT, Gemini) podem operar seu ambiente GoldenGate — com base no material oficial da Oracle.
🤖 O que é o Model Context Protocol (MCP)?
MCP é um padrão aberto (criado pela Anthropic e adotado amplamente pela indústria, incluindo a Oracle) que permite que assistentes de IA como o Claude e agentes autônomos descubram e usem ferramentas (tools) de sistemas externos de forma controlada — em vez de fazer chamadas de API ad-hoc, o assistente conecta-se a um MCP Server que expõe uma lista de ferramentas disponíveis, e o cliente de IA escolhe e invoca a ferramenta certa para responder à pergunta ou executar a tarefa.
Em maio de 2026, a Oracle publicou oficialmente um MCP Server open-source para o GoldenGate, que expõe operações do Microservices (status de processos, lag, criação de Extract/Replicat, e mais) como ferramentas que um assistente de IA pode usar diretamente, via API REST do GoldenGate.
⚠ Importante: o servidor é real, open-source e funcional — qualquer pessoa pode instalá-lo e usá-lo hoje. O que a própria Oracle destaca é que ele ainda não passou pelo processo formal de certificação/suporte (como acontece com o GoldenGate em si), ou seja: se algo falhar, não há uma linha de suporte oficial da Oracle para acionar. Na prática, isso pede o mesmo cuidado que qualquer ferramenta open-source traz para dentro do ambiente corporativo: comece em ambiente não produtivo, use credenciais de privilégio mínimo, e só amplie o uso depois de validar o comportamento no seu contexto.
Como o MCP Server conecta um assistente de IA ao GoldenGate
Diagrama ilustrativo desta formação, com base na arquitetura descrita no blog oficial da Oracle (maio/2026) — ver fonte ao final da página.
Fluxo simplificado: o cliente MCP (assistente/agente) envia um pedido → o MCP Server expõe as ferramentas do GoldenGate → o servidor invoca a API REST oficial usando as credenciais configuradas → a resposta retorna resumida em linguagem natural para quem perguntou.
Por que isso importa para quem administra GoldenGate
O modelo tradicional de operação depende de trocar entre console web, API REST, scripts e runbooks.
Com um MCP Server conectado, um assistente de IA pode responder perguntas operacionais ad-hoc ("quais processos estão parados?", "qual o lag do Replicat de vendas?"), e um agente de IA pode executar fluxos completos de múltiplos passos — validar uma conexão, checar o lag, e até remediar um problema — sempre através das APIs oficiais do GoldenGate, preservando controle e auditoria. Em cenários multi-sistema, um agente pode combinar o MCP Server do GoldenGate com o MCP Server do banco de dados e o da OCI para operações ponta a ponta.
Ferramentas (tools) disponíveis no servidor oficial
Organizadas pelas mesmas categorias operacionais ensinadas nesta formação.
Descoberta
list_domains / list_connections
list_extracts / list_replicats
list_distribution_paths
list_data_streams / list_trails
list_checkpoint_tables
Captura e Replicação
create_extract / update_extract
create_replicat / update_replicat
create_distribution_path
create_data_stream
Conectividade
create_connection
add_trandata_schema
add_trandata_table
Runtime e Monitoramento
start / stop
get_extract_status / get_replicat_status
get_extract_lag / get_replicat_lag
get_extract_report / get_replicat_report
get_extract_stats / get_replicat_stats
Exemplos de prompts (uso real)
É assim que um administrador interage com o ambiente através de um assistente de IA conectado ao MCP Server.
"Liste todos os Extracts e Replicats deste deployment e me diga quais não estão RUNNING."
"Verifique o lag de todos os Replicats. Se algum estiver acima de 5 minutos, me explique o motivo mais provável com base no relatório."
"Crie um Extract para o schema VENDAS, valide a conexão de origem e resuma a configuração antes de eu confirmar."
"Pegue o relatório do Extract EX_CDC e resuma os erros mais recentes em português."
Como instalar (visão geral)
Passos oficiais do repositório, adaptados como referência rápida.
git clone https://github.com/oracle/mcp.git
cd mcp/src/oracle-goldengate-mcp-serverEm seguida, siga o README.md do repositório para configurar o ambiente Python e copiar o arquivo oracle-goldengate-mcp-server.env.example para .env, preenchendo host, porta e credenciais do seu deployment GoldenGate. Depois, registre o servidor no seu cliente MCP (Claude Desktop, Cursor, Cline, Codex) usando transporte stdio e um script de inicialização que ativa o ambiente Python e carrega as variáveis de ambiente.
Boas práticas de segurança recomendadas pela Oracle
- Use ambientes não produtivos para testes iniciais.
- Aplique acesso de privilégio mínimo nas credenciais usadas pelo servidor MCP.
- Nunca incorpore senhas em arquivos de configuração compartilhados — prefira OCI Vault ou arquivos de senha seguros.
- Restrinja o acesso de rede ao servidor MCP.
- Revise as ações antes da execução, especialmente em fluxos agênticos autônomos.
- Habilite logging para garantir auditabilidade de tudo que o assistente/agente executar.