Atenção: por essa edição ser muito antiga não há arquivo PDF para download.
Os artigos dessa edição estão disponíveis somente através do formato HTML.
Clique aqui para ler todos os artigos desta edição
Influenciando o otimizador de consultas Oracle baseado
Muitos desenvolvedores Oracle e DBAs estão familiarizados com a teoria básica por trás da otimização de consultas baseadas-em-custo: o otimizador usa estatísticas descrevendo o conteúdo de tabelas, colunas e índices para estimar o custo de vários planos de consulta possíveis para uma dada query e escolhe aquela com o menor custo. Na prática, o plano de consulta selecionado nem sempre é o mais rápido e pode, até mesmo, nem ser próximo do mais rápido. Tipicamente, quando isto acontece, podemos considerar o uso de “dicas” para forçar o otimizador a utilizar um plano de consulta melhor. Porém, isto requer a modificação do programa que solicitou a consulta, o que nem sempre é possível. Por esta e outras razões, muitos especialistas não recomendam o uso de “dicas” para “passar por cima” do otimizador, exceto como um meio de experimentar vários planos de consulta com o intuito de comparar os tempos de execução.
Perfis armazenados (stored outlines) também podem ser problemáticos, pois eles devem “casar” com as consultas às quais se aplicam. Mesmo pequenas mudanças no texto de uma consulta podem conduzir a um perfil não utilizável, e muitos sítios operacionais não têm disciplina suficiente nos seus processos de gerência de configuração para assegurar que o perfil irá migrar para a produção junto com a consulta. Finalmente, para criarmos um perfil, é preciso fazer com que o otimizador escolha o plano de consulta correto sem modificar a consulta - se isso fosse possível, você não estaria lendo este artigo!
Após o ajuste fino dos parâmetros optimizer_index_caching e optimizer_index_cost_adj, e a coleta de estatísticas nas tabelas do banco de dados, o que faremos se ainda existirem alguns casos em que o otimizador escolha um plano de acesso sub-otimizado? Este artigo é o primeiro de uma série que descreve algumas dessas situações, e algumas ações que podemos tomar para contorná-las antes de recorrer a “dicas”.
Cardinalidade estimada
A estimativa do otimizador em relação ao custo de um plano de consulta é derivada principalmente pelo número estimado de linhas que serão processadas a cada passo, o que é chamado de cardinalidade. Se for utilizado o comando EXPLAIN PLAN com o otimizador baseado em custo (CBO – cost based optimizer), ele irá fornecer na coluna PLAN_TABLE.CARDINALITY, a cardinalidade estimada a cada passo do plano de consulta. Este valor é baseado no fato de que melhorando a precisão da cardinalidade estimada, será incrementada a precisão do custo estimado e, portanto, será aumentada a probabilidade de que o otimizador baseado-em-custo escolherá realmente o mais rápido plano de consulta. E agora, como fazer para que as cardinalidades sejam as mais precisas possíveis?
Para estimar as cardinalidades de uma fonte de linhas específica, o otimizador deve estimar a “seletividade” dos predicados que usam essa fonte de linhas. Seletividade é a probabilidade que o predicado seja verdadeiro para qualquer linha dada (um número entre 0 e 1). Assim, se a fonte de linhas provê N linhas, e a seletividade dos predicados dessa fonte é S, então a cardinalidade estimada após a aplicação dos predicados será N*S. Para predicados que combinam duas fontes A e B, a cardinalidade estimada é NA*NB*S.
Estimativas de seletividade de predicados são baseadas em muitos fatores:
· As colunas que a consulta utiliza em seus predicados;
· A estatística de colunas, incluindo informações como o número de valores diferentes (NDV – number of distinct values) e densidade (a “densidade” é 1/NDV quando não há histograma e é derivada de uma fórmula complexa quando há histograma);
· O tipo de predicados na sua consulta, tais como comparações de igualdade, desigualdades, operações LIKE, subconsultas, etc;
...
