Sistemas de Base de Dados

Transcrição

1 Sistemas de Base de Dados Comparação entre PostgreSQL, Oracle e Microsoft SQL Server dos mecanismos para processamento e optimização de perguntas Grupo 17 Elaborado por: Diogo Brito, nº37739 João Costa, nº Pedro Pires, nº25806 Dezembro 2011

2 Índice: 1. Introdução Microsoft SQL Server Oracle PostgreSQL Comparação Linguagem Intermédia Implementação de operações básicas Algoritmos suportados Mecanismos para consultar planos Paralelização de Queries Optimização Estimativa de Custos Comandos para parâmetrizar a construção e uso de estimativas Transformações Conclusão Bibliografia... 38

3 Índice de imagens Figura Pipelining base de uma query... 9 Figura Representação de uma query Figura 2.3 Operadores Figura Hash Join Figura Funcionamento do Hash Join Figura Processamento de uma query Figura Árvore derivada Figura Cálculo do custo... 25

4 1. Introdução A análise do processamento de perguntas num sistema de gestão de base de dados (SGBD) surge pela necessidade de optimização das mesmas. Apesar de numa base de dados de pequena escala a optimização poder não ter grande impacto, numa base de dados de grande escala a forma como as perguntas são particionadas internamente pode reduzir o tempo de resposta a uma dada pergunta. Geralmente as SGBDs estão divididas em duas partes. Uma que gere e controla os dados guardados, sendo responsável pela gestão destes. A segunda é responsável por receber uma query e produzir o output da mesma. Para isto primeiro é criado um plano de execução e, após o plano estar completo, este é executado. Este plano é feito através da transformação da operação lógica original em operações físicas. Uma operação lógica pode estar associada a apenas operação física, como é o caso da ordenação, ou pode estar associada a mais, por exemplo, transformar um join num nested loop join, merge join ou hash join. Para a elaboração dos planos são usadas estatísticas, para que seja possível 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 relatório vai recair. Como são elaborados planos e como estes podem ser optimizados. Para a elaboração deste trabalho foram escolhidas, para além 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 documentação existente sobre as mesmas.

5 1.1. Microsoft SQL Server Desenvolvido pela Microsoft em parceria com a Sybase em 1988 aparece como um produto complementar do Windows NT. A versão mais actual é o SQL Server 2008 R2 mas espera-se já uma nova versão em As principais linguagens que aceita são Transact SQL (T-SQL) e ANSI SQL. É um sistema de gestão de bases de dados que pode funcionar tanto localmente apenas num computador como em vários ao mesmo tempo, mesmo pela internet Oracle Lançada 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 disponível comercialmente. Os objectos e funções guardados podem ser invocados pela linguagem PL/SQL, linguagem proprietatia da Oracle Coorperation, ou por Java. A última versão é Oracle 11g PostgreSQL O PostgresSQL é uma SGBD desenvolvida na Universidade da Califórnia no Berkeley Computer Science Department. Esta SGBD foi pioneira em diversos conceitos que só foram implementados em SGBDs comerciais vários anos mais tarde.

6 Esta SGBD é open-source que nasceu no final dos anos 70 a partir de um projecto académico. Antes do nome Postgres ser adoptado este tinha como nome INGRES (INteractive Graphics REtrieval System). São suportadas vários standards do SQL bem como novas operações: Queries complexas; Chaves externas; Triggers; Vistas; Integridade de transacções; Controlo de concorrência; 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 trás conseguindo implementar um largo número de operações sendo que a primeira versão, ainda que não finalizada, surgiu em Em 1990 o sistema foi redesenhado com um novo sistema de regras e, em 1991, surgiu uma versão melhorada suportando múltiplos gestores de armazenamento, um executante de queries melhorado e o sistema de regras foi reescrito. Como podemos constatar através dos factos referidos atrás, o PostgreSQL evoluiu de uma maneira acelerada, no entanto, em 1994 surgiu uma versão que revolucionou o projecto. Esta versão é a chamada POSTGRES95 e foi desenvolvida por dois alunos, Andrew Yu e Jolly Chen. O que se destaca esta versão é o facto de ter um interpretador da linguagem SQL. Esta versão foi disponibilizada na internet numa versão opensource, juntamente com um tutorial o que facilitou e impulsionou o desenvolvimento da SGBD. O Posrgres possibilita também a adição de novos tipos de dados, funções, operadores, funções agregadas, métodos de index e linguagens procedimentais (PL/pgSQL, PL/Perl, PL/Java, PL/Ruby, etc.).

