Replicação transacional no SQL Server: como monitorar de verdade

Ver os agentes da replicação transacional como "Running" não prova que os dados estejam chegando ao destino no tempo esperado. O Log Reader Agent pode estar ativo e demorar para ler o log; o Distribution Agent pode continuar executando enquanto acumula comandos; e uma assinatura sem alterações recentes pode parecer saudável mesmo depois de perder a comunicação com o Assinante.

O monitoramento precisa responder a uma pergunta de negócio: quanto tempo uma transação confirmada no Publicador leva para estar disponível no Assinante? Para explicar a resposta, é necessário observar separadamente os dois trechos da replicação e o estoque de trabalho entre eles.

Onde o atraso pode se acumular

Na replicação transacional, o caminho da alteração tem três pontos principais:

1. a aplicação confirma a transação no banco publicado;
2. o Log Reader Agent lê os comandos marcados para replicação no transaction log e os grava no banco de distribuição;
3. o Distribution Agent lê esses comandos e os aplica no banco do Assinante.

Isso cria duas latências diferentes. A primeira fica entre Publicador e Distribuidor. A segunda, entre Distribuidor e Assinante. Medir apenas o tempo total informa que existe atraso, mas não mostra qual agente ou servidor precisa ser investigado.

O SQL Server Agent também faz parte dessa cadeia. Por padrão, os agentes da replicação são executados como jobs; se o serviço estiver parado, os jobs não avançam. Em assinaturas push, o Distribution Agent roda no Distribuidor. Em assinaturas pull, ele roda no Assinante. Essa diferença define onde consultar histórico, falhas e duração do job.

Comece pelo estado das assinaturas

O Replication Monitor é útil para investigação visual, mas os mesmos dados podem ser coletados por T-SQL e enviados à ferramenta de monitoramento da empresa. No banco de distribuição, sp_replmonitorhelpsubscription retorna uma linha por assinatura e expõe estado, alertas, latência, último sincronismo e nome do Distribution Agent.

USE distribution;GO EXEC sys.sp_replmonitorhelpsubscription    @publisher = N'SRV-PUBLICADOR',    @publisher_db = N'BancoPublicado',    @publication = N'PublicacaoTransacional',    @publication_type = 0,    @mode = 0;

Os campos mais úteis para uma coleta recorrente são:

• status: consolida o pior estado dos agentes associados à assinatura; valores como falha, nova tentativa ou parada merecem contexto imediato;
• warning: indica se algum limite configurado foi excedido;
• latency e latencythreshold: comparam a latência observada com o limite da publicação;
• last_distsync: mostra quando o Distribution Agent executou pela última vez;
• distribution_agentname: identifica o job que deve ser correlacionado com o histórico do SQL Server Agent.

Um único retrato ainda pode enganar. Armazene as coletas com horário e compare a tendência. Uma assinatura com latência de 20 segundos pode estar se recuperando depois de um pico ou pode ter crescido de 2 para 20 segundos em poucos minutos. O segundo caso exige atenção antes mesmo de atingir um limite fixo.

Meça a latência ponta a ponta com tracer token

O tracer token é uma pequena marca inserida no log da publicação e enviada pelo mesmo caminho de uma transação replicada. Ele mede separadamente:

• o tempo do Publicador até o banco de distribuição;
• o tempo do Distribuidor até cada Assinante;
• a latência total de ponta a ponta.

No Replication Monitor, a aba Tracer Tokens permite inserir o token e acompanhar esses três tempos. Se ele permanece pendente antes do Distribuidor, investigue o Log Reader Agent. Se chega ao Distribuidor, mas não ao Assinante, concentre a análise no Distribution Agent, no Assinante e na conectividade entre eles.

O token é especialmente importante em ambientes com pouco movimento. Sem uma transação nova, o painel pode não demonstrar que o caminho está interrompido. Uma validação periódica com tracer token testa o fluxo real, mas não substitui o acompanhamento contínuo do backlog.

Conte os comandos que ainda não chegaram

Latência e fila não são a mesma métrica. Um lote muito grande pode produzir milhares de comandos pendentes em poucos segundos; uma transação bloqueada no Assinante pode manter uma fila menor parada por muito tempo. A combinação das duas mostra volume e idade do problema.

Execute sp_replmonitorsubscriptionpendingcmds no banco de distribuição para obter a quantidade estimada de comandos pendentes e o tempo aproximado para processá-los:

USE distribution;GO EXEC sys.sp_replmonitorsubscriptionpendingcmds    @publisher = N'SRV-PUBLICADOR',    @publisher_db = N'BancoPublicado',    @publication = N'PublicacaoTransacional',    @subscriber = N'SRV-ASSINANTE',    @subscriber_db = N'BancoAssinante',    @subscription_type = 0; -- 0 = push; 1 = pull

