monografia otimizadores - carlos e. gorges - final · carlos eduardo gorges processamento e...
TRANSCRIPT
PONTIFCIA UNIVERSIDADE CATLICA DO PARAN CENTRO DE CINCIAS EXATAS E DE TECNOLOGIA
ESPECIALIZAO EM ADMINISTRAO DE BANCO DE DADOS
PROCESSAMENTO E OTIMIZAO DE CONSULTAS EM GERENCIADORES DE BANCO DE DADOS RELACIONAIS
Curitiba Julho/2008
CARLOS EDUARDO GORGES
PROCESSAMENTO E OTIMIZAO DE CONSULTAS EM GERENCIADORES DE BANCO DE DADOS RELACIONAIS
Projeto de concluso do curso de Especializao em Administrao de Banco de Dados da Pontifcia Universidade Catlica do Paran, Centro de Cincias Exatas e Tecnologia, sob a orientao do Professor Attilio Zanelatto Neto.
Curitiba Julho/2008
iii
Resumo
No h dvidas que o otimizador um dos componentes principais de um SGBD. Sua
principal tarefa escolher uma estratgia para resolver uma consulta relacional utilizando o
menor consumo computacional possvel. Sua evoluo baseia-se em retirar do usurio a
totalidade dessa responsabilidade objetivando a mitigao de erros e melhor eficcia,
tornando-o cada vez mais automatizado, complexo e importante. Desta forma, o objetivo
deste trabalho criar um material de referncia sobre o processamento de consultas em
SGBDs com foco na fase de otimizao, gerando um comparativo entre os mtodos de
otimizao abordados. O otimizador faz parte do conjunto de tarefas que o SGBD precisa
realizar para que a consulta requisitada seja executada e o resultado seja devolvido para o
usurio. Esse conjunto de tarefas chamado de processamento de uma consulta e ela
dividida em vrias etapas com suas respectivas responsabilidades. Os mtodos de otimizao
so as formas como a problemtica de otimizao podem ser resolvidas no processamento de
uma consulta. Os dois mtodos mais comuns utilizados para a otimizao de consulta em
SGBDS so: o baseado em regras heursticas, tambm conhecido como otimizador por regra,
e o baseado em estimativa de custo, tambm conhecido como otimizador por custo. O
resultado desses otimizadores o plano de execuo, que corresponde a uma seqncia de
etapas empregadas no processo de execuo de uma consulta.
Palavras-chave: SGBD, Otimizador, processamento de consultas SQL.
iv
Lista de Figuras FIGURA 1 ESTRUTURA DO PROCESSAMENTO DE CONSULTAS................................................................................. 3
FIGURA 2 INFORMAES DO PLANO DE EXECUO GERADO POR CUSTO ............................................................ 7
FIGURA 3 INFORMAES DO PLANO DE EXECUO GERADO POR REGRA............................................................ 7
FIGURA 4 LGICA DA JUNO POR ITERAO SIMPLES....................................................................................... 12
FIGURA 5 REGRAS E PRIORIDADES DO OTIMIZADOR POR REGRA NO SGBD ORACLE........................................... 16
FIGURA 6 - INDEX SKIP SCAN: DIAGRAMA E-R DA TABELA USADA PARA O TESTE.................................................. 20
FIGURA 7 INDEX SKIP SCAN: GRFICO COMPARATIVO DE LEITURAS REGRA VERSUS CUSTO............................ 21
FIGURA 8 INDEX SKIP SCAN: GRFICO COMPARATIVO DE TEMPO REGRA VERSUS CUSTO ................................ 21
FIGURA 9 HASH JOIN: DIAGRAMA E-R DAS TABELAS USADAS PARA O TESTE...................................................... 22
FIGURA 10 HASH JOIN: GRFICO COMPARATIVO DE LEITURAS REGRA VERSUS CUSTO .................................... 23
FIGURA 11 HASH JOIN: GRFICO COMPARATIVO DE TEMPO REGRA VERSUS CUSTO ........................................ 24
FIGURA 12 HISTOGRAMA: DIAGRAMA E-R DA TABELA USADA PARA O TESTE..................................................... 25
FIGURA 13 HISTOGRAMA: DISTRIBUIO DOS DADOS NA COLUNA VALUE........................................................ 25
FIGURA 14 HISTOGRAMA: GRFICO COMPARATIVO DE LEITURAS REGRA VERSUS CUSTO ............................... 27
FIGURA 15 HISTOGRAMA: GRFICO COMPARATIVO DE TEMPO REGRA VERSUS CUSTO.................................... 27
v
Lista de siglas e abreviaturas
1. SGBD (Sistema de Gerenciamento de Bancos de Dados) Sistema responsvel pelo
armazenamento, organizao, gerenciamento das bases de dados e pela garantia da
consistncia dos mesmos;
2. SGBDR (Sistema de Gerenciamento de Banco de Dados Relacional) SGBD onde os
dados so representados em linhas e colunas, baseado no modelo relacional de dados;
3. SGBD Oracle Produto desenvolvido pela empresa norte americana Oracle Corporation;
4. SQL Structured query language (linguagem de consulta estruturada) a linguagem de
pesquisa declarativa utilizada nos SGBD atuais;
5. Predicados valores aplicados nos filtros das consultas;
vi
SUMRIO
Resumo .....................................................................................................................................iii
Lista de Figuras ......................................................................................................................... iv
Lista de siglas e abreviaturas......................................................................................................v
SUMRIO.................................................................................................................................vi
1. Introduo...........................................................................................................................1
2. Desenvolvimento................................................................................................................2
2.1. Processamento de uma consulta .................................................................................2
2.1.1. Etapas do processamento....................................................................................2
2.1.1.1. Anlise lxica, sinttica e semntica (parse) ..............................................3
2.1.1.2. Otimizador de consultas .............................................................................4
2.1.1.3. Parse completo e parse parcial....................................................................5
2.1.1.4. Gerador de cdigo e processador (execute/fetch).......................................6
2.1.2. Plano de execuo ..............................................................................................6
2.1.2.1. Informaes relevantes ...............................................................................7
2.1.2.2. Mtodos de acesso......................................................................................9
2.1.2.3. Mtodos de unio .....................................................................................11
2.1.2.4. Ordem de unio ........................................................................................13
2.1.2.5. Operaes especficas...............................................................................13
2.1.3. Mtodos de otimizao.....................................................................................14
2.1.3.1. Otimizao por regra ................................................................................14
2.1.3.2. Otimizao por custo................................................................................16
2.1.3.2.1. Parmetros .............................................................................................17
2.1.3.2.2. Estatsticas .............................................................................................18
2.1.3.2.3. Modificadores (hints) ............................................................................18
2.1.4. Custo versus regra ............................................................................................19
3. Concluso .........................................................................................................................29
4. Referncias bibliogrficas ................................................................................................30
1
1. Introduo
O objetivo dos otimizadores de consulta claro: escolher uma estratgia para resolver
uma consulta relacional utilizando o menor consumo computacional possvel. Sua evoluo
baseia-se em retirar do usurio a totalidade dessa responsabilidade objetivando a mitigao de
erros e melhor eficcia, tornando-o cada vez mais automatizado, complexo e importante em
relao aos demais componentes de um SGBD.
Dada a importncia dos otimizadores no cenrio dos SGBDs, e ao fato de que,
atualmente, existe uma grande quantidade de profissionais trabalhando nessa rea sem o
conhecimento adequado no assunto abordado. A proposta desse trabalho criar um material
de referncia sobre o processamento de consultas em SGBDs com foco na fase de otimizao,
gerando comparativos dos mtodos de otimizao abordados.
2
2. Desenvolvimento
Quando se submete uma consulta SQL para um SGBD, se informam os resultados que
se pretende obter, mas no necessariamente o melhor caminho para faz-lo. O responsvel por
escolher a estratgia mais eficiente para o processamento dessas consultas o componente
dos SGBD conhecido como otimizador, que um algoritmo (modelo matemtico) que
transforma a consulta com o objetivo de minimizar o tempo e o custo computacional da sua
execuo.
Suas principais decises so:
Qual algoritmo e abordagem de otimizao aplicar, quando h mais de uma disponvel;
Se, e como, transformar os comandos da consulta;
Decidir o mtodo de acesso a cada tabela;
Decidir a ordem de unio das tabelas;
Decidir o mtodo de unio das tabelas;
Decidir como executar os operadores;
Essas decises so baseadas em:
Conjunto de regras;
Estatsticas;
Parmetros;
Modificadores (Hints);
Informaes no dicionrio de dados;
Predicados (filtros);
2.1. Processamento de uma consulta
O otimizador faz parte de um conjunto de tarefas que o SGBD precisa efetuar para que
cada consulta requisitada pelo usurio seja executada e o resultado seja devolvido. Esse
conjunto de tarefas chamado de processamento de uma consulta e ela dividida em vrias
etapas com suas respectivas responsabilidades.
2.1.1. Etapas do processamento
As etapas que compreendem o processamento de uma consulta esto no diagrama
encontrado na figura 1 (LAHDENMAKI, 2005);
3
Figura 1 Estrutura do processamento de consultas
2.1.1.1. Anlise lxica, sinttica e semntica (parse)
Esta a primeira fase de processamento da consulta submetida pelo usurio. Sua
responsabilidade montar, a partir do texto da consulta SQL, uma representao interna da
consulta em uma forma estruturada, chamada rvore de consulta, j com as validaes
necessrias efetuadas. Ela dividida em:
Anlise lxica (alfabeto) e sinttica (gramtica):
Nestas fases, o texto da consulta validado gramaticalmente e separado em uma
estrutura de acordo com o alfabeto da linguagem SQL do SGBD em questo. Consultas mal
formadas, geralmente, ocasionam erro nessas fases.
Anlise semntica (validao):
Nesta fase, os objetos encontrados na estrutura gerada so validados. Por exemplo,
verificado se as tabelas referenciadas na consulta existem e se o usurio tem permisso para
acessa-ls.
4
2.1.1.2. Otimizador de consultas
A fase de otimizao tm como objetivo escolher uma estratgia, entre as vrias
possveis, para recuperao dos resultados a partir da rvore de consulta. Os dois algoritmos
mais comuns usados para a otimizao de consulta em SGBDS so: o baseado em regras
heursticas, tambm conhecido como otimizador por regra, e o baseado em estimativa de
custo, tambm conhecido como otimizador por custo. A estratgia de execuo tambm
chamada de plano de execuo ou plano de acesso. Essa fase dividida em:
Transformao da consulta:
A transformao da consulta altera a rvore de consulta com o objetivo de gerar de uma
consulta equivalente mais eficiente, gerando assim um plano de execuo melhor na fase de
otimizao. As quatro principais tcnicas de transformao so:
Agrupamento das vises
Sabendo que as vises so tratadas como consultas separadas do bloco da consulta
principal, esta fase busca reescrever a consulta unindo a consulta do corpo da viso com o
bloco da consulta principal, possibilitando a otimizao conjunta das consultas e
disponibilizando mais uma opo para o otimizador.
Recuperao de predicados
Para cada viso no agrupada, essa fase se encarregar de avaliar os predicados da
consulta principal, e procurar aplic-los diretamente na viso. Essa tcnica melhora os sub-
planos das vises, pois permitem, por exemplo, que esses predicados sejam usados para um
acesso via ndice ou como simples operao de filtro;
Remoo de sub-consultas
Assim como as vises, as sub-consultas so tratadas separadamente da consulta
principal. Esta fase busca unir as sub-consultas no bloco da consulta principal, transformando
5
esta consulta aninhada em uma juno da consulta principal, disponibilizando mais uma
opo para o otimizador.
Reescrita da consulta utilizando vises materializadas
Sabendo que uma viso materializada similar a uma consulta armazenada em uma
tabela, quando o transformador de consultas encontra uma consulta compatvel com uma
viso materializada, ele reescreve a consulta utilizando essa viso. Isto apresenta ganhos de
desempenho, uma vez que parte do resultado j est previamente processado, dispensando a
necessidade de execut-lo novamente.
Escolha do algoritmo de otimizao:
Alguns SGBDs dispem de mais de um algoritmo e abordagem de otimizao. nesta
fase que um dos algoritmos e abordagem escolhido de acordo com as regras do SGBD
usado.
Execuo do algoritmo e abordagem de otimizao:
Nesta fase definida, de acordo com o algoritmo e abordagem escolhidos, qual
estratgia de processamento para a consulta que ser usada. Sempre que essa fase
necessria, o processo chamado de parse completo (hard parse) e seu resultado o plano de
execuo escolhido.
Cach dos planos de execuo:
A fase de otimizao exige certa quantidade de recursos computacionais, principalmente
quando o algoritmo utilizado baseado em estimativa de custo. Desta forma, nesta ltima
fase, o plano de execuo guardado para posterior reutilizao.
2.1.1.3. Parse completo e parse parcial
Como a maioria dos produtos de SGBDs considera que a fase de otimizao faz parte do
parse (junto com a anlise lxica, semntica e sinttica), vrias literaturas (GREEN, 2002)
6
(POWELL, 2003) definem o conceito de parse completo (hard parse) e parse parcial (soft
parse). O parse parcial ocorre quando um plano de execuo previamente gerado reutilizado
no processamento da consulta. O parse completo ocorre quando necessria a chamada do
algoritmo de otimizao para a gerao do plano de execuo. O objetivo do reuso diminuir
o impacto dos recursos computacionais necessrios para todo o processamento da consulta e
cada produto contm uma soluo para resolver este problema. No SGBD Oracle existe um
conceito de variveis bind, que funcionam como predicados dinmicos, e variveis literais,
que so predicados estticos. A definio do tipo do predicado feita pelo usurio na
chamada da consulta. Os planos previamente gerados so reutilizados quando a consulta
submetida equivalente a original, onde somente o valor dos predicados definidos como bind
mudem. Os planos de execuo guardados para reuso so gerados com os predicados usados
da primeira execuo da consulta, processo chamado bind variable peeking. No SGBD
Oracle ainda existe outra forma para forar o reuso de planos de execuo: as variaes
SIMILAR e FORCE do parmetro de configurao do compartilhamento de cursores
(cursor_sharing). Ambas as opes buscam transformar automaticamente as consultas
submetidas com predicados do tipo literal em consultas com predicados do tipo bind. A
diferena entre o SIMILAR e o FORCE que no primeiro caso h regras no
documentadas para a definio de quais predicados devem ser convertidos, e no segundo caso
ele sempre ir efetuar a converso. Essa diferena crucial para a performance da execuo
das consultas, pois um plano de execuo gerado com certos predicados em muitos casos no
o ideal para outras combinaes desses predicados.
2.1.1.4. Gerador de cdigo e processador (execute/fetch)
O objetivo do gerador de cdigo e processador executar o plano de execuo gerado
nas fases anteriores do processamento da consulta e retornar, gradativamente, as linhas que
compem o resultado para o usurio.
2.1.2. Plano de execuo
O plano de execuo a estratgia escolhida pelo algoritimo e abordagem de otimizao
adotados pelo SGBD para a execuo da consulta. O plano de execues formado por um
grupo estruturado e ordenado de instrues que informam ao SGBD, passo a passo, como a
consulta deve ser executada.
7
2.1.2.1. Informaes relevantes
De acordo com o SGBD e otimizador que gerou o plano, algumas informaes
relevantes so apresentadas. As figuras 2 e 3 demonstram a decomposio dessas informaes
no SGBD Oracle 10g. Na decomposio apresentada esto s colunas com as informaes
relevantes dentro do plano. Apesar de a decomposio estar apresentada em colunas, o plano
lido linha a linha, da operao aninhada com maior identao para a menor, na ordem de
cima para baixo quando houver operaes no mesmo nvel.
Figura 2 Informaes do plano de execuo gerado por CUSTO
Figura 3 Informaes do plano de execuo gerado por REGRA
As informaes mais importantes encontradas nos planos de execuo so as seguintes:
Modo do otimizador
Como o otimizador escolhe o algoritmo e abordagem de otimizao, quando h mais de
um disponvel, o plano de execuo ser influenciado por esta desciso j que ele o
resultado dessa escolha. Dependendo do SGBD e da ferramenta de gerao do plano de
execuo, o modo do otimizador encontrado como uma informao auxiliar no plano. No
8
exemplo acima precisamos analisar o plano para verificar o modo do otimizador: no
otimizador por custo as estimativas esto presentes.
Operaes aninhadas
As operaes mostram, de forma aninhada, os mtodos de acesso, ordem de unio,
mtodos de unio e operadores escolhidos pelo algoritmo do otimizador.
Nome dos objetos envolvidos em cada passo
So as fontes de dados acessadas por todo o plano: podem ser ndices, tabelas, parties,
vises, acessos remotos a outros bancos e muitos outros. Cada fonte de dados acessada a
partir de uma operao, que no exemplo das figuras 2 e 3 encontrada na mesma linha, na
coluna operaes aninhandas.
Uso estimado de espao temporrio necessrio
a estimativa de uso de espao temporrio em meio fsico (disco, storage, etc), para
operaes de agrupamento e ordenao, calculadas pelo otimizador por custo.
Tempo estimado para execuo de cada operao
o tempo estimado pelo otimizador por custo para execuo de cada operao.
Custo (cost)
O custo estimado pelo otimizador por custo uma unidade que procura demonstrar o
quanto cada operao consumir em recursos. A lgica de clculo desse valor no
documentada e muda de acordo com as verses dos SGBDs.
Uso de CPU estimado em cada operao
a porcentagem de uso de CPU estimado pelo otimizador por custo.
9
Nmero de linhas estimadas em cada passo (cardinalidade)
A cardinalidade representa o nmero de linhas em uma tabela ou o nmero de linhas
distintas retornadas por um ndice. A cardinalidade de uma consulta o nmero de linhas
estimada do resultado.
Nmero de bytes estimados em cada passo (volume de dados em bytes)
O volume de dados o tamanho estimado, em bytes, dos dados a serem manipulados em
cada operao. O calculo baseado na cardinalidade multiplicada pelo tamanho mdio da
linha da tabela coletada nas estatsticas.
2.1.2.2. Mtodos de acesso
Os mtodos de acesso so os modos com que os dados so obtidos de uma tabela em
uma base de dados. Em geral, o acesso via ndice deve ser usado para recuperao de uma
quantidade pequena de dados de uma tabela enquanto a leitura completa mais eficiente na
recuperao de uma quantidade grande de dados. O acesso direto a forma mais simples e
rpida de acesso a uma linha. Esses trs principais mtodos esto descritos abaixo:
Leitura total da tabela:
A consulta ir ler todas as linhas e filtrar o resultado de acordo com os predicados
aplicados na consulta. Essa forma de leitura utiliza requisies multi-bloco em disco, que
normalmente so mais rpidas que requisies de bloco simples.
10
ndice b-tree
Os acessos por ndices, que so estruturas auxiliares as tabelas, permite pesquisas
rpidas por pequenas fraes de uma tabela, como uma linha. Ele formado por uma estrutura
em forma de rvore, onde os valores da pesquisa ficam em seus galhos e os endereos das
linhas na tabela ficam nas folhas. Aps a pesquisa nos galhos pelo predicado da consulta, os
endereos de acesso direto das linhas so retornados e usados para acessar a tabela. Esse tipo
de acesso direto utiliza requisies por bloco simples em disco, que normalmente so lentas.
Existem vrias variaes de acessos via ndice, as principais so as seguintes:
Index-unique scan
A pesquisa efetuada em um ndice que no contm valores repetidos,,
permitindo que a consulta termine logo que a primeira ocorrncia do valor seja
achada. usado, por exemplo, em consultas com predicados em colunas com
valores nicos, como o CPF de uma pessoa.
Index-range scan
Esse tipo de acesso ocorre em consultas onde os predicados so intervalos de
valores ou quando os campos do ndice no contm valores nicos. A pesquisa
efetuada com predicado de menor valor e, com a primeira folha resultado, a
pesquisa continua na lista ordenada (duplamente ligada) at que o maior valor seja
encontrado. usado, por exemplo, na pesquisa de pessoas com idade entre 10 e 20
anos.
Index-skip scan
A pesquisa efetuada nos galhos de um sub-nvel do ndice. Isto possvel
efetuando vrias sub-consultas, uma para cada galho dos nveis anteriores, atraz do
valor pesquisado. usado quando o predicado aplicado em colunas que somente
esto includas a partir da segunda posio de ndices e a leitura completa da tabela
muito custosa.
11
Index full scan
A pesquisa feita lendo toda a lista ordenada (duplamente ligada) do ndice,
permitindo um resultado j ordenado. Normalmente usado quando todos os valores
de uma coluna presente no ndice esto sendo requisitados ordenadamente.
Index fast full scan
A pesquisa feita lendo todos os blocos do ndice desordenadamente, como o
ndice est armazenado. Usado para evitar a leitura completa da tabela quando
todos os campos envolvidos na consulta esto no ndice e no so nulos.
Acesso direto (ROWID)
O acesso direto a uma linha varia de acordo com o SGBD, mas em geral sua
representao uma unio do identificador do arquivo, endereo do bloco e linha da tabela.
Na maioria dos SGBDs esse endereo tratado internamente, sem que o usurio tenha acesso
a ele (como por exemplo, nas folhas dos ndices). No SGBD Oracle possvel passar esse
endereo, em um formato definido, como predicado de uma consulta.
2.1.2.3. Mtodos de unio
Sempre que mais de uma fonte de dados (tabela, ndice, etc) acessada em um bloco de
consulta, o SGBD deve escolher a forma de uni-las para possibilitar o processamento
conjunto do resultado. Os mtodos mais comuns de unio, que so escolhidos de acordo com
a consulta e o algoritmo de otimizao, so:
Juno por iterao simples (nested loops join)
o mtodo mais comum e sua grande vantagem retornar rapidamente algum resultado
para o usurio, sendo lento para grandes volumes de dados se comparado com outros mtodos
de juno. Esse algoritmo define uma fonte de dados externa e uma fonte de dados interna,
interagindo em todo o resultado da fonte de dados interna para cada linha da fonte de dados
externa. A figura 4 demonstra a lgica do funcionamento desse algoritmo.
12
Figura 4 Lgica da juno por iterao simples
Juno por hashing (hash join)
Este o mtodo mais comum para processamento de grandes volumes de dados e s
est disponvel no otimizador por custo. Sua lgica escolhe a menor das duas fontes de dados
envolvidas na unio e monta uma tabela hash em memria que contm a representao dos
valores distintos das chaves da juno encontrados na tabela menor. A partir da tabela hash,
toda a fonte de dados maior ser lida em busca dos valores em comum, retornando os que
atendem a juno.
Juno por classificao e intercalao (sort-merge join)
Este mtodo tambm eficiente para processamento de grandes volumes de dados e sua
grande vantagem retornar o resultado j ordenado. Em uma juno com esse algoritmo, s
duas fontes de dados so ordenadas e percorridas inteiramente para a unio.
Juno por plano cartesiano (cartesian merge join)
Essa unio ocorre quando no h uma condio de unio entre uma ou mais fontes de
dados, forando a unio de cada linha de uma fonte de dados com cada linha de outra. Juno
por plano cartesiano normalmente gerado por erros de escrita na consulta.
Alm dos mtodos j descritos, existe o mtodo para juno externa (outer join), que
retornam no s as linhas da juno, mas tambm as linhas que no atendem a chave da
juno em uma das fontes de dados. Existem ainda outras derivaes e mtodos: semi join,
anti join, juno paralela e algumas outras dependendo do SGBD.
13
2.1.2.4. Ordem de unio
Quando mais de uma fonte de dados (tabela, ndice, etc) acessada em um bloco de
consulta, assim como os mtodos de unio, a ordem em que fontes de dados sero unidas
precisa ser definida. A ordem de unio influenciar na quantidade de dados trabalhados e
consequentemente na velocidade da execuo da consulta. A forma como essa ordem
escolhida depende do algoritmo de otimizao usado e ser discutida nos captulos referente
aos mtodos de otimizao.
2.1.2.5. Operaes especficas
As operaes so rotinas encontradas em um SGBD que executam tarefas
imprescindveis na resoluo dos planos de execuo que sero usados para as consultas. No
SGBD Oracle, as principais operaes especificas so:
IN-LIST ITERATOR
Iterage em uma fonte de dados filtrando os valores que esto em um predicado do tipo
IN.
COUNT
Operao que conta o nmero de linhas selecionadas de uma tabela.
SORT
Operao que efetua a ordenao em uma fonte de dados. Existem vrias operaes e
um mtodo de unio que usa esse operador: MIN, MAX, AVG, COUNT, STDDEV, ORDER
BY, GROUP BY, DISTINCT, UNION, INTERSECT, MINUS e Sort-Merge Join;
SEQUENCE
Efetua um acesso a um objeto do tipo SEQUENCE (sequncia);
14
UNION ALL
Operao que aceita dois conjuntos de linhas e retorna a unio desses conjuntos. Note
que a funo UNION eliminanda duplicados a partir de uma operao extra de ordenao
(SORT).
VIEW
Operao que executa uma viso e retorna seu resultado para outra operao.
FILTER
Operao que recebe um conjunto de linhas e cria um subconjunto de acordo com a
regra de filtro. Permite ao SGBD filtrar resultados mesmo quando o mtodo de acesso fonte
de dados no permita isso (leitura completa da tabela, por exemplo).
2.1.3. Mtodos de otimizao
Os mtodos de otimizao so as formas como a problemtica de otimizao descrita no
captulo de processamento da consulta resolvida. Apesar de existirem vrios otimizadores
para casos especficos, os mais usados em SGBDs so o otimizador por regra e o otimizador
por custo.
2.1.3.1. Otimizao por regra
O otimizador por regra foi amplamente usado pelos SGBDs, mas atualmente foi
descontinuado ou mantido por compatibilidade pela maioria dos produtos, pois seu
funcionamento considerado limitado comparado com a otimizao por custo: h limitaes
de recursos, como unio por hash e index-skip scan, e limitaes na qualidade de suas
decises, pois o algoritmo no utiliza variveis importantes como o tamanho e distribuio
dos dados das tabelas e ndices. Suas decises so baseadas somente na sintaxe da consulta
SQL, em regras estticas e em poucas informaes do dicionrio de dados. Para a gerao do
plano de execuo, os predicados so processados na ordem que aparecem nos parmetros da
clausula where do texto da consulta SQL e os mtodos de acesso so escolhidos a partir de
uma lista de regras definidas de acordo com o SGBD usado. Como normalmente possvel
15
acessar de mais de uma forma as fontes de dados, para cada regra h um peso (ranking) ou
prioridade. Quando h mais de um mtodo possvel, o mtodo com menor peso ou maior
prioridade escolhido. Como exemplo, a figura 5 contm as regras usadas no otimizador por
regra do SGBD Oracle, que baseado em peso (rank). Como possvel notar na figura 5, o
acesso pelo endereo da linha ou por ndice, quando disponveis, so sempre as melhores
escolhas, e a leitura total da tabela, a pior. Quando h duas formas de acesso com o mesmo
peso, cada SGBD implementa uma forma de desempate: no SGBD Oracle o critrio de
desempate o objeto com a data de criao mais atual. Como discutido anteriormente, quando
h mais de uma fonte de dados envolvida na consulta os mtodos de unio a ordem da unio
devem ser definidas. No otimizador por regra o mtodo de unio tambm escolhido com
base na lista de regras. No SGBD Oracle, o otimizador ir sempre utilizar a juno por
iterao simples (nested loops join) com uma exceo: caso o mtodo de acesso de uma fonte
de dados tenha peso 12 ou pior (maior) e a chave de unio seja por igualdade (equijoin), o
otimizador ir utilizar a juno por classificao e intercalao (sort-merge join). A ordem de
unio definida a partir da ordem inversa das fontes de dados encontrada no from do texto
da consulta.
16
Mtodos de acesso e sua prioridade Peso 1 Pesquisa por linha nica acessada pelo endereo (ROWID) Peso 2 Pesquisa por linha nica acessada por uma juno em cluster Peso 3 Pesquisa por linha nica acessada pela chave hash do cluster a partir da chave primria ou nica Peso 4 Pesquisa por linha nica acessada por chave nica ou primria indexada Peso 5 Juno por cluster Peso 6 Pesquisa por chave hash do cluster Peso 7 Pesquisa por chave indexada do cluster Peso 8 Pesquisa em ndice composto Peso 9 Pesquisa em ndice com uma nica coluna Peso 10 Pesquisa por intervalo fechado em colunas indexadas Peso 11 Pesquisa por intervalo aberto em colunas indexadas Peso 12 Juno por classificao e intercalao (Sort-Merge Join) Peso 13 Uso de operadores MAX ou MIN em colunas indexadas Peso 14 Uso do operador ORDER BY (SORT) em uma coluna indexada Peso 15 Leitura total da tabela
Figura 5 Regras e prioridades do otimizador por regra no SGBD Oracle
2.1.3.2. Otimizao por custo
O otimizador por custo foi criado com o intuito de resolver de forma mais acurada e
dinmica a problemtica de otimizao. Atualmente ele o otimizador utilizado pelos SGBDs
lderes de mercado. Seu funcionamento consiste em estimar sistematicamente o custo de
estratgias de execuo diferentes e escolher o plano de execuo com o menor custo
estimado. Suas decises so baseadas no dicionrio de dados, estatsticas, parmetros e no
so influenciadas pela sintaxe da consulta SQL. Como sua deciso depende de estatsticas,
necessria a atualizao peridica dessas informaes para o melhor funcionamento do
algoritmo. Os dois componentes principais do otimizador por custo so: o gerador de
estimativas e o gerador de planos de execuo. A funo desses dois componentes gerar um
conjunto de planos de execuo, estimando o custo de cada um. O conjunto de planos de
execuo formado examinando todos os possveis mtodos de acesso (uso de ndice, leitura
total da tabela, etc), algoritmos de unio (sort-merge join, hash join, nestead loops, etc) e
operadores (filter, sort, etc). Isto possibilita que o otimizador determine qual dos planos o
mais eficiente a partir de seu custo. O tamanho do conjunto de planos gerados normalmente
limitado por parmetro de configurao para impedir que o prprio otimizador se torne um
problema. A mtrica de custo do otimizador uma tentativa de calcular o custo
computacional do processamento de um plano. Cada SGBD leva em conta certa quantidade
de fatores para o clculo desse valor e normalmente ele baseado no nmero de operaes de
entrada/sada necessrios, CPU e outros fatores determinados pelo dicionrio de dados. Desta
forma o mtodo de acesso, o mtodo de unio, a ordem de unio e os operadores so
17
escolhidos de acordo com o plano de execuo com menor custo. importante ressaltar que
mesmo trabalhando com mais informaes que outros algoritmos de otimizao, o custo
tambm heurstico, existindo o risco da escolha de uma estratgia de execuo que no seja
a melhor.
2.1.3.2.1. Parmetros
Os parmetros do otimizador so configuraes estticas do SGBD que objetivam
ajustar o comportamento do otimizador de acordo com a caracterstica da aplicao. Os
principais ajustes definem a tendncia da escolha do otimizador a planos de execuo com
melhor desempenho no retorno do inicio do resultado da consulta ou no retorno do total do
resultado da consulta. Os principais parmetros do otimizador no SGBD Oracle so os
seguintes:
OPTIMIZER_MODE
Decide qual algoritmo e abordagem do otimizador ser usado. Os valores possveis so:
RULE (Regra), ALL_ROWS (custo com abordagem para obter todas as linhas rapidamente),
FIRST_ROWS (custo com abordagem para obter as primeiras linhas rapidamente) e
CHOOSE (o otimizador escolhe qual utilizar acordo com a disponibilidade de estatsticas);
OPTIMIZER_INDEX_COST_ADJ
Define a tendncia de escolha do otimizador por acesso por ndice. Esse parmetro pode
ser configurado de 1 at 10000, onde 100 significa que o acesso por ndice igual aos
outros mtodos e 50 significa que o uso de ndice custa metade que outro mtodo.
OPTIMIZER_INDEX_CACHING
Define a tendncia da escolha do otimizador pelo mtodo de unio juno por iterao
simples (nested loops join) e o operador IN-LIST ITERATOR ao invs de juno por hash
(hash join) ou juno por intercalao (sort-merge join). Seu valor a porcentagem de blocos
dos ndices que o otimizador deve assumir que est em memria.
18
DB_FILE_MULTIBLOCK_READ_COUNT
Este parmetro determina o nmero mximo de blocos que sero lidos em uma nica
operao de leitura/gravao durante uma leitura seqencial (multi-bloco). Quanto maior este
valor, maior a tendncia do otimizador escolher o mtodo de acesso por leitura completa da
tabela ou index fast full scan. A partir do oracle 9 e a adoo do CPU Costing Model esse
valor estimado quando as estatsticas de sistema so coletadas, ignorando o valor desse
parmetro e usando no lugar o valor encontrado no dicionrio de dados.
2.1.3.2.2. Estatsticas
As estatsticas so informaes coletadas em tempo de execuo que ajudam o
otimizador tomar melhores decises.
As principais estatsticas coletadas so:
Estatsticas de tabela: nmero de blocos, nmero de blocos vazios, nmero de chained
ou migrated rows, tamanho mdio da linha, data da coleta e tamanho da amostra.
Estatsticas de ndices b-tree: altura, nmero de blocos folha, nmero de chaves
distintas, nmero mdio de blocos folha por chave, nmero mdio de blocos por chave,
nmero de entradas (index entries), clustering factor, data da coleta e tamanho da amostra.
Estatsticas de Colunas: nmero de valores distintos, menor valor, maior valor, data da
coleta e tamanho da amostra;
Outra estatstica importante nos casos de campos com valores com distribuio no uniforme
so os histogramas, que permitem ao otimizador escolher planos de execuo distintos de
acordo com o valor do predicado.
2.1.3.2.3. Modificadores (hints)
Como o otimizador por custo em boa parte, automtico, a interao do usurio sobre
como suas decises so tomadas limitada. No SGBD Oracle, os modificadores, que so
diretivas de compilao, permitem que o usurio influencie a escolha do otimizador por custo.
19
2.1.4. Custo versus regra
Com a evoluo do otimizador por custo, vrios recursos foram sendo melhorados e
adicionados. Atualmente o SGBD Oracle est na verso 11g e existem inmeras vantagens
para o uso do otimizador por custo, por exemplo:
Tabelas e ndices particionados: capacidade de dividir fsicamente as informaes
contidas em tabelas e ndices em pores menores a partir de regras definidas pelo usurio;
Tabelas organizadas por ndice: criao de tabelas que respeitam a ordem de um ndice
b-tree;
ndices com chave reversa: ndices onde os valores das chaves so invertidos, byte a
byte;
Paralelismo na execuo: permite a execuo paralela da consulta;
Otimizador extensvel: suporte a extenso das funcionalidades do otimizador pelo
usurio;
Reescrita da consulta para o uso de vises materializadas: funcionalidade discutida no
capitulo 2.1.1.2;
Mtodo de unio por hash (Hash joins): mtodo de unio discutido no capitulo 2.1.2.3;
ndices bitmap e unio por ndices bitmap: novo tipo de ndice baseado em mapas de
bits;
Mtodo de acesso Index skip scans: mtodo de acesso discutido no capitulo 2.1.2.2;
Para comprovar a evoluo do otimizador, foram efetuados testes em alguns desses recursos.
O banco de dados utilizado foi o Oracle Database 10g Enterprise Edition Release 10.2.0.1.0:
INDEX SKIP SCAN
Para o teste, foi usada a tabela no formado do diagrama E-R encontrado na figura 6.
20
Figura 6 - Index skip scan: diagrama E-R da tabela usada para o teste
Nesta tabela foram carregadas 3.020.730 linhas, onde a coluna PK contm valor
seqencial de 0 a 3020729, a coluna VALUE1 contm valores de 1 a 100, a coluna VALUE2
contm valores de 1 a 10000 e a coluna VALUE3 contm valores de 1 a 50000. Todas as
colunas VALUE contm valores com distribuio uniforme.
No paradigma antigo, o ndice SKIPSCAN_VALUES_IDX somente seria usado caso o filtro
aplicado fosse em VALUE1 ou VALUE1 e VALUE2. O otimizador por custo permite, caso
seja interessante, utilizar o ndice mesmo nos casos onde o filtro seja aplicado nas colunas dos
sub-nveis, onde antes a abordagem possvel era somente a leitura completa da tabela,
resultando em menor nmero de leituras necessrias para o processamento da consulta. Os
seguintes testes foram efetuados, gerando os seguintes planos de execuo:
Filtro na coluna presente no sub-nvel do ndice e otimizador por regra:
SELECT * FROM SKIPSCAN where VALUE2 = 1;
Filtro na coluna presente no sub-nvel do ndice e otimizador por custo:
SELECT * FROM SKIPSCAN where VALUE2 = 1;
21
O resultado dos testes, com o nmero de blocos necessrios para o processamento da
consulta e tempo de execuo encontra-se nos grficos das figuras 7 e 8.
Figura 7 Index skip scan: grfico comparativo de leituras Regra versus Custo
Figura 8 Index skip scan: grfico comparativo de tempo Regra versus Custo
Os testes comprovaram que o uso do otimizador por custo mais eficiente que o
otimizador por regra em casos de filtros aplicados em colunas posicionadas em sub-nveis de
ndices: em mdia, foram exigidos 98,4% menos leituras e 44,4% menos tempo para execuo
22
da consulta. Essa diferena ocorre, pois o otimizador por custo baseado nas suas estatsticas
previamente coletadas diferencia o caso que menos custoso: acessar a tabela por ndice via
sub-nveis ou efetuar a leitura total da tabela. Nos casos onde existam ndices com mais de
uma coluna, onde cada coluna representa um nvel, e consultas com filtros em colunas que
no esto no primeiro nvel do ndice, o otimizador por custo permite que seja usado o ndice
varrendo os sub-nveis, sendo que o custo do uso desse ndice proporcional quantidade de
valores distintos nos nveis anteriores. No exemplo, como a coluna VALUE1 foi carregada
somente com valores de 1 a 100, ser necessrio para percorrer todo o segundo nvel do ndice
SKIPSCAN_VALUES_IDX efetuar 100 pesquisas distintas com valor do filtro aplicado na
coluna VALUE2.
HASH JOIN
Para o teste, foi usada a tabela no formado do diagrama E-R encontrado na figura 9.
Figura 9 Hash join: diagrama E-R das tabelas usadas para o teste
Na tabela HASHJOIN1 foram carregadas 1.511.010 linhas, onde a coluna PK contm
valor seqencial de 0 a 1.511.009 e a coluna VALUE contm valores de 1 a 5.000. Na tabela
HASHJOIN2 foram carregadas 1.511.010 linhas, onde a coluna PK contm valor seqencial
de 0 a 1.511.009, a coluna VALUE contm valores de 1 a 5.000 e a coluna FK contm uma
referncia para cada linha da tabela HASHJOIN1, ou seja, valor seqencial de 0 a 1.511.009.
Os seguintes testes foram efetuados, gerando os seguintes planos de execuo:
Unio de duas tabelas mdias e otimizador por regra:
SELECT * FROM HASHJOIN1 HJ1, HASHJOIN2 HJ2 where HJ2.FK = HJ1.PK;
23
Obs: SYS_C005505 o ndice criado automaticamente para a chave primria - coluna PK da
tabela HASHJOIN1.
Unio de duas tabelas mdias e otimizador por custo:
SELECT * FROM HASHJOIN1 HJ1, HASHJOIN2 HJ2 where HJ2.FK = HJ1.PK;
O resultado dos testes, com o nmero de blocos necessrios para o processamento da
consulta e tempo de execuo encontra-se nos grficos das figuras 10 e 11.
Figura 10 Hash join: grfico comparativo de leituras Regra versus Custo
24
Figura 11 Hash join: grfico comparativo de tempo Regra versus Custo
Os testes comprovaram que o uso do otimizador por custo mais eficiente que o
otimizador por regra em casos de unio de conjuntos de tamanho mdio e grande: em mdia,
foram exigidos 97,7% menos leituras e 30,1% menos tempo para execuo da consulta. Essa
diferena ocorre, pois o otimizador por custo baseado nas suas estatsticas previamente
coletadas diferencia o caso que menos custoso: unir a tabela via nested loops, hash join ou
merge join. Normalmente o mtodo nested loops o melhor para unio de pequenos
conjuntos, mas para unio de grandes conjuntos ele ruim: para cada linha da tabela externa,
a tabela ou ndice interno inteiro ter que ser lido. Nesses casos o hash join mais eficiente:
os dois conjuntos so lidos integralmente somente uma vez. O merge join melhor que o hash
join em casos especficos, como em consultas onde h juno de conjuntos com ordenao
pela chave da unio, pois este mtodo ordena os conjuntos para unir, no sendo necessrio
uma tarefa de ordenao posterior.
HISTOGRAMAS
Para o teste, foi usada a tabela no formato do diagrama E-R encontrado na figura 12.
25
Figura 12 Histograma: diagrama E-R da tabela usada para o teste
Nesta tabela foram carregadas 2.063.088 linhas, onde a coluna PK contm valor
seqencial de 0 a 2063087 e a coluna VALUE contm valores de 1 a 50 com a distribuio de
valores demonstrada no grfico na figura 13.
Figura 13 Histograma: distribuio dos dados na coluna VALUE
Com a distribuio no uniforme dos dados comprovada acima, o uso do otimizador por
custo e a coleta de histograma deve resultar em resultados significantes, para tal, os seguintes
testes foram efetuados, gerando os seguintes planos de execuo:
Filtro com valor de baixa freqncia no campo da tabela e otimizador por regra:
SELECT * FROM HISTOGRAMA where VALUE = 30;
26
Filtro com valor de alta freqncia no campo da tabela e otimizador por regra:
SELECT * FROM HISTOGRAMA where VALUE = 10;
Filtro com valor de baixa freqncia no campo da tabela e otimizador por custo com
histograma coletado para o campo VALUE:
SELECT * FROM HISTOGRAMA where VALUE = 30;
Filtro com valor de alta freqncia no campo da tabela e otimizador por custo com
histograma coletado para o campo VALUE:
SELECT * FROM HISTOGRAMA where VALUE = 10;
O resultado dos testes, com o nmero de blocos necessrios para o processamento da
consulta e tempo de execuo encontra-se nos grficos das figuras 14 e 15.
27
Figura 14 Histograma: grfico comparativo de leituras Regra versus Custo
Figura 15 Histograma: grfico comparativo de tempo Regra versus Custo
Os testes comprovaram que o uso do otimizador por custo com histograma mais
eficiente que o otimizador por regra em casos de filtros aplicados em colunas com
distribuio de valores no uniformes: em mdia, foram exigidos 44,56% menos leituras e
52% menos tempo para execuo da consulta.
28
Essa diferena ocorre, pois o otimizador por custo baseado nas informaes dos histogramas
diferencia o caso que menos custoso: acessar a tabela por ndice ou efetuar a leitura total da
tabela. Nos casos onde existam valores com uma quantidade significativa de freqncia os
acessos por leituras simples na tabela gerados pela consulta no ndice tornam-se to custosos
que mais rpido ler a tabela na ntegra. No otimizador por regra o ndice, abordagem menos
eficiente neste caso, sempre ser usado quando disponvel.
29
3. Concluso
A elaborao desse trabalho deixou evidente que o conhecimento do funcionamento
interno do otimizador do SGBD utilizado obrigatrio e imprescindvel para profissionais
que desejem trabalhar com esses softwares. Com a evoluo dos SGBDs a tendncia que
vrios pontos de configurao atualmente obrigatrios sejam automatizados e as alteraes
nos otimizadores para resolver problemas antes tratados pelos usurios o ponto principal
dessa evoluo. Os experimentos aplicados ao SGBD Oracle, em forma de comparao entre
os algoritmos de otimizao (captulo 2.1.4), evidenciaram que esse objetivo est sendo
atingido.
30
4. Referncias bibliogrficas
LAHDENMAKI, Tapio. LEACH, Mike. Relational database index design and the optimizers:
DB2, Oracle, SQL server. Wiley-Interscience, 2005.
GREEN, Connie Dialeris. et ali. Oracle9i Database Performance Tuning Guide and
Reference, Release 2 (9.2). Oracle Corporation, 2002.
POWELL, Gavin. Oracle High Performance Tuning for 9i and 10g. Digital Press, 2003.
ORACLE MAGAZINE: Understanding Oracle SQL Optimizat ion. Disponvel em:
. Acesso em
12/05/2008.