Minha equipe usa Oracle 11 e SQL Developer. Ultimamente, tenho confiado muito em explicar planos para tentar determinar a maneira mais eficiente de resolver vários problemas. Recentemente, um colega de trabalho apontou que o plano de explicação nem sempre é preciso para o que realmente acontece no banco de dados e que um autotrace é uma indicação melhor, pois a consulta é realmente executada nos dados.
Testando uma consulta, obtive os seguintes resultados
_________________________________
| Method | Cost |
|--------------------|----------|
| Query A Explain | 306,188 |
| Query A Autotrace | 399,131 |
| Query B Explain | 99,226 |
| Query B Autotrace | 137,661 |
|____________________|__________|
Ao utilizar o autotrace, a consulta A teve um aumento de custo de 30% e a consulta B de quase 40%. Obviamente, eu deveria estar usando a consulta b em ambos os casos, mas não entendo o que faz com que sejam diferentes.
O Autotrace no SQL Developer obtém o plano de v$sql_plan e também obtém as estatísticas de sua sessão, faz um delta de estatísticas de sessão antes e depois de executar a consulta.
O plano de explicação pergunta ao banco de dados o que ele ACHA que será o plano para sua consulta.
Seu colega de trabalho está certo, eles podem diferir muito, e é melhor você usar o AutoTrace ou nosso novo recurso no 4 e superior, onde mostramos o plano em cache (um controle suspenso no botão explicar plano os torna disponíveis).
Há uma série de coisas que podem fazer com que o plano real seja diferente do plano estimado (e se você quiser se aprofundar nas ervas daninhas, há muitas coisas que podem fazer com que métodos diferentes de produzir o plano real produzam resultados diferentes mas vou ignorar isso).
O mais simples (e mais comum) gira em torno de variáveis de ligação. Se eu fizer uma
EXPLAIN PLAN
consulta simples comoA Oracle não tem informações sobre qual valor eu posso passar,
col1
então faz uma estimativa muito genérica. Se houver 20 valores distintos, por exemplo, provavelmente ele adivinhará que a consulta precisaria acessar 5% das linhas da tabela. Se você realmente executar esta instrução e passar um valor, por outro lado, o Oracle tem muito mais informações - ele pode saber por um histograma que o valor que você passou realmente exigirá que ele acesse 7% das linhas no tabela. Se o plano de consulta real permanecer inalterado, é totalmente plausível quecost
aumente em 40%, já que a quantidade de trabalho esperada aumentou em 40%.Uma lista completa de tudo o que faz com que os detalhes de um plano de consulta estimado sejam diferentes dos detalhes de um plano de consulta real e uma explicação de como essas coisas interagem seria muito longa para este formato (principalmente porque muitos dos itens ficam muito complicados muito rapidamente). Existem situações em que as estatísticas de um objeto estão ausentes, por exemplo, onde o otimizador precisa fazer uma amostra aleatória dos dados para inferir as estatísticas em tempo de compilação que serão um pouco diferentes toda vez que a consulta for compilada. Existem várias situações em que o otimizador tem algum tipo de mecanismo de feedback que entra em ação quando uma consulta está sendo executada, o que não ocorre quando um plano de consulta está sendo estimado -- ele pode escolher um grau de paralelismo com base nos recursos disponíveis , pode alterar o custo de uma classificação, dependendo de quanto espaço PGA pode obter, dependendo da versão, pode mudar de curso se uma operação recuperar substancialmente mais ou menos dados do que o esperado. Existem efeitos para os planos sendo armazenados em cache ou diferentes tecnologias que tentam garantir a estabilidade do plano quando as consultas são realmente compiladas.