System Monitor & SQL Profiler - Revista SQL Magazine 92

É 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;" [...] continue lendo...