Replication lag no Oracle GoldenGate: diagnóstico fila a fila ajuda a achar o gargalo

A tese do texto é direta: lag no GoldenGate não é um número só, é a soma das esperas em uma cadeia de filas. Redo na origem, captura do Extract, escrita no trail, caminho de distribuição, apply do Replicat e commit no alvo. O reflexo de subir o paralelismo do Replicat só funciona quando o apply é a restrição real. Pela lei de Little, o lag indica quanto trabalho está enfileirado em algum ponto, e pelo resultado de Kingman a espera explode perto da saturação de um estágio.

O lag de processo (LAG ou SEND ... GETLAG) mede quão velho é o registro que o processo está tocando, e um Replicat parado no fim do trail pode parecer saudável com dado fresco preso a montante. Já as tabelas de heartbeat medem a posição real no alvo, com um heartbeat a cada 60 segundos por padrão e decomposição hop a hop. Com várias pumps em série, o timestamp de roteamento é sobrescrito e vira agregado. Vale ler INCOMING_HEARTBEAT_AGE junto com INCOMING_LAG: se a idade sobe com o lag estável, os heartbeats pararam de chegar.

Três causas ficam fora do alcance dos appliers: transações maiores que CHUNK_SIZE (serializadas, a menos que SPLIT_TRANS_RECS as quebre), cadeias de dependência em linhas quentes e ausência de chave ou índice no alvo, que faz o Replicat montar o WHERE com todas as colunas, na prática um full scan. KEYCOLS define identidade, não caminho de acesso: sem índice nessas colunas, o scan continua.

No modelo discreto do autor (que simula o mecanismo, não o Oracle), quadruplicar appliers mantém o pico de lag em 823 s com transações grandes, e o split reduz o pico a 178 s, valor que é um limite superior porque as peças ganham chaves únicas. Com índice inutilizável em chaves quentes, 64 appliers empatam com 16. Sob throttle de rede, o pico é idêntico com 4 e 16 appliers; mais appliers só encurtam o escoamento do backlog. O modelo ignora contenção entre appliers e o fallback serial de DDL e SQLEXEC.

Para quem opera GoldenGate, a leitura prática é trocar o reflexo por método: heartbeat em todos os paths antes do go-live, alerta sobre idade do heartbeat além do lag, e auditoria de chaves e índices no alvo antes da carga inicial. Em active-active, o lag também é sinal de correção, porque alarga a janela de conflito, e essa janela pode continuar aberta durante o escoamento depois que a falha original foi corrigida. Se mais appliers não mexem no lag, isso é evidência de que o gargalo está em outro estágio.