RAC, Data Guard e Alta Disponibilidade

Conceito

Aqui está a razão técnica pela qual instituições continuam pagando por Oracle. As duas tecnologias resolvem problemas diferentes, e confundi-las é o erro mais comum:

RAC não é backup. Data Guard não é escala. Um DROP TABLE acontece nos dois nós do RAC instantaneamente; e o standby do Data Guard não divide a carga de escrita. Ambiente crítico usa os dois — mais backup. Ver Estratégias de Disaster Recovery.

RAC: várias instances, um database

   nó 1 (instance 1)        nó 2 (instance 2)        nó 3 (instance 3)
        SGA + procs              SGA + procs              SGA + procs
            │                        │                        │
            └───── interconnect privado (RDMA/Ethernet dedicada) ─────┘
                                     │
                          ┌──────────┴──────────┐
                          │   STORAGE COMPARTILHADO  (ASM)  │
                          │   datafiles, redo, control      │
                          └─────────────────────────────────┘

Isto é shared disk — a abordagem oposta ao shared nothing de sharding/federação que MySQL, Postgres e MongoDB usam. Não existe equivalente mainstream, e o motivo é o problema difícil que ele precisa resolver.

Cache Fusion: o coração do RAC

Se três nós têm buffer cache próprio e todos podem escrever no mesmo bloco, quem tem a versão correta?

nó 2 quer o bloco X, que o nó 1 tem sujo em cache
  ↓
GCS (Global Cache Service) sabe quem é o "master" do bloco X
  ↓
o nó 1 envia o bloco PELA REDE (interconnect), não pelo disco
  ↓
nó 2 recebe a versão atual — sem escrever/ler disco

A transferência memória-a-memória pela rede é o que torna o RAC viável. E é também o que define seu limite: o interconnect é o gargalo, e a latência dele entra no caminho de cada bloco disputado.

Onde o RAC ganha e onde ele decepciona

A regra prática que separa sucesso de fracasso em RAC: particione a carga por serviço/afinidade para que nós diferentes toquem blocos diferentes. Se todos os nós disputam as mesmas linhas quentes (um contador, uma sequência sem CACHE), o RAC fica mais lento que um nó único.

-- sequência em RAC: sem CACHE, cada NEXTVAL é uma disputa global
CREATE SEQUENCE seq_pedido START WITH 1 CACHE 1000 NOORDER;
-- NOORDER + CACHE grande = cada nó pega uma faixa e não conversa com os outros

Data Guard: cópia sincronizada de outro site

PRIMARY ──[redo pela rede]──> STANDBY (aplica o redo continuamente)

Três modos de proteção, que são o mesmo trade-off de Availability vs Consistency:

Tipos de standby:

• Physical — cópia byte a byte via redo apply. O padrão para DR.
• Active Data Guard (opção paga) — o physical standby fica aberto para leitura enquanto aplica. Transforma DR parado em réplica de leitura útil.
• Logical — aplica SQL reconstruído; permite estrutura diferente e escrita local (nichado).
• Snapshot standby — abre o standby para escrita temporariamente (teste em dados reais) e depois descarta as mudanças e volta a sincronizar. Recurso muito prático que não tem equivalente simples.

E o Data Guard Broker (dgmgrl) automatiza monitoramento, switchover e failover:

dgmgrl sys/senha@prod
DGMGRL> show configuration;
DGMGRL> validate database standby_db;      # verifica se está apto ANTES de precisar
DGMGRL> switchover to standby_db;          # planejado, sem perda
DGMGRL> failover to standby_db;            # desastre, com o RPO do modo configurado

ASM e o resto da pilha

Trade-offs

RAC custa licença por nó e complexidade real. Dois nós de RAC não são "dois servidores de banco": são duas licenças de Enterprise Edition + a opção RAC + storage compartilhado + interconnect dedicado + conhecimento de Clusterware. Muitos ambientes teriam melhor retorno com um nó forte + Data Guard.

RAC protege contra falha de nó, não contra erro humano nem corrupção lógica. Aliás, uma corrupção de bloco no storage compartilhado afeta todos os nós — porque é o mesmo bloco.

MAX PROTECTION com um único standby é um ponto único de falha invertido. Se o standby ficar inacessível, o primário para de aceitar escrita. Configure dois standbys ou use MAX AVAILABILITY. É exatamente a mesma armadilha da réplica síncrona única no Postgres.

