Em que situação o tema é útil: Se constantemente você recebe queixas de queda de desempenho, está na hora de verificar como está a “saúde” do seu ambiente de banco de dados. Problemas assim podem ser um bom indício de que algo não está funcionando corretamente. Resumo DevMan: Este artigo apresenta, de forma teórica e prática, um estudo sobre as ferramentas System Monitor e SQL Server Profile. Ao final, realizamos um estudo de caso para demonstrar como aproveitar o melhor destas duas ferramentas trabalhando em conjunto na identificação de problemas do dia a dia de um DBA.
É muito comum nos dias de hoje enfrentarmos problemas com desempenho no trabalho ou até mesmo no conforto de nossa casa. Você pode estar se perguntando: como assim? Imagine a seguinte situação: uma turma de amigos resolveu marcar um encontro on-line para disputar aquele jogo que acabou de ser lançado. Caso você não tenha uma boa placa de vídeo, memória e processador, a reuniãozinha vai ter que ficar para outro dia, pois o jogo vai ficar lento, a imagem no seu monitor ficará instável, entre outros problemas.
Falando no mundo do banco de dados, infelizmente estamos sempre sujeitos a falhas de hardware, bloqueio de transações, paginação, dentre outras coisas que acarretam na degradação das nossas aplicações. Diante destas situações, abordaremos neste artigo como monitorar seu ambiente de SQL Server e como diagnosticar tais problemas através de um estudo de caso prático. O desafio é reunir o System Monitor com o SQL Profiler de uma maneira coerente, de forma que nos permita fazer uma análise eficiente.
Para isso, vamos criar um cenário fictício tendo como objetivo ajudar na compreensão dos conceitos. Deste modo, imaginemos que somos funcionários da AdventureWorks e que parte das atribuições destinadas a nós incluem ficarmos encarregados de monitorar o ambiente de produção, ou seja, verificar o desempenho do banco de dados como um todo. Para tal, podemos realizar tarefas como analisar se está acontecendo I/O no disco, como está o processador ou a memória do servidor, quantas conexões estão ativas, e assim por diante.
Apesar disso, ultimamente o Help Desk tem recebido muitas ligações reportando problemas de lentidão com as aplicações. Assim, resolvemos investigar o motivo dessas reclamações.
Adotando o System Monitor
Com o objetivo de solucionar nosso problema, a primeira coisa que vamos fazer é utilizar o System Monitor para coletar as informações do servidor de banco de dados.
O System Monitor mostra graficamente os dados em tempo real de desempenho, incluindo a utilização do processador, cache, fila de impressão, sincronização, uso da largura de banda e milhares de outras estatísticas. Ele emprega uma arquitetura de sondagem para capturar e registrar dados numéricos expostos pelos aplicativos. Para isso, o DBA escolhe os contadores a serem capturados para estudo de acordo com a análise que ele necessita fazer. No nosso caso, vamos escolher os contadores que nos ajudará a identificar o motivo da queda de desempenho nas aplicações.
No entanto, para entendermos como obter as informações desejadas, é importante compreender os três níveis fundamentais para os critérios de monitoramento (veja a Figura 1). Estes níveis são:
- OBJECT: É um componente, aplicativo ou subsistema dentro de um aplicativo, por exemplo, Processor, Network Interface eSQLServer:Databases;
- COUNTERS: É um subconjunto de um object. Para um determinado Object você pode ter vários contadores, por exemplo, o Object Processor tem vários contadores, como %Processor Time, %User Time, Interrupts/sec, entre outros;
- INSTANCES: Cada counter, por sua vez, pode ter um ou mais Instances. Caso necessite, você tem a capacidade de monitorar apenas uma instância de um Counter de dados.
Deste modo, antes de criarmos nosso primeiro Data Collector Sets, vamos destacar três contadores em especial. São eles: System: Processor Queue Length;Network Interface: Output Queue Length; e Physical Disk: Avg Disk Queue Length.Se identificarmos alguma anormalidade neles, teremos sérios problemas no sistema.
- System: Processor Queue Length: Este contador, ao invés de avaliar o uso de um único processador, avalia o enfileiramento de threads aguardando oportunidade de execução em todos os processadores. Se ele excede duas threads por cada processador durante períodos contínuos ou durante um período de monitorização de 24 horas, você poder ter um gargalo de CPU. Por exemplo, se você possui seis CPUs no seu servidor, o valor deste contador não deve ultrapassar quanto? O resultado é a multiplicação de 06 CPUs com 02 threads (valor aceitável por processador). Assim, se este valor é ultrapassado por um período muito extenso e constante, pode indicar que seus processadores não estão mais suportando a carga do sistema;
- Network Interface: Output Queue Length:Este contador de desempenho indica o tamanho da fila de pacotes de saída. Ou seja, quantos pacotes estão sendo mantidos em uma fila, esperando para ser enviado a partir da placa de rede. Geralmente esse valor é zero. Como regra geral, se o Output Queue Length for superior a dois por um período de 10 minutos, provavelmente você tem um problema de desempenho de rede, e isso está causando gargalo na rede. As possíveis causas desse problema podem estar em várias coisas, como por exemplo: uma placa de rede lenta, um problema de rede, um problema no hub ou switch, entre outros; ...