7 O facto de o Posrgres ser open-source torna possível e gratuita a sua modificação quer seja por privados, comerciais ou com objectivos académicos, e é de realçar que várias 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.

8 2. Comparação 2.1. Linguagem Intermédia Uma linguagem intermédia é a linguagem desenhada para correr numa máquina abstracta e é usada muitas vezes pelos compiladores como, tal o nome indica, uma linguagem intermédia antes de passar para a linguagem máquina. Isto existe pois é uma linguagem que pode ser independente do CPU e ao mesmo tempo da linguagem de programação 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 máquina. Este tipo de linguagens intermédias são utilizadas pelos compiladores e também 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 código de sistema e é formado um pacote que é gravado na base de dados; no momento de execução estes são carregados para a memória partilhada e o código é executado. Na memória partilhada um pacote está limitado a 2^26 nós de DIANA o que corresponde a cerca de 6 milhões de linhas de código. O SQL Server utiliza o MSIL, como referido anteriormente. O MSIL: Microsoft Intermediate Language mas actualmente denominada por Common Intermediate Language. Esta linguagem é também utilizada por todas as outras.net Languages (C#, VB.NET, ASP.NET).

9 2.2. Implementação de operações básicas Figura Pipelining base de uma query Quando uma query é compilada o código é primeiro traduzido para uma representação equivalente em árvore. Depois, e caso a query tenha uma sintaxe SQL válida, um conjunto de verificações é efectuado para verificar se o utilizador tem acesso às tabelas e colunas pertencentes à arvore, tal como é verificado se estas existem. É ainda neste passo que são efectuadas verificações de semântica para garantir que são válidas e que, por exemplo, as colunas enumeradas num GROUP BY são válidas no caso em questão. Quando é completa a árvore da query e se verificou que a query está totalmente correcta então entra em acção a optimização. 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 representação da query em árvore é atribuído a cada operação 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= poderá ser representado internamente.

10 Figura Representação 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 operação lógica numa física, como exemplo, transforma um JOIN lógico (neste caso um INNER JOIN) num JOIN físico (Hash, merge ou nested). SQL Server tem cerca de 40 operadores lógicos e ainda mais operadores físicos. Alguns dos mais comuns irão ser focados, como o JOIN ou SELECT e outros mais específicos, como UDX ou Segment, não serão abordados. Operadores: Todos os operadores, em SQL Server, funcionam por pedidos de linhas aos seus nós filhos e, depois, retornando linhas aos nós que o chamam (pais), como no exemplo a seguir.

11 Figura 2.3 Operadores Cada operador retorna uma linha de cada vez, por isso, um caller terá de fazer vários pedidos para obter várias linhas. O nó caller poderá ser um operador pai ou o utilizador, que irá receber a resposta da query. Existem três tipos de join físico: HASH JOIN MERGE JOIN NESTED LOOP JOIN Em queries pequenas, que afectam um número reduzido de valores, o nested loop join é muito superior em relação 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 código SQL:

12 Figura Hash Join Um hash join utiliza duas entradas, uma de construção e uma de indicação. A entrada de construção é mostrada no topo enquanto a de indicação, é mostrada em baixo. A mais pequena das duas entradas é escolhida para ser a de construção. A operação é feita em duas fases: a de construção e a de indicação. O caso mais comum de hash join é o in-memory hash join, onde na primeira fase, o conjunto de entrada de construção é totalmente consultado e, depois, uma tabela de hash é escrita em memória. 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 indicação onde, para cada linha na entrada de indicação, é gerada uma chave de hash. Então, no correspondente conjunto de hash para aquela chave, é pesquisada a chave da entrada de indicação e são gerados os valores comuns. A figura seguinte ilustra bem como é feito.

13 Figura Funcionamento do Hash Join Este tipo de pesquisa é usado maioritariamente quando existem um grande número de dados, tipicamente não ordenados e não indexados. Merge Join Neste tipo de query é necessário que ambas as entradas estejam ordenadas nas colunas que estão a ser misturadas. Se houver índices disponíveis em ambas as colunas de entrada então é obtida uma linha de cada uma, são 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

14 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 não esteja indexada na coluna em questão é, então, necessário usar um hash join Algoritmos suportados Os índices são 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 contrário podendo aumentar o tempo de resposta. Sendo uma das melhores formas de reduzir as leituras/escritas do disco permite encontrar informação 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 informação necessária podemos ir directamente para a página que nos interessa. Há duas operações básicas que podem ser aplicadas através do índice: Pesquisa (por um valor ou um conjunto de valores na chave do índice); Percorrer o índice (para a frente ou para trás); Para a pesquisa, o operador inicial começa na raiz da árvore B+ e navega em profundidade até ao local desejado, baseado nas chaves dos índices. Uma vez completo é então possível 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.

15 Uma vez que os nós de folha numa árvore B+ (usada pelo SQL Server) estão ligados então é possível consultar linhas ordenadamente à medida que se navega por esses mesmos nós. Uma das tarefas com Optimizador de Query é o de assimilar quais predicados poderão ser aplicados a um certo índice para retornar linhas o mais rápido possível; alguns podem ser aplicados a um índice enquanto outros não. Os predicados que podem ser convertidos em índices são muitas vezes denominados sargable, de significado Search-ARGument-able, enquanto os que não podem são denominados non-sargable. Estes últimos seriam normalmente aplicados depois de uma pesquisa ao índice ou após 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 questões de optimização. Caso não o fizesse os passos seriam: 1. Operador de pesquisa: Pesquisar uma chave no índice da árvore B+; 2. Trancar a página; 3. Ler a linha; 4. Libertar a página; 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 não, voltar a 2; No entanto, esta opção é mais lenta que a óptima pois retornar a linha para um outro operador exige carregar um novo conjunto de instruções e dados para o CPU. Se o conjunto da operação for mantido apenas num sítio, o custo geral de CPU irá baixar. Os passos são: 1. Operador de pesquisa: Pesquisar uma chave no índice da árvore B+; 2. Trancar a página; 3. Ler a linha; 4. Aplicar o filtro non-sargable. Se não passar o filtro ir para o passo 3, se não ir para 5;

16 5. Libertar a página 6. Retornar a linha Isto é chamado de injectar predicados non-sargable, pois o predicado passa duma operação exterior para dentro da pesquisa/percorrer. É uma optimização física mas pode aparecer em queries que processem muitas entradas. No entanto nem todos os predicados podem ser avaliados desta forma pois, como trancar uma página bloqueia até o acesso de outros utilizadores a consultarem, então esta operação está reservada apenas a predicados que não sejam muito pesados em termos de custo. São os chamados predicados non-pushable, non-sargable Mecanismos para consultar planos Quando se trabalha com sistemas com um tamanho considerável e que exijam resultados rápidos/consistentes, muitas vezes é necessário recorrer a ferramentas que permitam verificar se as queries estão correctas, o que se está a passar por detrás 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 também os planos que estão por detrás das chamadas que são feitas, podendo verificar-se as decisões 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 gráfico 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 informação sobre queries em background Analisar a performance do sistema Diagnosticar problemas como deadlocks Fazer debug a uma sintaxe T-SQL

17 Permite também 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 são referenciadas no pedido; Método de acesso por cada tabela mencionada; Método de join para cada tabela afecta a um operador de join; Operadores de dados como filter, sort ou aggregation; Para além da informação na árvore é ainda possível ver informação sobre: Optimização, como o custo e cardinalidade de cada operação; Particionamento, como o conjunto de partições a que se acedeu; Execuções paralelas, como a distribuição de métodos 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 ]