Active Data Guard é opção paga; ler no standby sem ela não é permitido. Um standby "aberto para leitura" sem a licença é uso indevido. Vale checar o contrato antes de desenhar a arquitetura em cima disso.

O trade-off central: o Oracle oferece a pilha de HA mais completa do mercado, e cada camada dela é uma linha de licença. A pergunta não é "o Oracle consegue?" — quase sempre consegue — mas "quanto custa e o que eu perco de simplicidade?". Onde uma hora parada custa mais que a licença anual, o cálculo fecha; fora disso, raramente fecha.

Exemplo prático

Monitorar o que importa em RAC

-- as esperas de cluster: se dominarem, você tem hot block
SELECT event, total_waits, ROUND(time_waited/100) AS segundos
  FROM v$system_event
 WHERE event LIKE 'gc%' ORDER BY time_waited DESC FETCH FIRST 10 ROWS ONLY;
-- gc cr block 2-way / gc current block 2-way  → normal (transferência)
-- gc buffer busy acquire/release              → CONTENÇÃO: bloco disputado
-- gc cr block lost                            → problema no INTERCONNECT (grave)

-- distribuição de carga por instance: desequilíbrio indica serviço mal configurado
SELECT inst_id, COUNT(*) AS sessoes FROM gv$session
 WHERE type = 'USER' GROUP BY inst_id;

-- os objetos mais disputados entre nós
SELECT object_name, statistic_name, value
  FROM v$segment_statistics
 WHERE statistic_name LIKE 'gc%' AND value > 0
 ORDER BY value DESC FETCH FIRST 10 ROWS ONLY;

Serviços com afinidade: como se usa RAC de verdade

# serviço OLTP preferindo os nós 1 e 2; relatórios isolados no nó 3
srvctl add service -db prod -service oltp    -preferred inst1,inst2 -available inst3
srvctl add service -db prod -service relatorio -preferred inst3     -available inst1
srvctl start service -db prod

A aplicação conecta em //scan-prod:1521/oltp, e o relatório pesado em //scan-prod:1521/relatorio. Nós diferentes tocam blocos diferentes → menos cache fusion → o RAC entrega o que promete. Sem isso, RAC é só custo.

Verificar Data Guard

-- lag de aplicação e de transporte
SELECT name, value, time_computed FROM v$dataguard_stats
 WHERE name IN ('transport lag', 'apply lag', 'apply finish time');

-- o standby está realmente aplicando?
SELECT process, status, thread#, sequence#, block# FROM v$managed_standby;

-- gaps de arquivo: o silencioso que quebra o DR
SELECT * FROM v$archive_gap;

Como isso falha em produção

Aprofundamento aplicado

Desenhar a falha que se quer tolerar

RAC e Data Guard atuam sobre arranjos diferentes. O projeto deve nomear a falha: processo, instância, host, armazenamento ou site. Sobreviver à perda de uma instância não demonstra que o mesmo conjunto sobreviverá à perda de todos os arquivos compartilhados.

Cenário: duas instâncias de RAC atualizam constantemente a mesma pequena coleção de blocos. A coordenação entre caches pode virar parte relevante do custo. Distribuir serviços e reduzir disputa por dados podem ser mais úteis que acrescentar instâncias.

O cliente participa da recuperação

O teste de disponibilidade precisa incluir descoberta do serviço, conexão, transação interrompida e resultado incerto. Reconectar não torna automaticamente seguro repetir uma operação que pode ter confirmado antes da falha.

Exercício: crie uma matriz com perda de instância e perda de site, registrando o componente responsável pela recuperação e o dado potencialmente perdido conforme o modo de proteção. Resultado esperado: separar disponibilidade do serviço, proteção dos dados e comportamento do cliente.

Referências: RAC e Data Guard.

Relacionado

• 2. Instance, SGA e Processos
• 3. Redo, Undo e Consistência de Leitura
• 1. Oracle Database
• 5. Replicação e Alta Disponibilidade
• 3. WAL, Checkpoint e Replicação
• Estratégias de Disaster Recovery
• High Availability
• Fail-Over

---

Parte de MOC Oracle · RAC Admin Guide (docs)