Artigo SQL Magazine 20 - Influenciando o otimizador de consulta baseadoem custo do Oracle - Parte II

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (0)  (0)

Artigo da Revista SQL Magazine - Edição 20.

 

capaSQL20.JPG

 

Clique aqui para ler todos os artigos desta edição

 

Influenciando o otimizador de consulta baseado em custo do Oracle - Parte 2

Glenn Goodrum 

Leitura obrigatória: SQL Magazine 18, Influenciando o otimizador de consulta baseado em custo do Oracle - Parte 1.

 

O artigo anterior desta série introduziu o ajuste de estatísticas para ajudar o otimizador baseado em custo do Oracle a computar as estimativas de cardinalidade que mais se aproximam da realidade. Fazendo isto, aumentamos a probabilidade do otimizador realmente escolher o plano de consulta mais eficiente. Este artigo continua a discussão com outro exemplo.

Quando uma consulta une duas tabelas através de um equi-join simples (A.COLUMN = B.COLUMN), o otimizador assume que os valores possíveis de uma coluna são distribuídos uniformemente. Em outras palavras, assume que qualquer valor de uma coluna vai, em média, casar com o mesmo número de linhas, ou seja, se um determinado valor para a tabela A.COLUMN retornar X linhas relacionadas em B.COLUMN, outro valor para A.COLUMN retornará o mesmo número de X linhas relacionadas em B.COLUMN. E se soubermos que nossa consulta usará um valor de uma coluna que acontece bem menos que a média? Um histograma não resolverá, porque o otimizador não tem meios de saber que os valores de junção em tempo de execução serão relativamente raros. 

Exemplo

Este exemplo é uma extensão daquele usado no artigo anterior. Aqui, adicionamos uma tabela de look-up que define ciclos de remessa, onde os ciclos ou são sinalizados como "rotineiro" ou "não rotineiro”. Nos dados de teste, criamos deliberadamente só alguns ciclos de remessa do tipo "não rotineiro” e, mais importante, há muito menos ordens em um ciclo de remessa não rotineiro que em um rotineiro. Computamos estatísticas com 100% de amostragem, além de acrescentarmos histogramas a todas as colunas com distribuições distorcidas. 

A consulta de teste só está relacionada a ciclos de remessa do tipo "não rotineiro", portanto, já sabemos que a junção de SHIP_CYCLE com ORD usará IDs de ciclo que acontecem menos freqüentemente que a média em ORD (ver Listagem 1). 

select *

from    customer c

join     ord o           on (o.cust_id = c.cust_id)
join     ship_cycle sc   on (o.cycle_id = sc.cycle_id)
join     line_item li    on (o.order_num = li.order_num)
join"

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?