SQL Server Always On: monitoramento e alertas

Always On resolve failover, mas monitorar só "o AG está saudável ou não" esconde o problema mais comum na prática: um secundário sincronizado mas atrasado, que em caso de failover real vai perder dados ou demorar muito mais do que o esperado pra assumir.

As métricas que realmente importam

SELECT
  ag.name AS availability_group,
  ar.replica_server_name,
  ars.synchronization_health_desc,
  drs.synchronization_state_desc,
  drs.log_send_queue_size, drs.redo_queue_size
FROM sys.dm_hadr_availability_replica_states ars
JOIN sys.availability_replicas ar ON ar.replica_id = ars.replica_id
JOIN sys.availability_groups ag ON ag.group_id = ar.group_id
JOIN sys.dm_hadr_database_replica_states drs ON drs.replica_id = ars.replica_id;

log_send_queue_size (quanto log ainda não chegou no secundário) e redo_queue_size (quanto já chegou mas ainda não foi aplicado) são os números que mostram atraso real — "HEALTHY" no synchronization_health_desc só confirma que a réplica está se comunicando, não que ela está em dia.

O que monitorar continuamente

• Crescimento de log_send_queue_size ao longo do tempo — fila crescendo indica que o secundário não acompanha o volume de escrita da primária.
• Estado do listener e a role atual de cada réplica — pra saber imediatamente se um failover (planejado ou não) aconteceu.
• Falha de sincronização (NOT_HEALTHY) em modo síncrono — nesse modo, a primária pode ficar bloqueada esperando confirmação do secundário até o timeout.
• Espaço em disco no secundário — redo_queue_size alto às vezes é sintoma de disco lento no destino, não de rede.

O codeDB monitora múltiplas instâncias do mesmo ambiente de forma independente, então uma réplica atrasando aparece como alerta antes de um failover real expor o atraso na pior hora possível.