# Oracle GoldenGate vs Debezium

Uma atualização em uma tabela Oracle pode precisar chegar a outro banco, alimentar um Data Lakehouse ou ser consumida por dezenas de serviços. Consultar a origem a cada minuto ou executar cargas completas resolve parte do problema, mas adiciona atraso, leituras e dificuldades para detectar exclusões. É nesse contexto que entra o **Change Data Capture (CDC)**.

**Oracle GoldenGate e Debezium capturam mudanças, mas não oferecem exatamente a mesma solução.** Compará-los somente pelo preço ou pela velocidade da captura leva a decisões equivocadas. O que importa é o fluxo completo: captura, transporte, entrega, aplicação, recuperação e sustentação.

## O que é CDC e quais problemas ele resolve?

CDC identifica alterações realizadas nos dados e permite propagá-las incrementalmente. No modelo baseado em logs, os registros transacionais do banco são utilizados para identificar operações como `INSERT`, `UPDATE` e `DELETE`, reduzindo a necessidade de varrer tabelas repetidamente.

Isso ajuda a diminuir o intervalo entre a transação na origem e sua disponibilidade em outros sistemas. Mas **CDC não é sinônimo de replicação pronta, nem substitui carga inicial, observabilidade ou tratamento de falhas**. Uma arquitetura pode capturar corretamente todas as mudanças e ainda assim falhar ao aplicá-las no destino.

## Oracle GoldenGate: da captura à replicação transacional

O **Oracle GoldenGate** é uma plataforma de integração e replicação de dados. Na arquitetura clássica, o **Extract** captura alterações, os **Trail Files** persistem os registros intermediários e o **Replicat** aplica as operações no destino. Um Data Pump Extract pode transportar trails entre ambientes. Na arquitetura Microservices, serviços de distribuição, recepção e administração alteram o modo de operação, sem eliminar a lógica de captura, transporte e aplicação.

Seu diferencial não é simplesmente ler redo logs, mas oferecer uma cadeia de replicação com checkpoints, mecanismos de recuperação e opções de aplicação transacional, conforme produto e topologia.

**Vantagens:** aderência a migrações com baixa indisponibilidade, replicação Oracle–Oracle, integração heterogênea suportada e operação empresarial de fluxos transacionais.

**Limitações e custos:** licenciamento comercial, complexidade de topologias, necessidade de conhecimento especializado e cuidados com DDL, chaves, transformações e conflitos em arquiteturas bidirecionais. Não basta ativar o Extract para garantir consistência em qualquer destino.

## O que é Debezium e como funciona com Oracle?

O **Debezium** é uma plataforma open source baseada em conectores CDC. Seu cenário mais difundido utiliza **Kafka Connect** para publicar eventos em tópicos Kafka, permitindo que diversos consumidores processem as mesmas alterações. Também há modelos como Debezium Server e Embedded Engine: Kafka não é uma dependência universal da ferramenta.

No Oracle, o conector pode utilizar **LogMiner**, **XStream** ou **OpenLogReplicator**. O LogMiner é a opção padrão; exige preparação da origem, incluindo ARCHIVELOG, supplemental logging e privilégios adequados. Snapshots ajudam a obter o estado inicial, enquanto offsets e histórico de schema permitem continuar a captura e interpretar alterações.

Arquitetura típica:

`Oracle (redo/archive logs) → Debezium / Kafka Connect → Kafka → consumidores`

Imagine a execução:

```sql
UPDATE CLIENTES SET STATUS = 'ATIVO' WHERE ID = 100;
COMMIT;
```

Um evento simplificado, **ilustrativo e não um payload integral**, poderia ter a seguinte estrutura:

```json
{
  "op": "u",
  "before": {"ID": 100, "STATUS": "PENDENTE"},
  "after":  {"ID": 100, "STATUS": "ATIVO"},
  "source": {"db": "ORCL", "table": "CLIENTES"}
}
```

O campo `op: "u"` indica atualização; os estados `before` e `after` dependem das informações disponíveis e da configuração de logging. O evento real também pode conter SCN, identificadores de transação e timestamps, entre outros metadados.

**Vantagens:** integração natural com streaming, múltiplos consumidores, arquitetura desacoplada e código aberto.