18 FORMAT { TEXT XML JSON YAML } Este comando permite fazer consultas semelhantes à ferramenta anterior, do Oracle. Para além desta ferramenta existe ainda outra que é a tkprof Paralelização de Queries Paralelização de queries é a tecnologia usada para dividir um comando SQL em vários e distribui-los por dois ou mais processadores. Funções 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 começado a desenvolver paralelização de queries, o projecto foi abandonado pouco tempo depois. Como tal, apesar de ser uma das features mais comuns vistas em SGBDs, o PostgreSQL não tem esta função implementada. É considerada algo útil em apenas poucas situações e como tal não é 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 paralelização, o processo principal torna-se o coordenador da paralelização, com as seguintes responsabilidades: Divide o trabalho em unidades mais pequenas; Cria um número suficiente de processos paralelos que possam executar os subtrabalhos; Atribui os sub-trabalhos aos processos; Liberta os processos após o fim do processamento do trabalho; Vai atribuindo novos sub-trabalhos aos processos livres até a execução da query finalizar;

19 Para que haja paralelização num comando do tipo Select, é necessário que este cumpra alguns requisitos: Pelo menos uma das tabelas é acedida através de um full-table scan ou um índex range scan; Se a execução envolver um full-table scan (respectivamente, índex range scan), é necessário indicar a tabela correspondente ou definir a tabela com uma indicação de paralelização (respectivamente, indicar o índex correspondente ou declarar o índex com indicação de paralelização); A paralelização 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 parâmetros como o número mínimo e máximo de processos em paralelos, ou fazer com que estes parâmetros sejam controlados automaticamente. O valor tanto do número máximo de processos paralelos como do valor mínimo tem de ser balanceado. O número mínimo de processos paralelos tem de ser alto o suficiente para evitar seja necessário estar sempre a criar processos novos. O valor por defeito é 0. Por seu lado, o valor máximo, se for muito alto, irá tentar consumir mais recursos do que os disponíveis, acabando por prejudicar na performance da execução. É também possível indicar o número de processos associados com uma determinada operação. Tal operação é feita com o seguinte comando: SELECT /*+ PARALLEL(orders,4,1) */ ; Em Oracle operações como inserções, actualizações e deletes também pode beneficiar de paralelização. Para paralelizar updates e deletes é necessário que as tabelas estejam particionadas, e que diferentes partições sejam usadas. Ou seja, tem-se diferentes processos a fazerem pesquisas em diferentes partições.

