Monitorando Database Mirror com System Monitor

Olá pessoal,

Neste artigo vou mostrar alguns contadores do System Monitor relacionado ao Database Mirroring que acredito ser útil em situações onde é preciso monitorar a atividade de um banco de dados espelhado, verificar a taxa de transferencia dos registros de log, gerenciar a fila de registros em falha do banco de dados mirror ou principal, e com essas informações ter uma estimativa do tempo necessário para a sincronização dos databases, etc.

Neste artigo não irei abortar o processo de implementação e configuração do Database Mirror pois já tenho escrito um artigo com esse objetivo aqui. Como quase todas as features do SQL Server possui contadores de desempenho para monitorar suas atividades, com o Database Mirror não é diferente, vou explicar alguns dos principais contadores para Database Mirror e mostrar situações onde cada um deve ser verificado durante a atividade do sistema.

Para iniciarmos vamos entender como funciona os principais contadores:

Log Bytes Sent/sec: Este contador medi o número de bytes de log enviados ao mirror por segundo, é a taxa de qual o principal transfere registros de logs de transação para o banco de dados mirror.

Log Send Queue KB: Este contador medi a fila de dados de log de transação que não tem sido enviado ainda ao banco de dados mirror.

Transaction Delay: Este contador medi o total de delay em milisegundos que o banco de dados principal espera pelo “aviso” de commit a partir do banco de dados espelho.

Transactions/sec: Este contador medi o número de transações por segundos em um banco de dados.

No Banco de dados Mirror, vamos verificar os contadores abaixo:

Log Bytes Received/sec: Este contador medi o número de bytes de log recebidos pelo banco de dados mirror através do banco de dados principal.

Redo Queue KB: Este contador medi a fila de registros que não foram aplicados ainda ao banco de dados espelho.

Redo Bytes/sec: Este contador medi o número de bytes de log de transação estar sendo aplicado ao banco de dados espelho por segundo.

Irei detalhar as descrições dos contadores no decorrer do artigo. Para agente iniciar a monitoração, vamos abordar os três primeiros contadores descritos acima: Log Bytes Sent/sec, Log Send Queue KB, Transaction Delay. Para isso abra o System Monitor em sua instancia do banco de dados principal e adicione os contadores citados que estão localizados no Object Management SQLServer:Database Mirroring selecione os contadores e a instancia relacionada ao seu banco de dados espelhado, conforme a imagem abaixo.

image

Como disse acima para quem não tenha ainda configurado o Database Mirror neste artigo mostro passo a passo como configura-lo e suas devidos conceitos. No ambiente da simulação abaixo, estou utilizando o cenário de High Protection, ou seja, Alta Proteção da transferencia de dados entre o banco de dados principal e espelho, conforme a transação é primeiro confirmada “commit” no banco de dados espelho e após isso confirmada no banco de dados principal. Para monitorar as atividades no banco de dados espelho faça o mesmo procedimento acima selecionando os contadores Log Bytes Received/sec, Redo Queue KB, Redo Bytes/sec.

No meu exemplo estou utilizando um banco de dados chamado Performance e vou executar a seguinte instrução para simular uma carga de trabalho.

USE Performance

INSERT INTO TB1 VALUES(‘TESTE’)
GO 20000

Após executar a instrução acima, alterne para o System Monitor no banco de dados principal para iniciar a monitoração conforme a imagem abaixo. 

image

Neste momento alterne para o System Monitor no banco de dados mirror para verificar a monitoração conforme a imagem abaixo. (Poderia ter colocado todos os contadores do banco de dados principal e mirror monitorados pelo System Monitor remotamente, mas atrapalhou um pouco a visualização, por isso preferi executar o System Monitor em cada servidor separadamente.)

image

O gráfico mostrado no System Monitor no banco de dados principal medi os contadores Log Bytes Send/s de vermelho, Log Send Queue KB de verde e Transaction Delay na cor azul. Como descrevi acima o contador Log Bytes Send/s é a taxa de transferencia de bytes de log de transação para o banco de dados espelho e em nosso exemplo esse contador estar indicando um alto valor na transferencia de qual sua “linha” vermelha estar permanecendo na parte superior do gráfico, permanecendo até o final da transação. Podemos verificar que a quantidade de bytes de log enviados por segundo é alta. Já o contador Log Send Queue KB permaneceu como zero durante toda a transação pois como a taxa de envio de bytes de log por segundo (Log Bytes Send/s) e a taxa de recebimento de bytes de log (Log Bytes Received/sec) no banco de dados mirror estava estável o banco de dados principal não precisou armazenar registros dentro da fila de envio de log no log de transação, ou seja, o banco de dados principal estava conseguindo enviar os logs de transação em tempo satisfátório para o banco de dados espelho.