**Limitações:** o Debezium **não aplica sozinho transações em outro Oracle**. Para materializar dados no destino, são necessários sinks ou consumidores, com tratamento de falhas, duplicidade, ordem, schema e idempotência. Essa responsabilidade não desaparece porque a captura foi bem-sucedida.

## Comparativo técnico

| Critério | GoldenGate | Debezium |
|---|---|---|
| Foco | Replicação e integração transacional | Captura e publicação de eventos |
| Captura Oracle | Componentes de captura GoldenGate | LogMiner, XStream ou OpenLogReplicator |
| Aplicação Oracle–Oracle | Replicat nativo | Exige consumidor ou sink adicional |
| Carga inicial | Estratégias de initial load/sincronização | Snapshots configuráveis |
| Integração Kafka | Possível via componentes/adaptadores | Caso de uso central com Kafka Connect |
| Recuperação | Checkpoints e trails | Offsets, histórico de schema e logs disponíveis |
| Licença | Comercial, com oferta Free limitada | Open source; XStream pode exigir licença Oracle |
| Maior atenção | Topologia, lag, aplicação e conflitos | Mineração, buffers, eventos e consumidores |

### Como avaliar latência, consistência e recuperação no CDC?

Não há base para afirmar que uma tecnologia é sempre mais rápida. A latência precisa ser separada em **captura, transporte e aplicação/consumo**. Um evento chegar ao Kafka não significa que já foi processado no sistema de destino. Do mesmo modo, lag baixo no Extract não comprova que o Replicat terminou de aplicar as alterações.

Na retomada após falhas, pode haver reentrega. Em configurações com semântica **at-least-once**, um mesmo evento pode ser entregue mais de uma vez, por exemplo, quando ocorre falha entre o processamento e a confirmação do offset. Consumidores idempotentes, controle de offsets e tratamento de transações são necessários para evitar efeitos duplicados. Algumas configurações e componentes oferecem garantias mais fortes, inclusive **exactly-once** em escopos específicos, mas essas garantias **não se estendem automaticamente ao pipeline de ponta a ponta**. É preciso validar separadamente captura, transporte, processamento e aplicação no destino.

Também é necessário preservar ordem quando ela importa. Kafka mantém ordem dentro de uma partição, não entre todas as partições de um tópico; a escolha de chaves de particionamento e a estratégia de consumo fazem parte do projeto.

### Debezium com Oracle: detalhes que mudam a operação

No LogMiner padrão, alterações de transações ainda não confirmadas precisam ser mantidas em buffer até `COMMIT` ou `ROLLBACK`. Transações extensas e concorrência elevada podem pressionar a memória do conector. Há um modo alternativo de processamento de mudanças confirmadas que reduz esse buffer no conector, mas transfere trabalho e consumo de PGA para o Oracle. Não é uma otimização gratuita.

O histórico de schema também importa. A estratégia `online_catalog` utiliza o dicionário atual do banco e tem limitações quando DDL e DML se sobrepõem. A estratégia `hybrid` busca melhorar a reconstrução de alterações, **mas não pode ser utilizada com `lob.enabled=true`**. Portanto, se o requisito inclui captura de valores LOB, como `CLOB`, `NCLOB` e `BLOB`, é necessário avaliar uma estratégia compatível, como `online_catalog` ou `redo_log_catalog`, considerando as restrições de cada versão. A estratégia `redo_log_catalog` aumenta o volume de redo e está marcada como *deprecated* na documentação atual. A escolha precisa ser validada também para outros tipos complexos e para o comportamento de DDL.

Outro risco é a **retenção de archive logs**: se a captura parar e os logs necessários forem removidos, offsets preservados não são suficientes para retomar o processamento. Pode ser necessário um novo snapshot ou procedimento de recuperação. Isso exige alinhar FRA, política de backup, retenção e janelas de indisponibilidade.

O adaptador **XStream** usa tecnologia Oracle sujeita a direitos de licenciamento específicos. Já o **OpenLogReplicator** introduz um componente externo de leitura de redo, que precisa ser instalado, monitorado e mantido. A escolha deve considerar suporte, compatibilidade e impacto operacional, não apenas o desempenho potencial.