20 Em SQL Server, a paralelização é feita automaticamente, apesar de não ser usada caso aconteça uma das seguintes situações: O custo de execução da query não é alto o suficiente para que seja considerado uma alternativa em que seja usado algum tipo de paralelismo; O plano de execução paralelizado tem um custo maior que um nãoparalelizado; A query contém instruções que não podem ser paralelizadas. Dependendo da instrução, isto pode causar que parte do plano, ou o plano na sua totalidade, não seja paralelizado. Durante a criação do plano de execução, o SQL Server vai colocando operadores para preparar a query para ser executada em paralelo. Este operador faz a gestão dos processos e gestão dos dados. Existem três tipos de operadores, sendo que um ou mais podem aparecer no plano de execução: distributed streams, repartition streams e gather streams. O primeiro recebe como parâmetro uma lista e divide-a em múltiplas listas. Estas sub-listas mantêm o mesmo formato, conteúdo e ordem que a lista original, apesar de uma entrada poder aparecer em mais que uma sub-lista. O segundo operador, repartition stream, recebe múltiplas listas e devolve múltiplas listas após estas serem filtradas. Por fim, o operador gather streams recebe várias listas e junta-as numa única lista. Todos os operadores mantêm o formato e conteúdo da lista original. Após a inserção de todos os operadores necessários, o resultado é um plano de execução que usa a paralelização, e, consequentemente, vários processos. O número de processos usados é determinado pelo plano em si, nomeadamente pela complexidade do mesmo e pelo grau de paralelismo, ou seja, o número máximo de processos usados. O procedimento sp_configure permite configurar o grau de paralelismo, através das chamadas query hints. Estas permitem especificar quais os algoritmos usados no processamento da query. É possível definir entre muitos outros, o número máximo de paralelismo, se é usado loop join, merge join, hash join, hash group order group.

21 2.6. Optimização Em relação à optimização de queries, isto é feito pelas três SGBDs estudadas. Em SQL Server, quando uma query é submetida, esta passa por quatro passos (Figura 2.1). Figura Processamento de uma query Nos dois primeiros passos, verifica-se se a query é válida, e é criado uma árvore, em que cada nó representa uma operação lógica, 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

22 Esta é transformada na seguinte árvore(figura 2.2): Figura Árvore derivada A árvore é recebida pelo query optimizer, responsável pela optimização, e é nesse passo que são criados os diversos planos possíveis. Ainda que não seja possível gerar todos os planos possíveis para uma dada query, são 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 possíveis, são usadas heurísticas, para que o número de planos gerados seja limitado, limitando desta forma a quantidade de recursos e tempo usados para a geração dos mesmos, tendo em conta que independentemente do plano escolhido, o resultado terá de ser invariavelmente o mesmo. A heurística usada determina que irá ser procurado um plano de execução 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 operação física nesse plano, usando formulas que têm em conta o uso de recursos como RAM, CPU e I/O. Este custo vai então variar conforme o algoritmo usado e pelo número de entradas que terão de ser processadas. O custo de obter estas entradas é calculado recorrendo

