Por que eu devo ler este artigo:Otimizar consultas é um trabalho de grande relevância para todo DBA. Neste artigo, mostraremos como realizar esta tarefa nos baseando em dados estatísticos de tempo de execução, tempo de processamento, leituras físicas e de dados em cache e também gravações em tabelas.

Para facilitar a otimização, mostraremos também como realizar a leitura e interpretação dos planos de execução do SQL Server.

Sempre que analisamos dados relacionados à performance, temos em mente a otimização do ambiente. Ao analisarmos perfmons, eventos de espera ou traces, naturalmente somos levados a consultas que se destacam de forma negativa em nossas análises.

Uma vez identificadas essas consultas, a otimização se faz necessária, e junto com ela, testes e novas coletas de dados para novas ações de otimização, até que o resultado alcançado seja considerado satisfatório.

Deste modo, conseguimos reduzir cada vez mais o tempo de execução das consultas que mais consomem recursos em nossos ambientes.

Em artigos anteriores publicados na SQL Magazine, falamos de várias ferramentas que nos apoiam quando o assunto é análise de desempenho em ambientes e servidores de banco de dados e/ou aplicação.

Vimos como coletar e analisar perfmons, traces e eventos de espera, e também como relacionar os dados de duas ferramentas, quando trabalhamos com dados do perfmon importados no SQL Profiler, analisando, assim, o arquivo de trace junto com o arquivo de performance do servidor (veja os endereços dos artigos na seção Links).

Com essas informações podemos traçar o modelo de comportamento do nosso ambiente, sabendo o que é executado em determinado instante do dia e identificando padrões de consumo de recursos, tendo, deste modo, informações de picos de consumo.

Mas, e após essas informações serem coletadas e tratadas? Qual o próximo passo em um trabalho de otimização de um ambiente?

Uma vez munidos dos dados analisados, invariavelmente teremos consultas que se destacam entre as demais pelos mais diversos motivos, sejam eles tempo de execução, de processamento, número de leituras ou mesmo de acessos a uma mesma tabela.

É nesse momento que o trabalho analítico tem que ser deixado em segundo plano e as ações para melhoria precisam ser tomadas de maneira direta, pois em situações de melhoria de performance, é sempre necessário atuar no código, com foco direcionado para as consultas que se destacaram negativamente, as quais chamamos de Top Queries.

Além das ferramentas que já conhecemos, aprenderemos a identificar o que está sendo feito por trás das execuções mais custosas através de comandos simples, e também quais seriam as intervenções necessárias para que o problema seja resolvido, ou ao menos minimizado. Aprenderemos também como habilitar a coleta de um plano de execução e como ele pode nos ajudar a melhorar o desempenho do nosso ambiente.

Relembrando traces

Sempre que um comando é executado no nosso servidor de banco de dados, uma informação é registrada e pode ser acessada futuramente. Esses vestígios podem ser acessados através de views de estatística do próprio SQL Server ou então através de uma coleta do SQL Profiler, que agrupa em arquivos de trace qualquer ação que é demandada aos nossos servidores de banco de dados.

O que são traces?

Traces são os arquivos de coleta gerados pelo SQL Profiler, que agrupam as ações executadas por nosso servidor. Essas ações podem ser provenientes tanto de aplicações como de rotinas batch e até mesmo de rotinas internas de manutenção e funcionamento do SGBD.

Sempre que uma ação é executada no SQL Server, seja um login, a execução de um procedimento, ou uma instrução Transact-SQL, essa informação é registrada e se torna rastreável.

Dessa maneira é possível saber quem executou, de onde partiu, quantas e quais leituras foram feitas e qual o tempo total e de processamento de qualquer instrução executada pelo SGBD. Com informações como essas, podemos avaliar qual query está prejudicando a performance do nosso ambiente.

Como acessar essas informações?

As informações registradas estão sempre disponíveis no nosso servidor por meio de algumas views de estatística do próprio SQL Server. Porém, como as informações desses objetos têm um tempo de vida pré-determinado, ou podem se perder em caso de reinicialização do serviço, a maneira mais segura de se obter informações precisas e confiáveis do que é executado em nossos servidores é habilitando um t ...

Quer ler esse conteúdo completo? Seja um assinante e descubra as vantagens.
  • 473 Cursos
  • 10K Artigos
  • 100 DevCasts
  • 30 Projetos
  • 80 Guias
Tenha acesso completo