Aprendendo a otimizar consultas SQL e entender os planos de execução - recursos?

Eu me pego escrevendo mais e mais consultas SQL no trabalho (principalmente Oracle 11g, mas algumas SQL Server 2005-2008) e comecei a criar visualizações bastante complexas para o restante da equipe de analistas.

Todos correm muito bem, mas alguns nem tanto. Assim...

• Como aprendo a ajustar minhas consultas?
• Preciso aprender a ler / agir sobre os planos de execução?

E...

• Quais livros / sites você pode recomendar para aprender sobre o ajuste de consultas SQL 1) em geral 2) especificamente para o Oracle 11g?

Temos alguns DBAs bons aqui, mas eles são muito pequenos para nos ajudar a ajustar todas as consultas que escrevemos.

A maioria dos livros que encontrei no Amazon for Oracle parece estar voltada para a otimização geral do banco de dados e / ou foi escrita 8 a 10 anos atrás.

Obrigado por seus conselhos :)

Eu diria que aprender a entender os planos de explicação é uma habilidade vital para ajudar você a otimizar as instruções SQL. Encontrei o livro de Christian Antognini, Troubleshooting Oracle Performance , muito útil para detalhar como eles funcionam, além de explicar como abordar a otimização do banco de dados. Com alguns anos, você ainda aprenderá muito que ainda é relevante.

Se você for mais avançado, poderá ler os livros de Jonathan Lewis, mas estes são mais detalhados, provavelmente não um bom ponto de partida. O Oracle Fundamentals baseado em custos é bastante antigo agora, mas grande parte ainda é relevante. Ainda não li o Oracle Core: Internals essenciais para solução de problemas , mas ele recebeu boas críticas da comunidade Oracle.

Como você está no 11g, se você tiver consultas que demoram mais do que alguns segundos, eu recomendaria definitivamente olhar o monitor SQL em tempo real (supondo que você esteja devidamente licenciado). Como o nome sugere, mostra o progresso de uma instrução SQL em tempo real, detalhando quanto tempo cada operação levou com detalhes de linhas buscadas até o momento. Ele também mantém os detalhes das consultas executadas recentemente por um tempo, para que você possa ver como suas alterações afetam uma instrução.

Documentação do Oracle SQL Monitoring: http://docs.oracle.com/cd/E11882_01/server.112/e16638/instance_tune.htm#PFGRF94543

Aprender a ajustar as consultas é algo que levará tempo e prática. Algumas coisas que aprendi:

• Escreva consultas para buscar o menor número possível de linhas o mais rápido possível (por exemplo, você não deseja varrer completamente uma tabela de 10 milhões de linhas se precisar apenas de 100 linhas)
• Verifique se o número de linhas esperado em cada etapa de um plano de explicação (esperado) corresponde àquelas retornadas no plano de execução real. Quando essas ordens são de magnitude diferente, é provável que o otimizador não esteja escolhendo o "melhor" plano.
• Entenda os princípios da boa indexação: como eles funcionam e quando devem / não devem ser usados ​​ao executar uma consulta ( Richard Foote tem um blog muito detalhado discutindo índices no Oracle)

Você aprenderá principalmente escrevendo consultas, examinando os planos de explicação (esperados) e comparando-os com os planos de execução reais (rastreando a consulta ou usando o monitor SQL). Em seguida, reescreva a consulta, adicione / remova índices etc. e veja como isso afeta os planos e os tempos de execução

Como você está procurando informações específicas da Oracle, eu recomendaria o blog Ask Tom na Oracle. Em geral, acho que você encontrará o conselho para não ajustar a consulta. Você receberá bons conselhos sobre como escrever uma consulta que o otimizador pode otimizar. A documentação do Oracle também está online , e eu geralmente procuro informações atualizadas sobre o Oracle. Como não trabalhei com o SQLServer, não tenho recomendações.

Não tenho visto muitas novidades no campo da otimização de consultas nos últimos anos. A grande mudança é a descontinuação do otimizador baseado em regras, com o qual mal consigo me lembrar de trabalhar. No entanto, eu entendo que o SQLServer ainda usa um otimizador baseado em regras, portanto, entender suas regras pode ajudar.

Uma ferramenta na qual você pode editar uma consulta, executá-la e gerar um plano de explicação ajuda a entender quais alterações oferecem uma consulta com bom desempenho. Eu tive bons resultados com o AquaData Studio e realmente gosto da visualização em árvore. O desenvolvedor SQL deve fazer o mesmo.

Como em qualquer otimização, você precisa ter dados quantitativos sobre seu desempenho. Em seguida, você pode determinar se realmente o otimizou.

Como otimizar uma consulta depende, em parte, de como o analisador cria e otimiza a consulta. Em maior medida, depende da distribuição dos dados que você está consultando. Em um banco de dados Oracle, se o conjunto de resultados compõe quatro por cento ou mais de uma tabela e é distribuído aleatoriamente, uma varredura de tabela geralmente é mais rápida que um índice.

Eu trabalhei para otimizar consultas para uma equipe de desenvolvedores. Apenas duas ou três consultas por ano exigiam uma otimização séria. A maioria das consultas é simples o suficiente para não precisar de otimização. O restante geralmente pode ser tratado adicionando caminhos de junção ausentes.

Para o Oracle, existem três configurações ajustáveis ​​que podem afetar significativamente o desempenho. O custo para pesquisas de índice e dados interage para alterar as condições sob as quais um índice no será ou não será usado. Esses dois podem ser ajustados por sessão. Os padrões geralmente não são ideais. O outro valor controla quantas alternativas o otimizador tentará. Aumentar esse valor geralmente ajuda.

A otimização é significativamente impactada pela distribuição e volume de dados. Ao otimizar, é melhor usar uma cópia do banco de dados de produção ou pelo menos um banco de dados com a mesma distribuição e volumes de dados. Eu quebrei severamente o ambiente de teste, otimizando uma consulta para o banco de dados de ordem de produção. Os bancos de dados de teste e desenvolvimento tinham distribuição de dados significativamente diferente, o que causava falha na consulta, mesmo com significativamente menos dados.