## Debezium é gratuito? Quanto custa o GoldenGate?

O **GoldenGate comercial** tem licenciamento condicionado à edição, à métrica e aos componentes contratados. Recursos, conectores e direitos de uso precisam ser verificados nos documentos de licenciamento e no contrato da organização.

O **GoldenGate Free** não é uma versão comercial sem custo e sem restrições: é limitado a bancos Oracle de até **20 GB** (em CDB, considerando o total das PDBs), possui suporte comunitário, não oferece direitos de ADG/XStream ou downstream capture e não pode ser integrado livremente com instâncias GoldenGate licenciadas ou ferramentas terceiras.

O **Debezium é open source**, mas não equivale a custo operacional zero. Kafka Connect, brokers quando usados, retenção de eventos, observabilidade, upgrades, segurança, disponibilidade e suporte precisam entrar na conta. Se a opção de captura for XStream, também há implicações de licença Oracle.

A comparação correta é de **TCO (custo total de propriedade)**: licença, infraestrutura, competências, operação, recuperação e risco de indisponibilidade.

## Quando escolher GoldenGate ou Debezium?

### Cenário A — Migração Oracle com baixa indisponibilidade

Uma instituição financeira precisa migrar sua base Oracle para outra infraestrutura mantendo alterações sincronizadas até o cutover. Aqui, o desafio é garantir consistência, aplicar transações, monitorar defasagem e estabelecer um ponto de corte controlado.

**GoldenGate tende a ser a escolha mais direta**, pois já oferece componentes de captura e aplicação de replicação. Ainda assim, é preciso planejar carga inicial, reconciliação, compatibilidade de versões, tratamento de DDL e estratégia de rollback.

### Cenário B — Oracle alimentando microsserviços e analytics

A mesma instituição deseja disponibilizar alterações cadastrais a serviços independentes, mecanismos antifraude e pipelines analíticos. O requisito agora é distribuir eventos a consumidores com ciclos de evolução distintos.

**Debezium pode ser especialmente adequado**, sobretudo se Kafka e Kafka Connect já fazem parte da plataforma. A equipe deve projetar contratos de eventos, particionamento, DLQ/reprocessamento quando aplicável, controle de acesso e idempotência nos consumidores.

É possível combinar as tecnologias: GoldenGate para replicação transacional e Debezium para eventos. Isso, porém, aumenta a necessidade de governança para evitar captura redundante e fluxos divergentes.

## Critérios de escolha para produção

Antes de decidir, responda:

1. O objetivo é **replicar dados entre bancos** ou **distribuir eventos para aplicações**?
2. Quais são os requisitos de latência, RPO, recuperação e consistência?
3. Há DDL frequente, LOBs, transações longas ou necessidade de preservar ordem?
4. Quem sustentará logs, checkpoints/offsets, schemas, monitoramento e reprocessamento?
5. Qual é o TCO, incluindo licenças, infraestrutura e suporte?

## Conclusão

**GoldenGate e Debezium não são concorrentes perfeitos.** Ambos podem fazer CDC, mas o GoldenGate entrega uma plataforma orientada à replicação e à aplicação transacional, enquanto o Debezium se destaca na disponibilização de mudanças como eventos.

Se a prioridade é sincronizar bancos com mecanismos especializados de aplicação, GoldenGate tende a ser a alternativa natural. Se o objetivo é desacoplar sistemas e distribuir alterações para diversos consumidores, Debezium merece uma avaliação séria. A decisão correta nasce dos requisitos de negócio, da arquitetura de destino e da capacidade de sustentar o fluxo em produção — não apenas do preço da licença.

---

### Referências oficiais

- [Debezium — Oracle Connector](https://debezium.io/documentation/reference/connectors/oracle.html)
- [Debezium — Documentação](https://debezium.io/documentation/)
- [Oracle — GoldenGate Free: FAQ e limitações](https://docs.oracle.com/en/middleware/goldengate/free/21/uggfe/frequently-asked-questions.html)
- [Oracle — GoldenGate](https://www.oracle.com/integration/goldengate/)

*Nota: funcionalidades, suporte, versões e condições de licenciamento podem mudar. Consulte a documentação e os contratos específicos antes de implementar.*