O contador Transaction Delay nos indica o total em milisegundos que o banco de dados principal espera pelo aviso de commit no banco de dados espelho. Em nosso gráfico esse contador permaneceu na parte inferior, indicando um baixo valor de espera. Esse contador é o principal contador a ser monitorado em um ambiente de High Protection e High Availability de qual utiliza Safety Full um alto valor constante pode impactar problemas de performance nas transações. Como disse que este contador indicava um total em milisegundos de delay nas transações, para verificar qual o delay estimado em cada transação apenas divida o contador Transaction Delay pelo Transactions/sec de qual irá indicar essa média.

No banco de dados mirror vamos analisar o contador Log Bytes Received/sec de qual indica a quantidade de bytes de log recebidos a partir do banco de dados principal. Em nosso gráfico este contador também é indicado pela cor vermelha e teve um alto valor permanecendo numa escala próximo ao 70% indicando que a taxa de recebimento dos bytes de log de transação estava alta. O contador Redo Bytes/sec indicado pela cor verde, variou por quase as mesmas medidas do contador Log Bytes Received/sec. Este contador medi o número de bytes de log de transação aplicados ao banco de dados espelho por segundo, em nosso caso podemos observar que a medida que os bytes de log foram recebidos estes já eram aplicados ao banco de dados espelho, quando o tráfego de envio de log é muito grande e o banco de dados espelho não consegui aplicar os registros em tempo satisfatório é gerada uma fila armazenado os registros recebidos pelo banco de dados principal mas que ainda nao tem sido aplicado ao banco de dados espelho. Essa fila é medida pelo contador Redo Queue KB indicada pela cor azul em nosso gráfico. Reparem que este contador permaneceu zero, ou seja, não foi preciso armazenar os registros na fila, pois estes já foram aplicados na medida em que eram recebidos.

Agora que já vimos alguns dos conceitos mais importantes, vamos simular cenários para agente verificar o comportamento dos contadores. Em nosso ambiente de testes vamos alterar o modo de segurançã da transação, vamos alterar para Safety OFF ,ou seja, o banco de dados principal nao irá esperar o “aviso” de commit a partir do banco de dados espelho para confirmar a transação, com isso vamos monitorar o comportamento do contador Transaction Delay. Para esse exemplo, adicione o contador Transactions/sec de qual estar no Object Management Databases ao System Monitor junto com os demais contadores e utilize a instrução abaixo para habilitar o modo de segurança OFF e execute a transação novamente.

ALTER DATABASE [Performance] SET SAFETY OFF

USE Performance

INSERT INTO TB1 VALUES(‘TESTE’)
GO 20000

image

No Gráfico acima monitado a partir do System Monitor do banco de dados principal selecionei o contador Transaction Delay para destacar que sua atividade foi zero. Com isso percebemos que o banco de dados principal não estar tendo delay na transação, não estar esperando o “aviso” do banco de dados espelho para confirmar a transação, a transação é confirmada e após enviada ao banco de dados espelho. Como já esperado o contador Log Bytes Send/s permaneceu na parte superior e o contador Transactions/sec também mediu as transações por segundo enviadas ao banco de dados espelho. Para melhor visualização alterei a escala do contador Transactions/sec para não sobrepor a linha do contador Log Bytes Send/s.

Agora iremos simular um cenário onde o banco de dados principal é desconectado do banco de dados espelho para verificar a fila de envio de log medida pelo contador Log Send Queue KB, para isso vou desconectar o adaptador de rede do servidor espelho simulando uma indisponibilidade qualquer. Se você é um daqueles DBA´s que só acredita vendo ou melhor “lendo” vamos ler o conteúdo do errorlog do SQL Server para verificar que o banco de dados espelho não estar respondendo, assim deixando o banco de dados principal desconectado do banco de dados espelho.

2010-07-07 11:13:05.32 spid23s     Error: 1479, Severity: 16, State: 1.
2010-07-07 11:13:05.32 spid23s     The mirroring connection to "TCP://SERVER2008:1450" has timed out for database "Performance" after 10 seconds without a response.  Check the service and network connections.
2010-07-07 11:13:05.32 spid23s     Database mirroring is inactive for database ‘Performance’. This is an informational message only. No user action is required.

