Estatisticas é a area de Banco de Dados mais deixada de lado, embora seja uma das  que mais afetam a performance de um Banco de dados. Não adianta ter um servidor parrudo, todos os indices criados , consultas bem escritas , se as estatisticas estiverem desatualizadas.

Isso acontece porque as estatisticas é o que indicara qual é o melhor caminho para uma consulta, qual indice utilizar, se será usado realizado um seek em determinado indice, scan ou um table scan .

Por exemplo se uma tabela tem 30 milhões de registros mas as estatisticas dizem que tem 300 mil. Uma consulta que  traga 50 mil registros será tratada totalmente diferentes nos dois casos, pois o SQL Server tem uma regra que se o resultado da consulta trouxer mais de 30% do total da tabela será realizado um table Scan , do contrário será analisado a possiblidade de utilizar algum indice. Por isso com as estatisticas  desatualizadas seria realizado um table Scan , já com a estatistica atualizada seria utilizado provavelmente um index seek.

Sempre quando tiver problema de performance verifique as estatisticas, e é claro tenha um plano de manutenção semanal para atualiza-las manualmente não confie na atualização automatica do SQL.

Checando Estatisticas

SELECT OBJECT_name(OBJECT_ID) Tabela, name AS Indice, STATS_DATE(OBJECT_ID, index_id) AS DataAtualizado
FROM sys.indexes where is_hypothetical  = 0
AND OBJECT_name(OBJECT_ID) NOT LIKE ‘sys%’ ORDER BY  OBJECT_name(OBJECT_ID)

Atualizando Estatistica

 UPDATE STATISTICS NomeTabela WITH  fullScan

Links Sobre Estatisticas
http://technet.microsoft.com/en-us/library/cc966419.aspxhttp://www.sqlskills.com/BLOGS/KIMBERLY/category/Statistics.aspx

SQL SERVER – Update Statistics are Sampled By Default

http://www.sqldev.org/transactsql/obtaining-statistics-metadata-58567.shtml

É importante verificar a fragmentação de um indice, pois isso pode indicar tanto problema na manutenção em Geral dos Bancos de Dados como problemas de Design dos Índices .

Podemos ter problemas diretos e indiretos relacionados a fragmentação de um indice.

Problemas Diretos

• Aumento de leituras, sobrecarregando os discos
  Quando um indice esta fragmentado é como se tivessemos um livro onde após a página 89 você passa a ter a página 90, assim se você quer copiar da pagina 85 a 95 você terá o trabalho extra de localizar as páginas que estão fora de ordem.
• Ordem de colunas incorreta ou FillFactor incorreto
  Normalmente deve ser criado indices colocando primeiro colunas que tem mais valores distintos, mas as vezes essa organização não satisfaz bem determinada consulta “então precisamos analisar caso a caso”.
  Campos que possuem campos como chave que são frequentemente alterados , devem utilizar um fillfactor entre 70 e 90, pois quando um registro é alterado para “continuar na mesma pagina” ele deve ter espaço para isso , se a pagina esta totalmente preenchida o registro acaba sendo colocado em outra pagina ocasionando assim a fragmentação.

Problemas Indiretos

• Estatisticas Desatualizadas
  Se o indice estão fragmentados provavelmente as estatisticas não sejam atualizadas também, pois normalmente a estatistica de um indice é atualizada automaticamente quando o SQL Server esta habilitado “mas quase nenhum DBA confia nisso … neu eu =)” , outras possibilidades é atualizando diretamente a estatistica ou com Rebuild do indice “lembre-se que reorganzine não atualiza a estatistica”.
• Plano de Execução de Consultas Inconsistente
  Com indices fragmentados e estatisticas desatualizadas provavelmente o SQL Server  não consiga gerar um plano de execução adequado para uma consulta. Isso além de gerar problema de consultas irá gerar mais IO, CPU e Memória, pois o Servidor precisara de mais recursos por não estar utilizando o melhor caminho de execução.

Com todos esses problemas que podem ser ocasionados, podemos ter um Cenário que aparentemente o Servidor necessite de mais memória, processador e CPU , mas na verdade o mesmo está com esse sintoma por estar realizando mais trabalho que ele realmente precisa fazer.

Por isso é importante analisar todos os pontos antes de decidir que decisão tomar pra solucionar um problema.

Identificando Fragmentação: http://blog.sqlauthority.com/2010/01/12/sql-server-fragmentation-detect-fragmentation-and-eliminate-fragmentation/

Quando se fala de tuning primeiro passo é coletar informações do estado atual do ambiente, um problema de perfomance pode ser simples como a criação de um indice ou complexo como mover tabelas e indices para novos discos ou trocar um raid 5 por um raid 10. Pode também ser necessárias  várias ações em conjunto.

Um ponto de partida seria responder algumas perguntas como esta abaixo:

1. A lentidão é em todas as partes do sistema?
2. A Lentidão afeta todos os sitemas que possuem Bases de Dados nesse servidor?
3. Esta lento o tempo todo ou apenas em alguns periodos do dia ou dias da semana?
4. O Servidor é dedicado para o SQL Server?
5. As bases de dados estão numa storage ou em disco no proprio servidor?
6. Quantos discos fisicos o servidor possui?Quanto de memória dedicada para o SQL Server ?
7. Qual a fragmentação dos Indices?
8. Quando ocorreu a última atualização de estatisticas?
9. Existe alguma ação que quando tomada resolve temporariamente o problema?Por quanto tempo?
10. Número de deadlocks e de Blocks?

Respondendo todas essas perguntas é um bom inicio para investigar o problema. No caso de ser um problema apenas em alguma parte especifica do sistema podemos já utilizar o profiler e focar nas tabelas especificas.

Após o questionário ser respondido começa a coleta de informações:

1. Utilizar Profiler utilizando template Tuning “adicione as colunas StartTime , CPU, reads e writes” pegando consultas acima de 1 segundo (ajuste esse número para mais ou menos dependendo do volume retornado ).
2. Utilizar o PerfMon para coletar informações de disco, processador, memoria e estatiscas do SQL Server
3. Verficar os logs do windows e sql.
4. Analisar se foram aplicadas boas praticas ao TempDB
5. Coletar informações Consultas mais pesadas (IO e  CPU)
6. Verificar Contenção  “gargalos” que podem afetar a performance Geral
7. Verificar Blocks e DeadLocks
8. Montar ambiente de teste para utilizar DTA

Nos próximos posts vou detalhar cada etapa.