Monitoramento SQL Server

MONITORAMENTO SQL
SERVER
Lílian Simão Oliveira
Ferramentas que auxiliam o
monitoramento



O SQL Server Management Studio fornece várias
ferramentas para auxiliar o processo de desempenho
de aplicação. As consultas e os procedimentos
armazenados podem ser desenvolvidos e testados
usando o Query Editor integrado, que substitui o SQL
Server Query Analyzer.
Mais análises podem ser feitas usando o SQL Server
Profiler.
As recomendações de ajuste de banco de dados são
fornecidas por uma terceira ferramenta, o Database
Tuning Advisor.
Query Editor


Fornece uma interface gráfica com o usuário
simples para executar consultas SQL e ver os
resultados.
Oferece, também, uma representação gráfica do
showplan, as etapas escolhidas pelo otimizador
para a execução das consultas.
Query Editor

Um administrador pode usar para:
 Analisar
consultas: O query editor pode mostrar um
plano de execução gráfico ou textual para qualquer
consulta, bem como exibir estatísticas referentes ao
tempo e recursos necessários para executar qualquer
consulta
 Formatar consultas SQL
 Usar modelos para procedimentos armazenados,
funções e instruções SQL básicas
SQL Profiler



É um utilitário gráfico que permite monitorar e
registrar atividades de BD do SQL Server.
Pode exibir todas as atividades do servidor em
tempo real, ou pode criar filtros que focalizam as
ações de determinados usuários, aplicações ou tipos
de comandos.
Pode exibir dados de desempenho indicando o
tempo que a consulta levou para ser executada,
quanta CPU e E/S foram necessárias e o plano de
execução que a consulta usou.
SQL Profiler


Permite monitorar cada instrução executada como
parte de um procedimento armazenado, cada
operação de modificação de dados, cada bloqueio
adquirido ou liberado, ou cada corrência de um
arquivo de B.D. crescendo automaticamente.
O SQL Server divide a funcionalidade de
rastreamento em 2 componentes:
 Do
cliente – o SQL Profile suporta esse rastreamento
 Do servidor – a ferramenta de rastreamento SQL
SQL Profiler
A Figura acima mostra uma sessão do profiler com o banco de dados usado no cluster
do asp.net. Ao selecionarmos um item podemos ver também o texto completo, como foi
feito para a stored procedure cs_forums_Post. Há colunas adicionais para CPU, Reads,
Writes e Duration.
Query Analyzer

Resultados do Query Analyzer
Query Analyzer


Após obter a habilidade básica para examinar e
extrair profiles de banco de dados, deve-se saber o
que acontece a seguir.
O próximo passo é examinar as consultas com o Query
Analyzer, outra ferramenta útil para qualquer
desenvolvedor que trabalha com o SQL Server. Assim
como o Profiler é útil para obter as 50,000 visões
básicas do sistema, o Query Analyzer é o microscópio
para analisar os detalhes. Com o Query Analyzer,
podemos executar consultas e stored procedures e
obter uma exibição visual do plano de execução do
SQL Server.
Query Analyzer



Da mesma forma que o Profiler, o Query Analyzer é achado na
pasta SQL Server no menu All Program. Também, será necessário
completar o Connect para o diálogo SQL Server. Uma vez
conectado, podemos passar para o nosso banco de dados,
digitando o seguinte:
use [databasename] A seguir, clicamos no botão play na barra de
menu (ou realçamos o texto e pressionamos F5). Qualquer opção
executará o SQL realçado.
Em Profiler identificamos que a stored procedure cs_Sections_Get
está lendo um volume extraordinariamente grande de dados acima de 11,000 leituras! Podemos copiar o SQL trace do Profiler
para o Query Analyzer e veremos então exatamente o que aquela
consulta em particular está fazendo.
Analisando uma consulta

Para rodar a consulta, primeiro colamos o conteúdo
em Query Analyzer e a seguir selecionamos Query
| Show Execution Plan na barra de ferramentas. Em
seguida, realçamos o SQL e pressionamos F5 para
executá-lo..
Analisando uma consulta




Logo abaixo da consulta SQL que foi executada encontramos a grade de resultados que
mostra o que foi retornado pela consulta. Neste caso foram retornados dois resultsets. O
primeiro é uma lista de Sections (forums) e o segundo é um conjunto de permissões. O
Community Server usa um sistema de permissões role-based para controlar o que os usuários
podem ou não fazer dentro do sistema. Sempre que uma lista de Sections é recuperada, o
sistema também refresca a lista de permissões para as mesmas.
No canto inferior direito do Query Analyzer vemos o texto: "5430 rows". Isto indica o número
total de linhas retornadas. Neste procedimento, havia uma falha na lógica de permissões que
faria o sistema retornar uma lista equivalente à soma do total dos roles multiplicada pelo
total de sections. No caso de forums.asp.net, há 29 roles únicos e 181 sections, o que equivale
a 5,249 linhas. Somando as 181 linhas retornadas pelo primeiro resultset teremos um total
geral de 5,430 linhas retornadas.
Obviamente são muitas linhas. Na realidade, usando o Profiler e o Query Analyzer, esta
Query particular foi otimizada para retornar menos de 250 registros - reduzindo a duração
total para menos de 100 ms.
Além de rodar consultas, o Query Analyzer nos permite analisá-las. Verificamos que a
exibição do plano de execução foi habilitada antes de executar o SQL. O plano provê um
diagrama visual de como SQL Server está executando a consulta, que índices utiliza e outros
dados que podem nos ajudar a otimizar índices ou outros dados requeridos pelo SQL Server
para aumentar o desempenho das consultas.

A Figura ao lado mostra
cada consulta executada, o
plano de execução, os
índices usados, os joins e o
volume de dados retornado
em cada operação. Até
mesmo as setas entre cada
item têm significado: a
espessura da seta é uma
indicação visual de quantos
dados foram retornados
pela operação; isto é, uma
consulta mal ajustada, teria
muitas setas grossas,
indicando operações que
estão retornando
provavelmente muitos
dados.


O Application Center Test, o SQL Server Profiler e o SQL
Server Query Analyzer são algumas das ferramentas mais
poderosas para fazer o ajuste fino do desempenho de
aplicações ASP.NET ou SQL Server. Estas ferramentas não só
deveriam fazer parte do "cinto de ferramenta" dos
desenvolvedores, como também deveriam ser usadas
habitualmente para inspecionar o desempenho global das
aplicações. Freqüentemente os desenvolvedores estão
preocupados em otimizar rotinas dentro do código, no
entanto estariam utilizando melhor seu tempo, dedicando-se
a eliminar ou otimizar comunicações cross-process, tais como
chamadas a banco de dados.
Fonte: http://msdn.microsoft.com/ptbr/library/cc580638.aspx
SQL Monitor e Performace Monitor
Fonte: http://sqlbrasil.blogspot.com/2010/02/videoaula-utilizando-sql-profiler-e-o.html