Com o banco de dados principal isolado, emita novamente a transação. (Neste exemplo irei inserir 200 mil linhas para a fila crescer bastante para visualizarmos melhor)

USE Performance

INSERT INTO TB1 VALUES(‘TESTE’)
GO 200000

image

Podemos visualizar através do gráfico acima que o contador Log Send Queue KB indicado pela cor verde foi crescendo gradativamente de acordo com as transações vao preenchendo a fila até permanecer na parte superior do gráfico, o interessante é que este contador permanece estável durante e após a transação indicando que as transações estão na fila aguardando para serem enviadas ao servidor espelho. Neste momento se verificarmos a wait do log de transação indicando qual o motivo pelo qual este não pode ser sobrescrito podemos visualizar como DATABASE_MIRRORING de qual indica que existem transções ativas no log de qual são as transações que ainda não foram enviadas ao banco de dados espelho por isso o log de transação não pode ser truncado. Para visualizar emita a instrução abaixo:

SELECT name,log_reuse_wait_desc
FROM sys.databases
WHERE name = ‘Performance’

name              log_reuse_wait_desc
—————– —————————-
Performance   DATABASE_MIRRORING

(1 row(s) affected)

Caso quando emita a instrução acima, apareça na coluna log_reuse_wait_desc o valor BACKUP_LOG faça um backup do log de transação para retirar a porção inativa do log de transação causado por outras transações e emita novamete a transação para verificar o valor desta coluna.

Voltando ao gráfico podemos observar que o contador Transactions/sec permaneceu na parte superior do gráfico medindo as transações por segundo no banco de dados principal e logo mais este contador teve uma queda brusca pois a transação foi concluída. Reparem que os contadores Log Bytes Send/s e Transaction Delay permanecem como zero, pois não estar havendo transferencia de bytes de log para o banco de dados espelho.

Agora que já visualizamos o aumento da fila de envio de log vamos colocar novamente o banco de dados espelho no ar e monitorar os contadores no banco de dados principal e espelho. Após restabelecer a conexão com o banco de dados espelho verifique o errorlog do SQL Server e monitore os contadores em ambos os servidores conforme as imagens abaixo.

2010-07-07 15:44:47.18 spid23s Database mirroring is active with database ‘Performance’ as the principal copy. This is an informational message only. No user action is required.

image

No gráfico do banco de dados principal podemos ver que quando o banco de dados espelho foi colocado online a fila de envio de log medida pelo contador  Log Send Queue KB caiu gradativamente, os registros foram transferidos para o banco de dados espelho, como podemos observar o comportamente do contador Log Send Sent/sec que aumentou repentinamente assim que conexão foi restabelecida. Verifique as imagens abaixo sobre o gráfico do banco de dados espelho:

image

image

No primeiro gráfico podemos observar o comportamento dos contadores  Log Bytes Received/sec e Redo Bytes/sec que atigiram picos de atividade assim que a conexão com o banco de dados principal foi estabelecida indicando que os bytes de log de transação começaram novamente a ser recebidos e que já estavam começando a serem aplicados ao banco de dados espelho. O mais interessante do gráfico foi que a linha do contador Redo Queue KB começou a subir pelo fato de as transações estarem sendo armazenadas em fila para ser aplicadas ao banco de dados espelho, pois o volume de bytes de log recebidos não era o mesmo que o número de bytes aplicados ao banco de dados espelho, por isso foi preciso criar a fila.

No segundo e último gráfico podemos observar que a fila de redo (Redo Queue KB) subiu como disse acima mas no decorrer do gráfico essa começa a cair, conforme as transações são aplicadas ao banco de dados espelho. Conforme a linha do tempo do gráfico vai passando podemos verificar a atividade de sincronização do banco de dados espelho de forma clara, com todas as fases bem distintas.

Espero que este artigo seja útil para aqueles que precisem monitorar as atividades do Database Mirror, que precisem estimar dados de performance e utilização de recursos. Este artigo se aplica ao SQL Server 2005 e também SQL Server 2008, apesar do SQL Server 2008 possui mais alguns contadores (Este pode ser um tema para outro artigo).

Muito Obrigado.

Abraços.

Advertisements

One Response to Monitorando Database Mirror com System Monitor

  1. Pingback: Implementando Espelhamento de Banco de Dados (Database Mirror) « Alex Souza

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: