Sistemas de Base de Dados

Comparao entre PostgreSQL, Oracle e Microsoft SQL Server dos mecanismos para processamento e optimizao de perguntas Grupo 17

Elaborado por: Diogo Brito, n37739 Joo Costa, n 37945 Pedro Pires, n25806

Dezembro 2011

ndice:

1.

Introduo......................................................................................................... 4 1.1. 1.2. 1.3. Microsoft SQL Server ......................................................................................... 5 Oracle ................................................................................................................. 5 PostgreSQL ......................................................................................................... 5

2.

Comparao ...................................................................................................... 8 2.1. 2.2. 2.3. 2.4. 2.5. 2.6. 2.7. 2.8. 2.9. Linguagem Intermdia ....................................................................................... 8 Implementao de operaes bsicas ............................................................... 9 Algoritmos suportados..................................................................................... 14 Mecanismos para consultar planos ................................................................. 16 Paralelizao de Queries .................................................................................. 18 Optimizao ..................................................................................................... 21 Estimativa de Custos ........................................................................................ 26 Comandos para parmetrizar a construo e uso de estimativas .................. 32 Transformaes ............................................................................................... 32

3. 4.

Concluso ........................................................................................................ 36 Bibliografia ...................................................................................................... 38

ndice de imagens

Figura 2.1 - Pipelining base de uma query .................................................. 9 Figura 2.2 - Representao de uma query ................................................ 10 Figura 2.3 Operadores ........................................................................... 11 Figura 2.4 - Hash Join ............................................................................... 12 Figura 2.5 - Funcionamento do Hash Join ................................................. 13 Figura 2.6 - Processamento de uma query ............................................... 21 Figura 2.7 - rvore derivada ..................................................................... 22 Figura 2.8 - Clculo do custo .................................................................... 25

1. Introduo
A anlise do processamento de perguntas num sistema de gesto de base de dados (SGBD) surge pela necessidade de optimizao das mesmas. Apesar de numa base de dados de pequena escala a optimizao poder no ter grande impacto, numa base de dados de grande escala a forma como as perguntas so particionadas internamente pode reduzir o tempo de resposta a uma dada pergunta. Geralmente as SGBDs esto divididas em duas partes. Uma que gere e controla os dados guardados, sendo responsvel pela gesto destes. A segunda responsvel por receber uma query e produzir o output da mesma. Para isto primeiro criado um plano de execuo e, aps o plano estar completo, este executado. Este plano feito atravs da transformao da operao lgica original em operaes fsicas. Uma operao lgica pode estar associada a apenas operao fsica, como o caso da ordenao, ou pode estar associada a mais, por exemplo, transformar um join num nested loop join, merge join ou hash join. Para a elaborao dos planos so usadas estatsticas, para que seja possvel calcular qual a melhor forma de produzir os resultados esperados, e, dependendo do custo de cada plano, escolhido um que ir ser levado adiante. sobre esta segunda parte das SGBDs que este relatrio vai recair. Como so elaborados planos e como estes podem ser optimizados. Para a elaborao deste trabalho foram escolhidas, para alm de Oracle, as SGBDs Microsoft SQL Server 2008 e PostgreSQL, sendo que esta escolha baseou-se nas funcionalidades oferecidas por cada uma das SGBDs, e pela documentao existente sobre as mesmas.

1.1. Microsoft SQL Server

Desenvolvido pela Microsoft em parceria com a Sybase em 1988 aparece como um produto complementar do Windows NT. A verso mais actual o SQL Server 2008 R2 mas espera-se j uma nova verso em 2012. As principais linguagens que aceita so Transact SQL (T-SQL) e ANSI SQL. um sistema de gesto de bases de dados que pode funcionar tanto localmente apenas num computador como em vrios ao mesmo tempo, mesmo pela internet.

1.2. Oracle

Lanada em 1979 por uma empresa criada por Larry Ellison (actualmente CEO da Oracle Corporation) e dois colegas, foi a primeira base de dados relacional a estar disponvel comercialmente. Os objectos e funes guardados podem ser invocados pela linguagem PL/SQL, linguagem proprietatia da Oracle Coorperation, ou por Java. A ltima verso Oracle 11g.

1.3. PostgreSQL

O PostgresSQL uma SGBD desenvolvida na Universidade da Califrnia no Berkeley Computer Science Department. Esta SGBD foi pioneira em diversos conceitos que s foram implementados em SGBDs comerciais vrios anos mais tarde.

Esta SGBD open-source que nasceu no final dos anos 70 a partir de um projecto acadmico. Antes do nome Postgres ser adoptado este tinha como nome INGRES (INteractive Graphics REtrieval System). So suportadas vrios standards do SQL bem como novas operaes: Queries complexas; Chaves externas; Triggers; Vistas; Integridade de transaces; Controlo de concorrncia;

No ano de 1986, o Professor Michael Stonebraker, patrocinado pela Defense Advanced Research Projects Agency (DARPA), Army Research Office (ARO), National Science Foundation (NSF) e ESL, Inc, liderou o projecto com uma vasta equipa por trs conseguindo implementar um largo nmero de operaes sendo que a primeira verso, ainda que no finalizada, surgiu em 1987. Em 1990 o sistema foi redesenhado com um novo sistema de regras e, em 1991, surgiu uma verso melhorada suportando mltiplos gestores de armazenamento, um executante de queries melhorado e o sistema de regras foi reescrito. Como podemos constatar atravs dos factos referidos atrs, o PostgreSQL evoluiu de uma maneira acelerada, no entanto, em 1994 surgiu uma verso que revolucionou o projecto. Esta verso a chamada POSTGRES95 e foi desenvolvida por dois alunos, Andrew Yu e Jolly Chen. O que se destaca esta verso o facto de ter um interpretador da linguagem SQL. Esta verso foi disponibilizada na internet numa verso opensource, juntamente com um tutorial o que facilitou e impulsionou o desenvolvimento da SGBD.

