Monitorando a latência da replicação transacional com Tokens

Creio que dois dos fatores mais impactantes numa topologia de replicação transacional são o throughput e a latência. O throughput nada mais é que a quantidade de atividade – medida em comandos ou transações entregues – que o sistema mantém ao longo do tempo. Já a latência é o tempo em que os dados alterados no publicador – banco de dados que está sendo publicado – levam para ser aplicados no banco de dados assinante. Logo, o fator mais evidente ao usuário é a latência.

Uma maneira prática de monitorar a latência atual é através do Replication Monitor. Basta se conectar à instância participante da replicação através do SSMS, expandir a árvore de diretórios, clicar com o botão direito na pasta “Replication” e depois em “Launch Replication Monitor”. Mas depois de algum tempo acompanhando os números subirem e descerem você lembra que seu tempo pode ser mais bem gasto. Afinal de contas você não quer ficar olhando para o Replication Monitor o dia todo ou durante a madrugada quando os avisos de latência não param de chegar. É aí que entram os Tokens de Rastreamento (ou Tracer Tokens).

Os Tokens de Rastreamento são pequenos pacotes de dados inseridos no log transacional do Publicador para medir estatísticas de latência na topologia de replicação. O processo é iniciado assim que o Token é escrito no log transacional, sendo anotado o momento em que foi disparado. Então, novamente quando o Log Reader Agent recupera o Token. E, finalmente, quando o Token é aplicado no assinante pelo Distribuition Agent. Os momentos exatos em que o Token é registrado tanto no Publicador quanto no Distribuidor podem ser recuperados na tabela MStracer_tokens. Já para o registro do Token no Assinante, é necessário consultar a tabela MStracer_history. Ambas as tabelas estão no banco de distribuição.

Sabendo disso, precisamos apenas disparar os Tokens, certo? Errado. Existem algumas limitações e restrições que devemos levar em conta. Uma das condições para o uso dos Tokens é a versão do SQL Server, mas se você está utilizando a versão 2005 ou superior não terá problemas (se ainda está trabalhando com a versão 2000, pare tudo e vá migrar de versão). Outras restrições incluem que a Assinatura tem que estar ativa (inicializada) e o Assinante deve ter passado pelo processo inicial de sincronização. Isso sem mencionar o óbvio: deve existir uma publicação ativa e os participantes devem estar acessíveis.

Os passos a seguir são opcionais e servem apenas como validações adicionais para o processo de monitoramento que queremos montar. Inicialmente, verificamos a publicação.

USE [Publicador]
EXEC sp_helppublication @publication = 'Publicação'
GO

Observando o resultado, temos os dados a seguir.
sp_helppublication
A imagem foi cortada para mostrar apenas o que nos interessa: a coluna “status”. O valor “1” para este atributo indica que a publicação está ativa. Para a lista completa dos atributos e todos seus significados e valores, consulte sp_helppublication.

Repetindo o processo de validação para verificarmos a assinatura…

USE [Publicador]
EXEC sp_helpsubscription @publication = 'Publicação', @article = 'all'
GO

Temos como saída o seguinte resultado.
sp_helpsubscription
Aqui utilizamos o parâmetro “all” para agrupar as informações de todos os artigos, dado que queremos apenas as informações da assinatura como um todo. Novamente, a imagem foi cortada para mostrar apenas o importante: a coluna “subscription status”. O valor “2” indica que a assinatura está ativa. Para a lista completa dos atributos e todos seus significados e valores, consulte sp_helpsubscription.

Agora que terminamos com as validações, vamos disparar um Token! Para isso poderíamos usar o próprio Replication Monitor, mas, ao invés disso, usaremos o bom e velho T-SQL e a stored procedure sp_posttracertoken. Por questão de praticidade, nesta demonstração iremos supor que o Publicador e o Distribuidor estão na mesma instância.

USE [Publicador]
-- Variáveis de controle
DECLARE @token_id INT;
-- Dispara o Token
EXEC sp_posttracertoken @publication = 'Publicação',
@tracer_token_id = @token_id OUTPUT;
-- Aguarda que o Token chegue
WAITFOR DELAY '00:00:10'
-- Verifica o "percurso" do Token
USE [distribution]
SELECT t.[publication_id],t.[publisher_commit],
t.[distributor_commit],h.[subscriber_commit]
FROM [MStracer_tokens] t
JOIN [MStracer_history] h
ON t.[tracer_id] = h.[parent_tracer_id]
WHERE t.[tracer_id] = @token_id;

Executando este script temos a saída a seguir.
sp_posttracertoken
Com esse resultado já podemos saber o tempo que o Token levou desde a saída do Publicador (publisher_commit), passando pelo Distribuidor (distributor_commit) até sua chegada ao Assinante (subscriber_commit). Ajustando a consulta anterior para retornar o tempo em segundos levado pelo Token em cada parte do trajeto, temos o seguinte:

USE [distribution]
SELECT [publication_id],
DATEDIFF(s,t.[publisher_commit],t.[distributor_commit]) AS 'Latência do Distribuidor(s)',
DATEDIFF(s,t.[distributor_commit],h.[subscriber_commit]) AS 'Latência do Assinante(s)'
FROM [MStracer_tokens] t
JOIN [MStracer_history] h
ON t.[tracer_id] = h.[parent_tracer_id];

Desta forma temos um resultado mais amigável para avaliar a latência como visto a seguir.
latencia
Poderíamos ainda utilizar as stored procedures sp_helptracertokens e sp_helptracertokenhistory para recuperar os dados do Token sobre a latência entre os trechos do trajeto e o momento em que foi disparado, mas este método fica para um próximo artigo. De qualquer forma, este método pode ser encontrado no BOL.

Agora basta criarmos um job que dispare Tokens em intervalos regulares – digamos a cada 10 minutos – e teremos registros da latência em nossa topologia de replicação. Vale ressaltar que esses Tokens existirão até que atinjam o período de retenção definido para o job de manutenção da replicação, o Agent History Clean Up: Distribution que tem como valor padrão 48 horas. Assim, temos uma janela máxima em horas igual ao período de retenção. Isto não impede de guardarmos estes dados numa tabela para manter o histórico.

Apesar de o formato tabular ser bem familiar aos profissionais que trabalham com banco de dados, gosto de gerar formas gráficas para facilitar análises de tendências e padrões. Com a última consulta criada é prático plotarmos os dados num gráfico dinâmico do Excel. Para esta análise, escolhi a janela da latência nas últimas 24 horas como mostra o gráfico.

Através do gráfico é fácil identificar, por exemplo, processos que são executados durante a madrugada – neste caso, por volta da 1 hora da manhã. Pode-se, ainda, acompanhar a latência durante o horário comercial, ou traçar uma baseline para identificar comportamentos fora do padrão. Com o auxílio visual, conseguimos isolar eventos que geram aumento na latência rapidamente, podendo direcionar nossa atenção ao que interessa.

Anúncios