Oracle tem três tecnologias principais de DR e replicação: Data Guard, Active Data Guard e GoldenGate. Cada uma serve a um perfil diferente de RTO, RPO, custo e complexidade. Escolher a errada significa pagar a mais ou descobrir as limitações no pior momento.
Por que DR de Oracle Database é diferente
Imagine que o datacenter principal cai às 2h da manhã. Você precisa que o ERP esteja acessível em quanto tempo? Esse número — o RTO — define qual tecnologia de DR faz sentido e quanto você vai pagar.
Oracle Database, diferente de sistemas de arquivos ou VMs, tem consistência transacional complexa. Um failover de banco Oracle não é só ligar outro servidor — envolve garantir que o banco standby está sincronizado, que as transações em curso foram corretamente finalizadas ou revertidas, e que as aplicações conseguem reconectar no novo endpoint.
As três tecnologias da Oracle para isso têm características muito diferentes.
Oracle Data Guard: o DR padrão Oracle
Data Guard cria um banco standby sincronizado com o banco primário via redo logs. Qualquer transação confirmada no primário é replicada para o standby em tempo real (ou quasi-real, dependendo do modo de proteção).
Standby físico: réplica exata do banco primário, byte a byte. O standby aplica redo logs continuamente e fica em estado de recuperação (RECOVER mode). Não pode ser aberto para leitura em modo write. Em caso de failover, o standby se torna o novo primário em segundos a minutos.
Standby lógico: replica transações como SQL no standby. Permite que o standby seja aberto para consultas em tabelas replicadas. Mais complexo de manter, com limitações de tipos de objetos suportados. Menos comum em novas implementações.
Modos de proteção:
- Maximum Protection: sem perda de dados garantida (RPO = 0). Toda transação do primário espera confirmação de pelo menos um standby. Se o standby cair, o primário para — zero transações perdidas, mas disponibilidade reduzida.
- Maximum Availability: RPO próximo de zero. Funciona como Maximum Protection quando o standby está disponível, mas o primário continua operando sozinho se o standby cair.
- Maximum Performance: padrão. O primário não espera confirmação do standby — melhor performance, alguma potencial perda de transações em caso de falha simultânea do primário e do standby antes de sincronia.
Switchover vs Failover:
- Switchover: operação planejada, ambos os bancos cooperam, sem perda de dados. Usado para manutenção ou migração planejada.
- Failover: o primário está indisponível, o standby assume. Pode ter mínima perda de dados em Maximum Performance mode.
Active Data Guard: standby aberto para leitura
Active Data Guard (ADG) é uma extensão do Data Guard que permite abrir o banco standby físico para consultas de leitura enquanto ainda aplica redo logs. É uma licença adicional (parte do Oracle Database Enterprise Edition + ADG option).
Casos de uso do Active Data Guard:
- Descarregar queries de relatório e analytics do banco primário para o standby — sem impacto no primário
- Banco de standby acessível para desenvolvimento ou QA enquanto produção está no primário
- Distribuição geográfica de carga de leitura (primário no Brasil, standby regional para usuários distantes)
Em termos de DR, o ADG adiciona valor por manter o standby “exercitado” continuamente — banco que recebe queries de leitura o tempo todo está mais testado do que um standby frio que nunca foi acessado.
GoldenGate: replicação bidirecional e heterogênea
GoldenGate é uma solução de replicação de banco de dados separada, com licença própria, que vai além do que Data Guard faz.
O que GoldenGate entrega a mais:
- Replicação bidirecional (active-active): ambos os bancos podem receber escritas simultaneamente — com resolução de conflitos
- Replicação heterogênea: Oracle para PostgreSQL, Oracle para MySQL, Oracle para Kafka — replicação entre bancos de diferentes fabricantes
- Transformação de dados durante replicação — filtrar tabelas, mapear colunas, transformar tipos
- Latência de replicação muito baixa — sub-segundo em configurações otimizadas
Quando GoldenGate é necessário vs Data Guard:
- Active-active (dois datacenters recebendo escritas): GoldenGate. Data Guard não suporta este modelo.
- Migração zero-downtime para novo banco ou nova versão Oracle: GoldenGate para sincronizar enquanto a migração acontece, depois switchover.
- Replicação para sistema não-Oracle (PostgreSQL, MySQL, Kafka): GoldenGate.
- DR simples com standby Oracle: Data Guard é mais simples, mais barato e suficiente.
RPO e RTO de cada opção
| Tecnologia | RPO típico | RTO típico | Complexidade | Custo |
|---|---|---|---|---|
| Data Guard (Max Protection) | 0 | Minutos | Média | Incluso no DB EE |
| Data Guard (Max Performance) | Segundos a minutos | Minutos | Média | Incluso no DB EE |
| Active Data Guard | 0 a segundos | Minutos | Média-alta | DB EE + licença ADG |
| GoldenGate (active-active) | ~0 | Segundos | Alta | Licença separada cara |
| GoldenGate (unidirecional) | Segundos | Minutos | Alta | Licença separada cara |
| Backup + restore (RMAN) | Horas | Horas | Baixa | Incluso no DB |
Backup+restore como DR: funciona, mas com RPO de horas (desde o último backup) e RTO de horas (tempo de restauração). Aceitável para ambientes não críticos ou como camada de DR adicional, não como única estratégia.
Quando cloud DR faz sentido para Oracle
Manter um datacenter secundário fisicamente é caro — espaço, energia, hardware, equipe. Cloud como destino de DR elimina esse custo de standby físico.
Data Guard com standby em OCI: Oracle suporta e documenta Data Guard entre on-premises e OCI. O standby fica em OCI e é ativado apenas em caso de failover — custo muito menor do que manter datacenter secundário. Para o failover funcionar, as aplicações precisam redirecionar conexão para o endpoint OCI.
Data Guard com standby em cloud privada brasileira: alternativa ao OCI que mantém o dado no Brasil, em BRL, com latência previsível. Ideal para empresas que precisam de DR nacional sem migrar para cloud pública.
RTO de cloud DR: depende da conectividade entre os ambientes. Com link dedicado ou VPN de baixa latência entre on-premises e o site de DR, o failover é tão rápido quanto DR físico. Com link de internet, há riscos de latência variável que podem impactar o tempo de sincronização.
Como escolher a tecnologia certa
A decisão entre Data Guard, ADG e GoldenGate simplifica em três perguntas:
- Você precisa de active-active (dois primários simultâneos)? → GoldenGate.
- Você quer usar o standby para leitura enquanto é standby? → Active Data Guard.
- Você precisa de standby Oracle confiável para failover em caso de desastre? → Data Guard padrão.
Para a maioria das empresas brasileiras, Data Guard em modo Maximum Availability — com standby em segunda localização física ou em cloud — resolve o requisito de DR com o menor custo e complexidade.
DR para Oracle Database exige planejamento de RTO/RPO antes de escolher a tecnologia. A Adentro pode hospedar o site de DR para Oracle Database em cloud privada com datacenters Tier III em Osasco, Vinhedo e Porto Alegre, com conectividade de alta qualidade e faturamento em BRL.