23 ao uso de estatísticas que descrevem a distribuição dos valores nas tabelas existentes. Após o cálculo dos custos, estes são somados para obter o custo total do plano. Este plano é então guardado numa estrutura chamado memo para que mais tarde se possa comparar os vários planos e escolher o melhor. Este plano é então passado para a execution engine para ser executado, e possivelmente é guardado em memória para ser mais tarde usado. Em PostgreSQL a estrutura do plano é uma árvore em que nós nos níveis mais baixos representam operações de mais baixo nível, como scans em tabelas. Os custos das operações mais acima na árvore inclui o custo dos seus descendentes, e não é tido em conta os custos de operações como mostrar os resultados por serem independentes do plano escolhido. Os custos destas operações são medidos em unidades de disco lidas, sendo que 1.0 representa uma leitura sequencial. O custo do CPU também é tido em conta, mas é convertido para as mesmas unidades. Por exemplo, o custo duma query em comparação de a mesma query mas com uma cláusula WHERE vai ser menor, pois a segunda vai necessitar verificar essa condição em todas as entradas da tabela. Esta cláusula, WHERE, vai ter impacto no algoritmo escolhido para ler os dados. Se a cláusula for restrita o suficiente, é usado um índex scan. Isto torna mais dispendioso ler os dados pois eles não são lidos de forma sequencial, mas devido ao seu reduzido número o custo acaba por ser compensado. Este tipo de scan é também usado com cláusulas do tipo ORDER BY. No caso de serem usadas cláusulas WHERE sobre diferentes colunas da mesma tabela, dependendo de como a condição é feita, o algoritmo escolhido irá ser diferente. Para isto são utilizadas estatísticas. Estas estatísticas não são constantemente actualizadas, mas tendem a reflectir o número de entradas numa dada tabela, e o número blocos ocupados em disco.

24 Para queries complexas que usem o operador join o PostgreSQL usa algoritmos genéticos para ajudar a diminuir a complexidade das mesmas. Este algoritmo escolhe algumas possíveis sequências de joins aleatoriamente, e sequências com menor custo são consideradas mais adequadas que as de maior custo. São então geradas novas combinações tendo em conta as sequências de menor custo encontradas até ao momento. Isto repete-se um número pré-definido de vezes, e a sequência de menor custo até ao momento é a escolhida para o plano de execução. Por este algoritmo ser não-determinista, existem parâmetros de controlo que garantem que a mesma query produz sempre o mesmo resultado. Em Oracle existem duas possibilidades sobre o modo como é feita a optimização. Pode ser dada mais importância ao tempo de resposta total, como em aplicações em que o importante é o resultado final, ou pode ser dada mais importância ao tempo que demora até começarem a surgir resultados, como em aplicações interactivas em que o utilizador apenas está interessado nos primeiros resultados. Esta possibilidade é definida no parâmetro OPTIMIZER_MODE. Para calcular qual o melhor custo são usadas estatísticas, guardadas num dicionário. É guardada informação sobre a forma como os dados estão guardados em disco e a distribuição de dados nas diferentes tabelas.

25 Figura Cálculo 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. Após isso, são geradas três tipos diferentes de medidas, relacionadas entre si, e são estas medidas que vão estimar o custo de um determinado plano. Estas medidas são: Selectividade; Cardinalidade; Custo; A primeira representa uma fracção 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 também associado a um predicado WHERE, que irá actuar como um filtro, sendo que este filtro vai determinar quantas entradas vão ser seleccionadas. O valor da selectividade pode variar entre 0.0 e 1.0, em que 0.0 significa que que não existem entradas resultantes do filtro, e 1.0 indica que nenhuma entrada foi eliminada. Caso não existam estatísticas disponíveis para o cálculo da selectividade, são usados valores por defeito que vão ajudar no calculo.

26 Cardinalidade representa o número de entradas de uma determinada lista, após serem efectuadas todas as operações. O custo representa uma estimativa das unidades de trabalho necessárias para produzir o resultado final. Por exemplo, no caso de uma B-Tree, o custo vai depender do número de níveis, número de folhas e entradas lidas. O plan generator irá gerar vários planos de execução possíveis e escolher o plano com o menor custo. Inicialmente são gerados sub-planos para cada uma das sub-queries, estes planos são então usados para gerar os planos das queries de mais alto nível. A query original é então a última a ser optimizada. O número de planos possíveis tende a ser proporcional aos números de joins existentes na query, tendendo a crescer exponencialmente. É por isso imperativo tentar controlar esse número. O PostgreSQL tenta obter algoritmos genéticos, e o Oracle usa parâmetros internos que limitam o número de planos gerados. Este parâmetro é calculado automaticamente, conforme o plano de menor custo encontrado até ao momento. Caso o custo desse plano seja elevado, são criados vários planos alternativos para as várias possibilidades de calcular os joins. Caso o custo seja reduzido, então não é necessário 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 número de planos gerados. Por esse motivo é usada uma heurística simples que calcula primeiro os joins com menor cardinalidade e a partir daí irá calcular os com maior cardinalidade Estimativa de Custos Oracle É recomendado estimar o espaço de uma tabela antes da sua criação e recomenda-se também que tal estimativa faça parte do planeamento da base de dados. Os tamanhos estimados de tabelas, índices, undo, space e redo log files podem ser