DevMedia - asp.net, Java, Delphi, SQL e web Design, tudo em um só lugar!
Bem vindo a DevMedia!
LOGIN:     SENHA:
 
 

  Este é um post disponível para assinantes MVP
Este post também está disponível para assinantes da SQL Magazine DIGITAL
ou para quem possui Créditos DevMedia.  Clique aqui para saber mais!

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

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

[fechar]

Você não gostou da qualidade deste conteúdo?

(opcional) Você gostaria de comentar o que não lhe agradou?

 

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)
"

A exibição deste artigo foi interrompida.

  Este é um post disponível para assinantes MVP
Este post também está disponível para assinantes da SQL Magazine DIGITAL
ou para quem possui Créditos DevMedia.  Clique aqui para saber mais!


Equipe Devmedia
Noticias/Dicas/Artigos publicados.
O que você achou deste post?

    0 COMENTÁRIO

[Fechar]

Este post é fechado - você precisa ter acesso ao post para incluir um comentário.


Nenhum comentário foi postado - seja o primeiro a comentar!
Cursos relacionados
Publicidade
[Fechar]

Você precisa estar logado para dar um feedback.

Clique aqui para efetuar o login
[Fechar]


Este post está fechado. Saiba mais sobre a assinatura MVP!
web-03
DevMedia  |  Anuncie  |  Fale conosco
Hospedagem web por Porta 80 Web Hosting
2013 - Todos os Direitos Reservados a web-03