O resultado contém pendingcmdcount e estimatedprocesstime, em segundos. Trate o tempo como estimativa, não como prazo garantido: a taxa recente de aplicação pode mudar com bloqueios, I/O, concorrência e tamanho das próximas transações. Se a fila parar de drenar, correlacione as sessões do Assinante com o método para achar a query que bloqueia as outras no SQL Server.

Mais importante que alertar por uma quantidade universal é observar o comportamento da própria assinatura. Uma fila de 50 mil comandos que cai a cada coleta está drenando. Uma fila de 5 mil que dobra continuamente está caminhando para um incidente. Registre também a variação por minuto para saber se o Distribution Agent aplica mais rápido do que o Publicador produz.

Em topologias peer-to-peer, valide a versão e as limitações documentadas para esse procedimento. O suporte foi adicionado no SQL Server 2019 CU17, e metadados antigos em MSrepl_originators ainda podem distorcer a contagem em determinados cenários.

Não monitore só os agentes

Quando o atraso aparece, quatro componentes precisam ser correlacionados.

O transaction log do banco publicado é outro sinal indispensável. A replicação pode impedir o truncamento enquanto comandos necessários ainda não foram entregues ao Distribuidor. Consulte o motivo de reutilização do log no Publicador:

SELECT    name,    recovery_model_desc,    log_reuse_wait_descFROM sys.databasesWHERE name = N'BancoPublicado';

Se log_reuse_wait_desc mostrar REPLICATION, confirme se o Log Reader Agent avança e se há transações marcadas para replicação ainda no log. Se mostrar ACTIVE_TRANSACTION, procure uma transação longa. O valor explica por que o log não pode ser reutilizado naquele instante; não autoriza limpar o log, remover a replicação ou matar uma sessão sem identificar a causa.

No Distribuidor, monitore espaço livre, crescimento do arquivo e execução dos jobs de manutenção, principalmente Distribution clean up: distribution, Agent history clean up: distribution, Replication agents checkup e Replication monitoring refresher for distribution. Um cleanup atrasado pode ampliar o banco de distribuição; uma retenção curta demais, por outro lado, reduz a janela disponível para uma assinatura se recuperar.

Transforme os sinais em alertas acionáveis

Um monitoramento útil combina estado, tendência e impacto. Uma base prática inclui:

• agente em falha ou em nova tentativa;
• tracer token pendente ou latência total acima do objetivo do serviço;
• comandos pendentes crescendo em coletas consecutivas;
• last_distsync antigo para o padrão daquela assinatura;
• banco de distribuição ou transaction log próximos do limite de capacidade;
• job de limpeza ou checkup com falha.

Não use o mesmo limite para todas as assinaturas. Um Assinante que alimenta uma API pode tolerar segundos; uma carga de relatórios talvez aceite minutos. Defina o limite a partir do atraso máximo que o consumidor suporta e mantenha uma margem para intervenção antes de violá-lo.

O alerta deve carregar Publicador, publicação, Assinante, assinatura push ou pull, latência por trecho, comandos pendentes, horário do último sincronismo e nome do agente. Assim, o plantonista recebe uma hipótese inicial em vez de apenas "replicação atrasada".

O painel mínimo para a replicação transacional

Para cada assinatura, mantenha no mesmo painel:

1. estado atual do Log Reader e do Distribution Agent;
2. latência Publicador → Distribuidor e Distribuidor → Assinante;
3. quantidade e tendência dos comandos pendentes;
4. taxa de entrega por segundo;
5. uso do log publicado e espaço do banco de distribuição;
6. falhas recentes dos jobs de agentes e manutenção.

Essa visão separa indisponibilidade de degradação. Um agente parado é um problema explícito. Um agente executando com fila crescente é um problema silencioso — e normalmente é esse que chega primeiro ao usuário como dado desatualizado.

As consultas deste artigo são somente leitura, mas os procedimentos de monitoramento exigem permissões no banco de distribuição. Prefira conceder a função replmonitor a uma conta dedicada, quando compatível com o procedimento usado, em vez de executar a coleta permanentemente como sysadmin.

Referências: visão geral dos agentes de replicação, monitoramento programático da replicação, tracer tokens e sp_replmonitorsubscriptionpendingcmds.

Se a replicação está ativa, mas a latência cresce sem uma causa clara, a H1 Data oferece um diagnóstico gratuito de SQL Server para correlacionar agentes, backlog, transaction log, banco de distribuição e gargalos no Assinante.