Por que eu devo ler este artigo:

Com o surgimento de novas edições do SQL Server, novas ferramentas foram adicionadas ao arsenal do DBA. Com base nisso, este artigo abordará técnicas de monitoração que surgiram até o SQL Server 2012 e boas práticas para sua implantação. Adotar boas práticas ao gerenciar um banco de dados culmina na monitoração proativa da instância. Ou seja, independente da existência de problemas no SQL Server, deve existir um acompanhamento de desempenho histórico para prever ou corrigir problemas rapidamente.

A rotina de qualquer DBA inclui a monitoração de um banco, seja de forma proativa ou para encontrar e descobrir problemas que estejam ocorrendo no ambiente.

Com o passar dos anos, o SQL Server evoluiu neste aspecto, entregando ferramentas cada vez mais completas e intuitivas para a monitoração do banco de dados. Porém, muitas vezes, o impacto que ferramentas como o SQL Server Profiler geram acaba agravando ou criando novos problemas de recursos, caso o servidor não esteja bem dimensionado ou o banco de dados seja extremamente transacional e sensível.

É importante ressaltar que o direcionamento da Microsoft é diminuir cada vez mais o uso do SQL Server Profiler, com a introdução dos Extended Events na versão 2008 do SQL Server.

Portanto, serão apresentadas alternativas de monitoração do SQL Server que geram pouco impacto no banco de dados e que, inclusive, podem ser implantadas em longo prazo para a geração de métricas e possibilitar a investigação posterior de eventos.

SQL Trace

O SQL Trace surgiu com o jurássico SQL Server 6.5 como uma forma de monitorar a comunicação cliente-servidor. Com o objetivo de capturar queries e stored procedures, sua limitação era visível ao tentar monitorar eventos mais complexos, como a aquisição e liberação de locks.

SQL Server Profiler

Com o surgimento do SQL Server 7.0, a Microsoft implementou uma forma gráfica e poderosa de capturar diversos tipos de eventos gerados pelo SQL Trace. A Figura 1 exemplifica a arquitetura do SQL Trace a partir do SQL Server 7.0.

Note que o SQL Server Profiler é apenas uma das diversas maneiras para capturar os eventos internos do banco de dados ou oriundos da comunicação cliente-servidor.

Arquitetura do SQL Trace a partir do SQL Server 7.0

Figura 1. Arquitetura do SQL Trace a partir do SQL Server 7.0.

Criando um trace via SQL Server Profiler

Para criar um Trace no SQL Server Profiler, devemos proceder da seguinte forma. Primeiro, inicie a ferramenta SQL Server Profiler, e clique em File > New Trace. Em seguida, informe o servidor e as credenciais de acesso. O usuário SQL Server deve ser administrador do banco de dados. A partir do SQL Server 2005, a permissão ALTER TRACE tornou esse privilégio mais granular.

As propriedades gerais do Trace são mostradas na Figura 2. São apresentados templates com eventos pré-selecionados para diversas situações (Ex: Locks, Tuning). O Trace pode ser nomeado para facilitar a visualização e localização posterior. Pode-se configurar a saída do trace para um arquivo ou tabela.

Estas configurações de saída serão úteis ao demonstrarmos as melhores práticas de um Trace. Por último, podemos definir um horário para que o trace seja interrompido. Na tela da Figura 2 selecione o template Tuning.

Propriedades gerais do Trace

Figura 2. Propriedades gerais do Trace.

Conforme a Figura 3, selecione a aba Events Selection e clique em Column Filters. Apenas alguns filtros pré-selecionados no Template são exibidos. Informaremos o valor 1000 (valor em milissegundos) no item Duration / Greater than or equal.

Configurando o Trace

Figura 3. Configurando o Trace.

Feito isso, após clicar em OK/Run, o trace será iniciado e coletará queries ...

Quer ler esse conteúdo completo? Tenha acesso completo