O Posrgres possibilita tambm a adio de novos tipos de dados, funes, operadores, funes agregadas, mtodos de index e linguagens procedimentais (PL/pgSQL, PL/Perl, PL/Java, PL/Ruby, etc.).

O facto de o Posrgres ser open-source torna possvel e gratuita a sua modificao quer seja por privados, comerciais ou com objectivos acadmicos, e de realar que vrias empresas usam esta SGBD para gerir os seus dados, como por exemplo o MySpace, Skype, IMDB, Yahoo, chegando a albergar dados na ordem dos petabytes neste ltimo caso.

2. Comparao
2.1. Linguagem Intermdia

Uma linguagem intermdia a linguagem desenhada para correr numa mquina abstracta e usada muitas vezes pelos compiladores como, tal o nome indica, uma linguagem intermdia antes de passar para a linguagem mquina. Isto existe pois uma linguagem que pode ser independente do CPU e ao mesmo tempo da linguagem de programao em si. Um exemplo disso , dentro da plataforma .NET, todas as linguagens (C#, vb.net, etc) serem traduzidas para MSIL (Microsoft Intermediate Language) e apenas depois para linguagem mquina. Este tipo de linguagens intermdias so utilizadas pelos compiladores e tambm por outras ferramentas. O Oracle e o PostgreSQL, por utilizarem o PL/SQL, que baseado em Ada utilizam uma variante do Desciriptive Intermediate Attributed Notation for Ada (DIANA). Para estes dois ltimos, o funcionamento o seguinte: no momento de compilar o PL/SQL traduzido em cdigo de sistema e formado um pacote que gravado na base de dados; no momento de execuo estes so carregados para a memria partilhada e o cdigo executado. Na memria partilhada um pacote est limitado a 2^26 ns de DIANA o que corresponde a cerca de 6 milhes de linhas de cdigo. O SQL Server utiliza o MSIL, como referido anteriormente. O MSIL: Microsoft Intermediate Language mas actualmente denominada por Common Intermediate Language. Esta linguagem tambm utilizada por todas as outras .NET Languages (C#, VB.NET, ASP.NET).

2.2. Implementao de operaes bsicas

Figura 2.1 - Pipelining base de uma query

Quando uma query compilada o cdigo primeiro traduzido para uma representao equivalente em rvore. Depois, e caso a query tenha uma sintaxe SQL vlida, um conjunto de verificaes efectuado para verificar se o utilizador tem acesso s tabelas e colunas pertencentes arvore, tal como verificado se estas existem. ainda neste passo que so efectuadas verificaes de semntica para garantir que so vlidas e que, por exemplo, as colunas enumeradas num GROUP BY so vlidas no caso em questo. Quando completa a rvore da query e se verificou que a query est totalmente correcta ento entra em aco a optimizao. Neste passo o optimizador de query verifica diferentes tipos de planos, escolhendo a melhor a ser executada para o caso e entrega ao sistema para o plano escolhido para que este execute a query. Ao construir a representao da query em rvore atribudo a cada operao um n da rvore distinto. Vejamos o exemplo de como SELECT * FROM Customers C INNER JOIN Orders O in C.cid = O.cid WHERE O.date= 2008-11-06 poder ser representado internamente.

Figura 2.2 - Representao de uma query

O processador de queries utiliza diferentes rvores durante o processo. Um caso onde tal pode ser verificado quando o Optimizador de Queries transforma uma operao lgica numa fsica, como exemplo, transforma um JOIN lgico (neste caso um INNER JOIN) num JOIN fsico (Hash, merge ou nested). SQL Server tem cerca de 40 operadores lgicos e ainda mais operadores fsicos. Alguns dos mais comuns iro ser focados, como o JOIN ou SELECT e outros mais especficos, como UDX ou Segment, no sero abordados. Operadores: Todos os operadores, em SQL Server, funcionam por pedidos de linhas aos seus ns filhos e, depois, retornando linhas aos ns que o chamam (pais), como no exemplo a seguir.

Figura 2.3 Operadores

Cada operador retorna uma linha de cada vez, por isso, um caller ter de fazer vrios pedidos para obter vrias linhas. O n caller poder ser um operador pai ou o utilizador, que ir receber a resposta da query. Existem trs tipos de join fsico: HASH JOIN MERGE JOIN NESTED LOOP JOIN

Em queries pequenas, que afectam um nmero reduzido de valores, o nested loop join muito superior em relao aos demais, porem em queries com muitos valores as duas primeiras podem ser melhores. A escolha de qual usar feita dinamicamente pelo optimizador. Hash Join Vejamos o seguinte exemplo, relativo ao seguinte cdigo SQL:

Figura 2.4 - Hash Join

Um hash join utiliza duas entradas, uma de construo e uma de indicao. A entrada de construo mostrada no topo enquanto a de indicao, mostrada em baixo. A mais pequena das duas entradas escolhida para ser a de construo. A operao feita em duas fases: a de construo e a de indicao. O caso mais comum de hash join o in-memory hash join, onde na primeira fase, o conjunto de entrada de construo totalmente consultado e, depois, uma tabela de hash escrita em memria. Cada linha , de seguida, inserida num conjunto de hash (denominado hash bucket) dependendo do valor de hash computado para a sua chave de hash. Esta fase seguida da de indicao onde, para cada linha na entrada de indicao, gerada uma chave de hash. Ento, no correspondente conjunto de hash para aquela chave, pesquisada a chave da entrada de indicao e so gerados os valores comuns. A figura seguinte ilustra bem como feito.

Figura 2.5 - Funcionamento do Hash Join

Este tipo de pesquisa usado maioritariamente quando existem um grande nmero de dados, tipicamente no ordenados e no indexados. Merge Join Neste tipo de query necessrio que ambas as entradas estejam ordenadas nas colunas que esto a ser misturadas. Se houver ndices disponveis em ambas as colunas de entrada ento obtida uma linha de cada uma, so comparados os valores e, se coincidirem, adicionada essa linha ao resultado final. Este processo executado para todas as entradas. Nested Loop Join O nested loop join usa uma das entradas dos join como entrada exterior da tabela e a outra como entrada interior da tabela. Basicamente existem dois ciclos sendo que um

deles est dentro do outro. O ciclo exterior vai consumindo a entrada exterior linha por linha medida que o interior verifica entradas na entrada interior. Este tipo de join muito eficiente quando a entrada exterior relativamente pequena e a entrada interior grande mas indexada. Em muitos tipos de query onde existem apenas um conjunto pequeno de entradas este muito superior aos dois tipos de join referidos anteriormente. Caso a tabela interior no esteja indexada na coluna em questo , ento, necessrio usar um hash join.

2.3. Algoritmos suportados

Os ndices so a base da melhoria de performance das queries. Um ndice bem feito poder melhorar substancialmente o tempo de resposta de uma query, no entanto, um ndice incorrecto ou colocado na coluna errada pode ter o efeito contrrio podendo aumentar o tempo de resposta. Sendo uma das melhores formas de reduzir as leituras/escritas do disco permite encontrar informao numa tabela sem ter que a percorrer por completo; pode at ser comparada a um ndice de um livro: se o consultarmos e encontrarmos a informao necessria podemos ir directamente para a pgina que nos interessa. H duas operaes bsicas que podem ser aplicadas atravs do ndice: Pesquisa (por um valor ou um conjunto de valores na chave do ndice); Percorrer o ndice (para a frente ou para trs);

Para a pesquisa, o operador inicial comea na raiz da rvore B+ e navega em profundidade at ao local desejado, baseado nas chaves dos ndices. Uma vez completo ento possvel para o processador de query iterar sobre todas as linhas que verificam um certo predicado ou at que o ltimo valor pertencente ao predicado seja encontrado.

Uma vez que os ns de folha numa rvore B+ (usada pelo SQL Server) esto ligados ento possvel consultar linhas ordenadamente medida que se navega por esses mesmos ns. Uma das tarefas com Optimizador de Query o de assimilar quais predicados podero ser aplicados a um certo ndice para retornar linhas o mais rpido possvel; alguns podem ser aplicados a um ndice enquanto outros no. Os predicados que podem ser convertidos em ndices so muitas vezes denominados sargable, de significado Search-ARGument-able, enquanto os que no podem so denominados non-sargable. Estes ltimos seriam normalmente aplicados depois de uma pesquisa ao ndice ou aps percorrer este; isto para que a pesquisa retornasse todos os valores que verificam todos os predicados. No entanto, no SQL Server verifica normalmente os non-sargable dentro da pesquisa/percorrer ndice na rvore da query, por questes de optimizao. Caso no o fizesse os passos seriam: 1. Operador de pesquisa: Pesquisar uma chave no ndice da rvore B+; 2. Trancar a pgina; 3. Ler a linha; 4. Libertar a pgina; 5. Retornar a linha ao operador de filtro; 6. Filtro: testar se a linha verifica o predicado non-sargable. Se sim, passar a linha para o operador pai. Se no, voltar a 2; No entanto, esta opo mais lenta que a ptima pois retornar a linha para um outro operador exige carregar um novo conjunto de instrues e dados para o CPU. Se o conjunto da operao for mantido apenas num stio, o custo geral de CPU ir baixar. Os passos so: 1. Operador de pesquisa: Pesquisar uma chave no ndice da rvore B+; 2. Trancar a pgina; 3. Ler a linha; 4. Aplicar o filtro non-sargable. Se no passar o filtro ir para o passo 3, se no ir para 5;

5. Libertar a pgina 6. Retornar a linha Isto chamado de injectar predicados non-sargable, pois o predicado passa duma operao exterior para dentro da pesquisa/percorrer. uma optimizao fsica mas pode aparecer em queries que processem muitas entradas. No entanto nem todos os predicados podem ser avaliados desta forma pois, como trancar uma pgina bloqueia at o acesso de outros utilizadores a consultarem, ento esta operao est reservada apenas a predicados que no sejam muito pesados em termos de custo. So os chamados predicados non-pushable, non-sargable.

2.4. Mecanismos para consultar planos

Quando se trabalha com sistemas com um tamanho considervel e que exijam resultados rpidos/consistentes, muitas vezes necessrio recorrer a ferramentas que permitam verificar se as queries esto correctas, o que se est a passar por detrs da black-box. Para isso os sistemas muitas vezes disponibilizam tais ferramentas para que um administrador de bases de dados possa cumprir o seu papel. Estes mecanismos mostram tambm os planos que esto por detrs das chamadas que so feitas, podendo verificar-se as decises do optimizador de query, como verificar se se optou por um nested loop join ou um hash join, etc. Em SQL Server a ferramenta existente o SQL Profiler Tool. O SQL Profiler tool um ambiente grfico que permite ao utilizador fazer variados tipos de consulta sobre uma base de dados sem SQL Server, como por exemplo: Monitorizar graficamente SQL Server queries Guardar informao sobre queries em background Analisar a performance do sistema Diagnosticar problemas como deadlocks Fazer debug a uma sintaxe T-SQL

Permite tambm criar SQL Traces

Em Oracle existe o Explain Plan que permite verificar os planos para operadores de SELECT, UPDATE, INSERT e DELETE. mostrada uma rvore com o conjunto de chamadas que o Oracle executa para uma determinada chamada. Nessa rvore podese ver: Conjunto de tabelas que so referenciadas no pedido; Mtodo de acesso por cada tabela mencionada; Mtodo de join para cada tabela afecta a um operador de join; Operadores de dados como filter, sort ou aggregation;

Para alm da informao na rvore ainda possvel ver informao sobre: Optimizao, como o custo e cardinalidade de cada operao; Particionamento, como o conjunto de parties a que se acedeu; Execues paralelas, como a distribuio de mtodos de entrada de join;

Em PostgreSQL a ferramenta utilizada chama-se EXPLAIN e tem a seguinte sintaxe: EXPLAIN [ ( option [, ...] ) ] statement EXPLAIN [ ANALYZE ] [ VERBOSE ] statement

where option can be one of:

ANALYZE [ boolean ] VERBOSE [ boolean ] COSTS [ boolean ] BUFFERS [ boolean ]

FORMAT { TEXT | XML | JSON | YAML } Este comando permite fazer consultas semelhantes ferramenta anterior, do Oracle. Para alm desta ferramenta existe ainda outra que a tkprof.

2.5. Paralelizao de Queries

Paralelizao de queries a tecnologia usada para dividir um comando SQL em vrios e distribui-los por dois ou mais processadores. Funes como full-table scans, sorts, etc. podem ter um aumento de performance ao serem paralelizadas. Apesar de em 1987 a Ingres, predecessora do PostgreSQL, ter comeado a desenvolver paralelizao de queries, o projecto foi abandonado pouco tempo depois. Como tal, apesar de ser uma das features mais comuns vistas em SGBDs, o PostgreSQL no tem esta funo implementada. considerada algo til em apenas poucas situaes e como tal no algo urgente para implementar. Essa tecnologia no entanto implementada tanto pela Microsoft como pela Oracle. No caso da Oracle, a query SQL dividida em unidades mais pequenas, cada uma executada por um processo. Ao ser usada paralelizao, o processo principal torna-se o coordenador da paralelizao, com as seguintes responsabilidades: Divide o trabalho em unidades mais pequenas; Cria um nmero suficiente de processos paralelos que possam executar os subtrabalhos; Atribui os sub-trabalhos aos processos; Liberta os processos aps o fim do processamento do trabalho; Vai atribuindo novos sub-trabalhos aos processos livres at a execuo da query finalizar;

Para que haja paralelizao num comando do tipo Select, necessrio que este cumpra alguns requisitos: Pelo menos uma das tabelas acedida atravs de um full-table scan ou um ndex range scan; Se a execuo envolver um full-table scan (respectivamente, ndex range scan), necessrio indicar a tabela correspondente ou definir a tabela com uma indicao de paralelizao (respectivamente, indicar o ndex correspondente ou declarar o ndex com indicao de paralelizao); A paralelizao pode ser activada usando o comando: ALTER TABLE nome_da_tabela PARALLEL (DEGREE 8); E pode ser desactivada usando o comando: ALTER TABLE nome_da_tabela NOPARALLEL; A Oracle permite ainda controlar parmetros como o nmero mnimo e mximo de processos em paralelos, ou fazer com que estes parmetros sejam controlados automaticamente. O valor tanto do nmero mximo de processos paralelos como do valor mnimo tem de ser balanceado. O nmero mnimo de processos paralelos tem de ser alto o suficiente para evitar seja necessrio estar sempre a criar processos novos. O valor por defeito 0. Por seu lado, o valor mximo, se for muito alto, ir tentar consumir mais recursos do que os disponveis, acabando por prejudicar na performance da execuo. tambm possvel indicar o nmero de processos associados com uma determinada operao. Tal operao feita com o seguinte comando: SELECT /*+ PARALLEL(orders,4,1) */ ; Em Oracle operaes como inseres, actualizaes e deletes tambm pode beneficiar de paralelizao. Para paralelizar updates e deletes necessrio que as tabelas estejam particionadas, e que diferentes parties sejam usadas. Ou seja, tem-se diferentes processos a fazerem pesquisas em diferentes parties.

Em SQL Server, a paralelizao feita automaticamente, apesar de no ser usada caso acontea uma das seguintes situaes: O custo de execuo da query no alto o suficiente para que seja considerado uma alternativa em que seja usado algum tipo de paralelismo; O plano de execuo paralelizado tem um custo maior que um noparalelizado; A query contm instrues que no podem ser paralelizadas. Dependendo da instruo, isto pode causar que parte do plano, ou o plano na sua totalidade, no seja paralelizado. Durante a criao do plano de execuo, o SQL Server vai colocando operadores para preparar a query para ser executada em paralelo. Este operador faz a gesto dos processos e gesto dos dados. Existem trs tipos de operadores, sendo que um ou mais podem aparecer no plano de execuo: distributed streams, repartition streams e gather streams. O primeiro recebe como parmetro uma lista e divide-a em mltiplas listas. Estas sub-listas mantm o mesmo formato, contedo e ordem que a lista original, apesar de uma entrada poder aparecer em mais que uma sub-lista. O segundo operador, repartition stream, recebe mltiplas listas e devolve mltiplas listas aps estas serem filtradas. Por fim, o operador gather streams recebe vrias listas e junta-as numa nica lista. Todos os operadores mantm o formato e contedo da lista original. Aps a insero de todos os operadores necessrios, o resultado um plano de execuo que usa a paralelizao, e, consequentemente, vrios processos. O nmero de processos usados determinado pelo plano em si, nomeadamente pela complexidade do mesmo e pelo grau de paralelismo, ou seja, o nmero mximo de processos usados. O procedimento sp_configure permite configurar o grau de paralelismo, atravs das chamadas query hints. Estas permitem especificar quais os algoritmos usados no processamento da query. possvel definir entre muitos outros, o nmero mximo de paralelismo, se usado loop join, merge join, hash join, hash group order group.

2.6. Optimizao

Em relao optimizao de queries, isto feito pelas trs SGBDs estudadas. Em SQL Server, quando uma query submetida, esta passa por quatro passos (Figura 2.1).

Figura 2.6 - Processamento de uma query

Nos dois primeiros passos, verifica-se se a query vlida, e criado uma rvore, em que cada n representa uma operao lgica, como ler uma determinada tabela ou efectuar um inner join. Por exemplo, caso seja introduza a query: SELECT c.CustomerID, COUNT(*) FROM Sales.Customer c JOIN Sales.SalesOrderHeader o ON c.CustomerID = o.CustomerID WHERE c.TerritoryID = 4 GROUP BY c.CustomerID

Esta transformada na seguinte rvore(Figura 2.2):

Figura 2.7 - rvore derivada

A rvore recebida pelo query optimizer, responsvel pela optimizao, e nesse passo que so criados os diversos planos possveis. Ainda que no seja possvel gerar todos os planos possveis para uma dada query, so avaliados os custos dos planos gerados e escolhido um dos gerados, normalmente escolhido o de menor custo. De forma a explorar o conjunto de planos possveis, so usadas heursticas, para que o nmero de planos gerados seja limitado, limitando desta forma a quantidade de recursos e tempo usados para a gerao dos mesmos, tendo em conta que independentemente do plano escolhido, o resultado ter de ser invariavelmente o mesmo. A heurstica usada determina que ir ser procurado um plano de execuo com um custo menor ao encontrado at ao momento desde que esse custo seja alto o suficiente que compense essa pesquisa. Para estimar o plano mais eficiente estimado o custo de cada operao fsica nesse plano, usando formulas que tm em conta o uso de recursos como RAM, CPU e I/O. Este custo vai ento variar conforme o algoritmo usado e pelo nmero de entradas que tero de ser processadas. O custo de obter estas entradas calculado recorrendo

ao uso de estatsticas que descrevem a distribuio dos valores nas tabelas existentes. Aps o clculo dos custos, estes so somados para obter o custo total do plano. Este plano ento guardado numa estrutura chamado memo para que mais tarde se possa comparar os vrios planos e escolher o melhor. Este plano ento passado para a execution engine para ser executado, e possivelmente guardado em memria para ser mais tarde usado. Em PostgreSQL a estrutura do plano uma rvore em que ns nos nveis mais baixos representam operaes de mais baixo nvel, como scans em tabelas. Os custos das operaes mais acima na rvore inclui o custo dos seus descendentes, e no tido em conta os custos de operaes como mostrar os resultados por serem independentes do plano escolhido. Os custos destas operaes so medidos em unidades de disco lidas, sendo que 1.0 representa uma leitura sequencial. O custo do CPU tambm tido em conta, mas convertido para as mesmas unidades. Por exemplo, o custo duma query em comparao de a mesma query mas com uma clusula WHERE vai ser menor, pois a segunda vai necessitar verificar essa condio em todas as entradas da tabela. Esta clusula, WHERE, vai ter impacto no algoritmo escolhido para ler os dados. Se a clusula for restrita o suficiente, usado um ndex scan. Isto torna mais dispendioso ler os dados pois eles no so lidos de forma sequencial, mas devido ao seu reduzido nmero o custo acaba por ser compensado. Este tipo de scan tambm usado com clusulas do tipo ORDER BY. No caso de serem usadas clusulas WHERE sobre diferentes colunas da mesma tabela, dependendo de como a condio feita, o algoritmo escolhido ir ser diferente. Para isto so utilizadas estatsticas. Estas estatsticas no so constantemente actualizadas, mas tendem a reflectir o nmero de entradas numa dada tabela, e o nmero blocos ocupados em disco.

Para queries complexas que usem o operador join o PostgreSQL usa algoritmos genticos para ajudar a diminuir a complexidade das mesmas. Este algoritmo escolhe algumas possveis sequncias de joins aleatoriamente, e sequncias com menor custo so consideradas mais adequadas que as de maior custo. So ento geradas novas combinaes tendo em conta as sequncias de menor custo encontradas at ao momento. Isto repete-se um nmero pr-definido de vezes, e a sequncia de menor custo at ao momento a escolhida para o plano de execuo. Por este algoritmo ser no-determinista, existem parmetros de controlo que garantem que a mesma query produz sempre o mesmo resultado. Em Oracle existem duas possibilidades sobre o modo como feita a optimizao. Pode ser dada mais importncia ao tempo de resposta total, como em aplicaes em que o importante o resultado final, ou pode ser dada mais importncia ao tempo que demora at comearem a surgir resultados, como em aplicaes interactivas em que o utilizador apenas est interessado nos primeiros resultados. Esta possibilidade definida no parmetro OPTIMIZER_MODE. Para calcular qual o melhor custo so usadas estatsticas, guardadas num dicionrio. guardada informao sobre a forma como os dados esto guardados em disco e a distribuio de dados nas diferentes tabelas.

Figura 2.8 - Clculo do custo

Query Transformer recebe como entrada um conjunto de sub-queries, sendo que a estrutura da query original vai definir qual a estrutura destas sub-queries, e tenta determinar se esta estrutura a ptima ou se compensa muda-la. Aps isso, so geradas trs tipos diferentes de medidas, relacionadas entre si, e so estas medidas que vo estimar o custo de um determinado plano. Estas medidas so: Selectividade; Cardinalidade; Custo;

A primeira representa uma fraco das entradas de uma determinada lista. Esta lista pode ser uma tabela, uma vista, o resultado de um join ou de um operador GROUP BY. Pode estar tambm associado a um predicado WHERE, que ir actuar como um filtro, sendo que este filtro vai determinar quantas entradas vo ser seleccionadas. O valor da selectividade pode variar entre 0.0 e 1.0, em que 0.0 significa que que no existem entradas resultantes do filtro, e 1.0 indica que nenhuma entrada foi eliminada. Caso no existam estatsticas disponveis para o clculo da selectividade, so usados valores por defeito que vo ajudar no calculo.

Cardinalidade representa o nmero de entradas de uma determinada lista, aps serem efectuadas todas as operaes. O custo representa uma estimativa das unidades de trabalho necessrias para produzir o resultado final. Por exemplo, no caso de uma B-Tree, o custo vai depender do nmero de nveis, nmero de folhas e entradas lidas. O plan generator ir gerar vrios planos de execuo possveis e escolher o plano com o menor custo. Inicialmente so gerados sub-planos para cada uma das sub-queries, estes planos so ento usados para gerar os planos das queries de mais alto nvel. A query original ento a ltima a ser optimizada. O nmero de planos possveis tende a ser proporcional aos nmeros de joins existentes na query, tendendo a crescer exponencialmente. por isso imperativo tentar controlar esse nmero. O PostgreSQL tenta obter algoritmos genticos, e o Oracle usa parmetros internos que limitam o nmero de planos gerados. Este parmetro calculado automaticamente, conforme o plano de menor custo encontrado at ao momento. Caso o custo desse plano seja elevado, so criados vrios planos alternativos para as vrias possibilidades de calcular os joins. Caso o custo seja reduzido, ento no necessrio calcular alternativas pois gastaria-se recursos a tentar reduzir algo que j relativamente reduzido. O primeiro join a ser calculado o mais importante, pois esse que ir determinar o nmero de planos gerados. Por esse motivo usada uma heurstica simples que calcula primeiro os joins com menor cardinalidade e a partir da ir calcular os com maior cardinalidade.

2.7. Estimativa de Custos Oracle

recomendado estimar o espao de uma tabela antes da sua criao e recomenda-se tambm que tal estimativa faa parte do planeamento da base de dados. Os tamanhos estimados de tabelas, ndices, undo, space e redo log files podem ser

usados de uma forma combinada para determinar o tamanho em disco requerido para suportar a base de dados a criar e, por conseguinte, a tarefa de aquisio do hardware correcto torna-se algo mais facilitado. Tambm h que ter em conta a velocidade de crescimento da base de dados.

Um bom planeamento melhorar operaes de I/O em relao a performance e velocidade, por exemplo, se o planeamento do espao usado pelos indexes for bem feito, podemos estimar o tamanho mximo que estes vo ocupar e toda a informao sobre index vai ser alocada de uma maneira contgua no disco, melhorando o tempo de acesso para I/O em relao a operaes envolvendo indexes. O mesmo se aplica a tabelas.

Estimativa do espao usado de uma tabela O tamanho de uma base de dados pode variar muito dependendo do atributos de armazenamento, tamanho dos blocos, e muitos outros factores. O comando CREATE_TABLE_COST permite estimar o espao que custa criar uma tabela. Este procedimento tem duas variantes. A primeira usa o tamanho mdio de uma linha para estimar o espao, enquanto que a segunda usa informao sobre colunas para estimar o tamanho das tabelas. Para obter tais informaes precisamos dos seguintes inputs:

TABLESPACE_NAME - a tabela na qual o objecto vai ser criado. Por defeito usada a tabela SYSTEM; ROW_COUNT - o nmero antecipado de filas na tabela; PCT_FREE - a percentagem de espao livre que se quer reservar em cada bloco para futuras expanes de filas existentes devido a actualizaes.

A primeira variante requer tambm o tamanho mdio de filas, AVG_ROW_SIZE, enquanto que a segunda variante requer para cada valor de coluna antecipado para COLINFOS que inclui informao acerca da coluna (COL_TYPE e COL_SIZE). Este procedimento retorna dois valores:

Os bytes usados pelo procedimento, USED_BYTES.

A quantidade de espao antecipado para ser alocado pelo objecto, tendo em conta as caractersticas da tablespace.

Estimativa do espao usado por um index O comando CREATE_INDEX_COST estima o espao usado por um index numa tabela existente. So necessrios os seguintes inputs:

DDL: O comando CREATE INDEX que ir criar a tabela. A tabela especificada deve ser existente PLAN_TABLE: O nome do plano a ser usado. Por defeito NULL pois este parmetro opcional.

O resultado retornado depende das estatsticas acerca de um segmento, por isso requirida a obteno de estatsticas antes da execuo desta estimativa pois, se no houver estimativas actualizadas, o resultado poder ser errneo. So retornados os seguintes valores:

USED_BYTES - nmero de bytes representando o a informao do index ALLOC_BYTES - a quantidade de espao alocado para o index na tablespace.

Estimativa do tamanho do Cluster e Parametros de armazenamento A estimativa do tamanho do Cluster antes da sua criao trs benifcios:

Podemos combinar a estimativa do tamanho do Cluster com as estimativas dos indexes e redo log files para determinar a quantidade de espao de disco para albergar a base de dados pretendida; A estimativa do do tamanho de um cluster individual capacita-nos de visualizar melhor o tamanho que o Cluster vai ocupar em disco. Quando um cluster criado, possvel fornecer os parametros de armazenamento e melhorar operaes de I/O de aplicaes que utilizam o cluster.

Independentemente da estimao do tamanho de tabelas antes da sua criao, possvel estabelecer os parmetros de armazenamento ao criar uma tabela sem

cluster. O no fornecimento de tais parmetros implica a utilizao de parmetros activados por defeito. Isto acontece tambm com tabelas com cluster.

SQL Server
A qualidade dos planos de execuo que o Query Optimizer gera, est relacionado directamente com a preciso das estimativas de custo. Uma estimativa incorrecta pode levar a que o Query Optimizer escolha planos ineficientes tento, assim, uma diminuio na performance da base de dados. Durante a optimizao, o Query Optimizer explora os candidatos, determinando os seus custos e escolhe o plano que lhe parece ser o mais eficiente e preciso dado que tal plano vai ser usado diversas vezes durante a optimizao de queries. Os custos so estimados para planos completos ou parciais, sendo que a sua computao feita por operador e o custo total do plano a soma dos custos de todos os operadores desse mesmo plano. O custo de cada operador depende do seu algoritmo e do nmero estimado de records devolvidos, tendo em conta que cada operador tem um custo de CPU associado e, alguns deles, um custo de I/O. Alguns operadores, como Sort e Hash Join tambm consideram a memria disponvel no sistema. O SQL Server recolhe estatsticas de ndices e colunas e mantm-nas actualizadas automaticamente ( AUTO_UPDATE_STATISTICS ). Esta opo est ligada por defeito e pode ser desligada caso o utilizador do sistema assim o pretenda. O utilizador tem tambm a opo de accionar as estatsticas pretendidas ou criar as suas estatsticas ( CREATE_STATISTICS ). A optimizao de estatsticas feita atravs de algoritmos que processam quando se d um grande nmero de alteraes numa determinada coluna ou quando o tamanho da tabela aumenta. No Postgres, se se verificar que as estimativas de custo esto erradas, o que este faz , o custo total calculado a partir do custo por linha de cada n do plano vezes a

selectividade estimada do plano do n. Os custos estimados para tal plano podem ser ajustados a partir dos parmetros do tempo de execuo. A carncia de estatsticas poder levar a uma estimativas imprecisas. Tipos de Estimativas guardadas e como so usadas Estatsticas podem ser criadas numa ou mais tabelas, sendo que as estatsticas geradas automaticamente so geradas sobre apenas uma tabela. So guardadas vrias estatsticas de uma tabela: Nmero de linhas da tabela; Data da ltima actualizao; Tamanho mdio da chave; Densidade de combinaes das colunas;

As componentes mais importantes sobre as estatsticas so os histogramas, que so estruturas internas, e a densidade da informao. Os histogramas consistem na amostra de uma distribuio de dados sobre uma coluna ou ndices.

Postgres
O planner do PostgreSQL precisa de estimar o nmero de linhas que uma determinada consulta ir devolver de forma a conseguir boas estimativas e aproximaes para obter o melhor plano de execuo. Para tal necessrio guardar valores estatsticos sobre os dados da base de dados para que seja possvel efectuar tais anlises. Um constituinte das estatsticas no PostgreSQL o nmero total de entradas em cada tabela e em cada ndice nmero de blocos em disco ocupados por cada tabela e ndices A tabela de estatsticas guarda a seguinte informao: Nmero de linhas da tabela; Nmero de entradas em cada ndice; Nmero de blocos em disco ocupados por tabela;

Nmero de blocos em disco ocupados por ndices;

O query planner do Posgres, para devolver o melhor plano de execuo, precisa de ter determinar de uma forma precisa a cardinalidade, o que requer guardar os valores estatsticos, tal como as outras SGBDs estudadas, sobre os dados.

Consulta de planos no Postgres O comando EXPLAIN mostra-nos que plano que o query planner cria para qualquer query, mostra tambm que algoritmos de juno, ordenao, etc. so usados. A estrutura de um plano uma rvore de ns plano. Os ns de mais baixo nvel so ns resultado da explorao de tabelas, ou seja, so filas de uma tabela. Dentro deste tipo de ns h diferentes tipos, consoante o acesso a tabelas: sequencial, index e bitmap index. O output do EXPLAIN tem uma linha para cada n na rvore do planeamento, mostrando os tipos bsicos de ns junto com o custo estimado pelo planner para a execuo daquele n e o primeiro n, o n mais acima, tem o custo total estimado para o plano. este o nmero a minimizar pelo planner.

exemplo:

output: EXPLAIN SELECT * FROM tenk1; QUERY PLAN ------------------------------------------------------------Seq Scan on tenk1 (cost=0.00..458.00 rows=10000 width=244)

Os parmetros envolvidos so:

Analize - planeia e executa a consulta sendo disponibilizado o custo total da consulta; Verbose - mostra, de uma forma verbosa, no output, a rvore do planeamento da query; Statement - consulta SQL a visualizar o planeamento.

2.8. Comandos para parmetrizar a construo e uso de estimativas

No Postgres, as variveis envolvidas no planeamento de custos aqui descritas so medidas numa escala arbitrria. Somente os valores relativos entre si so relevantes e subi-los ou desce-los na escala irrelevante pois estas variaes so feitas atravs do mesmo facto, o que no trar nenhuma mudana na escolha do do query optimizer planner. Por defeito, esses custos so variaveis baseados no custo da busca sequncial de pginas. Outros parmetros de medio podem ser utilizados, como o tempo de execuo real em milissegundo numa mquina.

2.9. Transformaes
As regras de transformao tm como objectivo a explorao de um conjunto de planos de execuo possveis para uma dada query. Estas transformaes so baseadas em lgebra relacional, pegando nas rvores de operadores relacionais e gerando rvores alternativas equivalentes. Uma query consiste em expresses qual, aplicando um conjunto de regras de transformao, so geradas alternativas equivalentes, que so guardadas na memria enquanto o processo de optimizao se d.

O Query Optimizer do SQL Server opera em trs estados de optimizao e diferentes regras de transformao so aplicadas em cada estado.

Cada regra de transformao tem um padro e um substituto. O padro a expresso a ser analisada e o substituto a expresso equivalente que gerada como um output. Um exemplo do SQL Server: para a regra comutativa, uma regra de transformao pode ser definida do seguinte modo Expr1 join Expr2 > Expr2 join Expr1. O SQL Server vai fazer uma equivalncia de padres entre Expr1 join Expr2, como em Individual join Customer, e produzir uma expresso equivalente, Customer join Individual. Ambas as expresses retornam o mesmo resultado.

Em SQL Server, os principais tipos de regras de transformao so: simplificao - produzem rvores lgicas mais simples como output e so maioritariamente usadas durante a fase se simplificao antes da optimizao total; explorao - estas so as chamadas transformaes lgicas. Geram alternativas lgicas equivalentes; regras de implementao - conhecidas tambm como regras de transformao fsicas. So usadas para obter alternativas fsicas.

As regras de explorao e de implementao so executadas durante a fase de optimizao total. Passamos a dar um exemplo para as regras de explorao comutativa e associativa, que so usadas na optimizao de join. As regras comutativas e associativas so definidas como A join B > B join A e (A join B) join C > A join (B join C) respectivamente. A regra comutativa A join B > B join A, significa que A join B equivale a B join A, ou seja, ambos produzem o mesmo resultado.

importante lembrar que ao aplicarmos as regras de transformao no estamos, necessariamente, a reduzir os custos nas alternativas geradas. Os custos continuam a ter de ser calculados.

O sistema de regras do Postgres suporta sistemas de regras bastante poderosos. Originalmente, o sistema de regras consistia em duas implementaes: A primeira operava usando processamento de linhas e estava implementado no executor. Este sistema era chamado quando uma linha era acedida. Esta implementao caiu em desuso. A segunda implementao do sistema de regras uma tcnica chamada query rewriting. O rewrite system um modulo que se encontra entre o parser stage e o planner/optimizer. Esta tcnica continua a ser implementada.

Em relao ao Postgres, o Query Optimizer tem 2 etapas para este processo: Gera uma rvore, a chamada query tree que , posteriormente, entregue ao Rewrite System; O Rewrite System, tendo a query tree, aplica-lhe um conjunto definido de regras (user dened rules) devolvendo zero ou mais query trees equivalente para serem utilizadas pelo planeador.

As trs SGBDs utilizam a regra de equivalncia que verifica se duas expresses diferentes retornam o mesmo resultado.

A SGBD Oracle divide as transformaes em 3 tipos: Automatic produzem sempre o plano mais rpido; Heuristic-based - Assume-se que produzem o plano mais rpido maior parte das vezes. O utilizador tem de fornecer os parmetros neste tipo de transformao; Cost-based - Nem sempre produz a query mais rpida. O query optimizer verifica o custo das queries no transformadas e das transformadas e escolhe o que tiver menor custo entre todas. No necessrio o fornecimento de parmetros.

A seguir apresentada a lista incompleta: CBQT - cost-based query transformation JPPD - join predicate push-down OJPPD - old-style (non-cost-based) FPD - filter push-down PM - predicate move-around CVM - complex view merging SPJ - select-project-join SJC - set join conversion SU - subquery unnesting OBYE - order by elimination ST - star transformation CNT - count(col) to count(*) transformation JE - Join Elimination

Uma transformao em particular a Star Transformation. Esta uma poderosa tcnica de optimizao que visa transformar implicitamente o SQL da star query original. O query optimizer do Oracle escolhe automaticamente este tipo de transformao quando apropriado. O Oracle processa a star query usando duas fases bsicas: 1 - obtm as filas necessrias da tabela utilizando ndices bitmap. muito eficiente. 2 - junta o resultado dimenso das tabelas. Um exemplo simples de star query o seguinte: "Quais foram as vendas e lucros para o departamento de mercearia de lojas no norte e no sul nos ltimos trs meses?"

O optimizador opera em trm passos 1. Todas as vistas possveis de juntar so juntas; 2. O optimizador executa o teste do bloco de consulta; 3. O optimizer reescreve a consulta usando visualizaes em linha. Aps a query ser reescrita esta executada e a informao retornada ao utilizador.

3. Concluso
Pode-se concluir que a optimizao das queries um pedao crtico de um Sistema de Gesto de Base de Dados, da ser bem implementado e estudado pelas trs SGBDs estudadas neste trabalho. No entanto ainda existem objectivos a ser melhorados, principalmente com a evoluo da velocidade de computao que tem vindo a aumentar. Um desses pontos que podem ser melhorados o estudo de todos os planos possveis para a execuo de uma dada query. Neste momento, necessrio encontrar um balano entre o tempo gasto a encontrar o plano ptimo, e o tempo que esse plano ajudar a reduzir. No entanto, com o aumento da velocidade de computao, ser possvel cada vez estudar mais planos e encontrar que , de facto, o plano ptimo. Isto leva-nos a outro desafio tcnico que poder ser possvel melhorar, num futuro talvez no distante: estimar o custo e cardinalidade das operaes. Por ser o escolhido o plano de execuo com o menor custo, a qualidade deste to boa quanto a qualidade estimativas do custo e cardinalidade. Mesmo que o tempo no seja algo problemtico, e que seja possvel analisar todos os planos de execuo possveis, no so consideradas todas as possibilidades de hardware e as condies em que os dados so lidos. Por exemplo, ao estimar o custo de leitura dos dados assumese que os dados so lidos do disco, quando estes podem estar a ser lidos da memria, havendo uma discrepncia entre o tempo estimado e o tempo real. Devido forma como os planos de execuo so feitos, em forma de uma rvore, estas pequenas discrepncias vo sendo somadas e quando chegam raiz da arvore a discrepncia entre os pontes pode ser maior que a desejada. Em relao paralelizao de queries, ao contrrio do SQL Server e do Oracle, o PostgreSQL no tem esta funcionalidade implementada, visto ela no ser considerada uma funcionalidade essencial. No entanto, em relao optimizao de queries todas tm uma implementao bastante completa, devido a ser um pedao crtico de um Sistema de Gesto de Base de Dados.

 tambm interessante notar que a documentao existente, no mbito deste trabalho, sobre Oracle, tanto oficial como no oficial, bastante completa e fcil de encontrar. Por seu lado, a informao oficial sobre SQL Server escassa, principalmente sobre as verses mais recentes, mas existe bastante documentao no oficial. E, finalmente, existe pouca informao disponvel sobre PostgreSQL, tanto oficial como no oficial.

4. Bibliografia

http://www.orafaq.com/wiki/Parallel_Query_FAQ http://markmail.org/message/2t3nrzg72gpgcvvq http://www.simple-talk.com/sql/sql-training/the-sql-server-query-optimizer/ http://www.akadia.com/services/ora_parallel_processing.html http://msdn.microsoft.com/en-us/library/ms178065.aspx