A Diretoria de Tecnologia de um órgão público precisa revisar sua estratégia de alta disponibilidade para o banco de dados que sustenta os processos digitais. O requisito é tolerância a falhas tanto de hardware no datacenter principal quanto a desastres geográficos. A solução deve garantir que, em caso de falha no servidor primário, o serviço continue ativo e que haja uma réplica em um site secundário sem perda de transações (Zero Data Loss), mantendo a integridade síncrona dos dados, incrementando a resiliência do ambiente e implementando arquitetura técnica para integrar as soluções de cluster e replicação. Para atender esse objetivo, é fundamental
Autilizar o Oracle GoldenGate para o espelhamento síncrono das bases de dados no cluster local e configurar o Oracle RAC estendido para a replicação geográfica das tabelas.
Bimplementar o Oracle RAC para alta disponibilidade local das instâncias e configurar o espelhamento via Storage Replication em modo assíncrono para o site de contingência remota.
Cconfigurar o Oracle RAC para redundância de instâncias no site primário e o Oracle Data Guard com transporte síncrono (Fast-Sync) para uma base Standby em site secundário.
Dadotar o Oracle Data Guard em modo Maximum Performance para replicação síncrona entre os nós do cluster, utilizando o espelhamento de base de dados via ferramentas de SO.
Eestabelecer uma solução de Cold Cluster para failover automático das instâncias locais e utilizar a replicação assíncrona baseada em tabelas para o banco de dados de desastre.
Revelar gabarito e comentário▾
GabaritoC — configurar o Oracle RAC para redundância de instâncias no site primário e o Oracle Data Guard com transporte síncrono (Fast-Sync) para uma base Standby em site secundário.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Alta disponibilidade em Oracle: RAC + Data Guard
Gabarito: letra C. Para atender tolerância a falhas de hardware no datacenter principal e a desastres geográficos com Zero Data Loss e integridade síncrona, a solução correta combina o Oracle RAC (Real Application Clusters) para redundância de instâncias no site primário e o Oracle Data Guard com transporte síncrono (modo Maximum Protection ou Fast-Sync) para uma base Standby em site secundário. Essa é a arquitetura clássica que separa a alta disponibilidade local (RAC) da recuperação de desastres (Data Guard).
O Oracle RAC é uma solução de cluster que permite que múltiplas instâncias Oracle acessem um mesmo banco de dados compartilhado, garantindo alta disponibilidade e escalabilidade dentro de um mesmo datacenter. Se uma instância falhar, as demais continuam atendendo as requisições, sem interrupção do serviço. Já o Oracle Data Guard é a solução da Oracle para replicação e recuperação de desastres: mantém uma cópia física (Standby) do banco de dados primário em um site remoto, aplicando os redo logs recebidos. Para garantir Zero Data Loss, o transporte dos redo logs deve ser síncrono, ou seja, a transação só é confirmada no primário quando o redo foi recebido pelo standby. O modo Maximum Protection exige esse comportamento, enquanto o modo Maximum Availability (Fast-Sync) permite um pequeno atraso em caso de falha de comunicação, mas ainda assim é considerado síncrono na prática.
A distinção fundamental é: RAC resolve falha de instância (hardware/software no mesmo site), Data Guard resolve falha de site (desastre geográfico). Eles são complementares, não concorrentes. A banca explora exatamente essa confusão, misturando as funções de cada tecnologia. Vamos analisar cada alternativa.
NÃO CAIA NESSA!
A banca adora inverter os papéis: colocar o RAC como solução de replicação geográfica e o Data Guard como solução de cluster local. Lembre-se: RAC = cluster local (várias instâncias, um banco); Data Guard = replicação remota (banco primário + standby). Guarde essa fronteira e você elimina as alternativas A, B e D.
Alta disponibilidade Oracle
1RAC (cluster local)
Múltiplas instâncias, um banco
Falha de hardware/instância
Mesmo datacenter
2Data Guard (replicação remota)
Banco primário + Standby
Desastre geográfico
Transporte síncrono (Fast-Sync)
Zero Data Loss
LEVEL · soulevel.com.br
Alternativa A — ❌ Incorreta
Inverte as funções: o Oracle GoldenGate é uma ferramenta de replicação lógica (baseada em captura de mudanças), não de espelhamento síncrono de cluster; e o Oracle RAC estendido (Extended RAC) é uma configuração de cluster que pode abranger dois sites, mas não é a solução típica para replicação geográfica com Zero Data Loss — o Data Guard é. Além disso, o GoldenGate não é usado para espelhamento síncrono de bases no cluster local; isso é papel do RAC.
Alternativa B — ❌ Incorreta
O RAC está corretamente usado para alta disponibilidade local, mas o espelhamento via Storage Replication em modo assíncrono não garante Zero Data Loss. Em modo assíncrono, há uma janela de perda de dados em caso de desastre. O requisito exige integridade síncrona, portanto a replicação deve ser síncrona (Data Guard em modo Maximum Protection ou Fast-Sync).
Alternativa C — ✅ Correta ⟵ GABARITO
Combina exatamente as duas camadas necessárias: Oracle RAC para redundância de instâncias no site primário (tolerância a falhas de hardware) e Oracle Data Guard com transporte síncrono (Fast-Sync) para uma base Standby em site secundário (tolerância a desastres geográficos com Zero Data Loss). O modo Fast-Sync (Maximum Availability) é uma forma de transporte síncrono que garante que nenhuma transação seja perdida, mesmo que haja um pequeno atraso em caso de falha de rede.
Alternativa D — ❌ Incorreta
O Data Guard em modo Maximum Performance usa transporte assíncrono, o que não garante Zero Data Loss. Além disso, o Data Guard não é usado para replicação síncrona entre nós de um cluster; isso é função do RAC. A alternativa mistura os conceitos e ainda cita "espelhamento de base de dados via ferramentas de SO", que não é uma prática padrão para esse cenário.
Alternativa E — ❌ Incorreta
Cold Cluster não é uma solução de failover automático (é um cluster onde o nó reserva fica desligado até a falha, com tempo de ativação maior). E a replicação assíncrona baseada em tabelas não garante Zero Data Loss nem integridade síncrona. O requisito pede failover automático e replicação síncrona, o que não é atendido.