Básico: Performance e otimização

[Tinho]

Boa tarde.

Estou com problema de performance em algumas querys relatada pelo DBA e estou tentando me virar com o que tenho e com o pouco que sei. Utilizo o TOAD e nesta ferramenta possui uma funcionalidade chamada "SQL Tunning" onde por meio de estatísticas é criado uma série de cenários possíveis de sugestões para o otimizador do Oracle.

Portanto gostaria da opinião de vocês, colegas mais experientes, para ver se o que eu estou fazendo é válido ou é indiferente. O que eu faço, eu pego a query problemática e executo a ferramenta (SQL Tunning), após a conclusão de análise do TOAD eu rodo o "Explain Plan" e faço uma comparação de Bytes e Cost retornado, se a diferença for significativa eu troco e depois comparo as mudanças efetuada afim de tentar aprender alguma coisa. É bem tosco isso, eu sei, mas tenho que começar de algum lugar, arriscar...

A minha maior dificuldade é de interpretação, pois para mim tanto faz tanto fez o custo ser de 1000 ou 100, pois não passam de números. Por isso eu gostaria de saber o critério de avaliação do custo,o que significa, quando ele é considerado alto ou não? Quais parâmetros eu uso para me basear? Será que eu reduzindo o custo realmente acabo ganhando em performance?

Grato e atenciosamente.

[dr_gori]

Com certeza o CUSTO menor é mais rapido. Ele não é uma medida de TEMPO, e sim é de comparação. (entre todos custos).

Veja alguns links sobre tuning que talvez possam te ajudar.
http://glufke.net/oracle/viewtopic.php?t=5519
http://glufke.net/oracle/viewtopic.php?t=4325
http://glufke.net/oracle/viewtopic.php?t=3802
http://glufke.net/oracle/viewtopic.php?t=4899

[Tinho]

Obrigado, com certeza vou dar uma estudada nos links e vai ser de grande valia.

O custo está baseado na quantidade de dados trazidos dentro de uma query? O método que estou usando para avaliar a performance de uma query é válido?

At.

[fsitja]

Bom, vamos meter a mão dentro do vespeiro.

Quando se fala em performance tuning o ideal é começar a abordagem de cima para baixo (o famoso top-down): primeiro entender exatamente o que o SQL está tentando obter e como seu resultado é utilizado.

E mais que isso: qual o resultado que o processo como um todo está realizando ao seu final. O motivo é simples: muitas vezes o maior gargalo não está em um único SQL, mas na forma como vários selects e procedimentos PL/SQL estão encadeados de maneira arquiteturalmente sub-ótima. Nesse aspecto, uma excelente referência é o "mantra" do Tom Kyte, que diz o seguinte:

* You should do it in a single SQL statement if at all possible.
* If you cannot do it in a single SQL Statement, then do it in PL/SQL.
* If you cannot do it in PL/SQL, try a Java Stored Procedure.
* If you cannot do it in Java, do it in a C external procedure.
* If you cannot do it in a C external routine, you might want to seriously think about why it is you need to do it…

think in sets...

learn all there is to learn about SQL...

Seguir essas regras é o primeiro passo. Evite PL/SQL, evite procedures e functions encadeadas. Faça tudo num só SQL. Aí entramos no "como" da questão.

Aprendendo mais e mais sobre SQL. Qual a melhor forma arrancar os dados que você precisa de dentro do banco de dados.
Eventualmente o modelo de dados ou a complexidade do problema vai colocar desafios de desempenho à sua frente. Aí entram as ferramentas de tuning.

A melhor forma de resolvê-los é começar olhando o plano de execução. É imprescindível entender qual seria teoricamente o plano de acesso ideal e o motivo. Uma pegadinha existe no plano de acessos: comparar o custo no plano de um SQL com o custo de outro SQL pode não significar muito. O custo é usado para um determinado SQL pelo Oracle para escolher a melhor forma de chegar aos seus dados. Ele traça os planos de acesso para um SQL e opta por aquele com menor custo.
Leia a referência:
http://asktom.oracle.com/pls/asktom/f?p ... 0346648193

De forma simplificada, os recursos que você dispõe e que você quer precisa otimizar num SQL para melhorar seu desempenho são os volumes de I/O realizado e o tráfego de rede. Isso você consegue usando trace, através do TKPROF, e de timed statistics.

O trace registra tudo que ocorre no banco de dados detalhadamente num arquivo e o TKPROF torna esse emaranhado de dados algo legível e compreensível por um analista trabalhando para otimizar o procedimento.
Seu objetivo em geral é diminuir os "consistent gets", que são leituras a disco no servidor. Eles são os grandes vilões quando se usa banco de dados.

Recomendo a você ler a documentação sobre SQL Tracing, TKPROF e, mais tarde, timed statistics, além de muita coisa sobre SQL (SQL analítico, funções built-in do Oracle, queries hierárquicas com connect by e tudo o mais no ritmo que você puder digerir).

Link: http://tkyte.blogspot.com/2006/10/slow-by-slow.html

Livro de performance tuning da Oracle:
http://download.oracle.com/docs/cd/E118 ... 21/toc.htm

Tópico sobre tuning de SQL:
http://asktom.oracle.com/pls/asktom/f?p ... 4517459743[/b]