aula 1 - 2014 b

Aula 1

Programao e Otimizao em

SQL CET - 0604

Especializao Engenharia e Administrao de

Sistemas de Banco de Dados

Prof. Dr. Luiz Camolesi Jnior FT / UNICAMP - Limeira

Janeiro de 2014 copyrights reserved

CET 0604 Programao e Otimizao em SQL Especializao em Engenharia e Administrao de Sistemas de Banco de Dados -- FFTT / UUNNIICCAAMMPP

Prof. Luiz Camolesi Junior Pg. 2 /Aula 1

A. Expresses Lgicas Na avaliao e comparao de desempenho de uma expresso condicional (lgica) necessrio estabelecer tcnicas que, combinadas, possam apoiar projetistas e desenvolvedores na melhor configurao de uma expresso condicional.

1. Modelo de Sentena Condicional

Todos os desenvolvedores de SGBDs recomendam que uma sentena condicional seja elaborada seguindo o modelo:

Neste formato, o otimizador pode rapidamente reconhecer um ndice que poder ser utilizado para melhorar o desempenho da pesquisa.

Em pesquisas utilizando mais de uma tabela, o otimizador ir analisar a tabela que deve ser a base do filtro de seleo. Esta tabela base (conhecida como Driver) oferece um ganho de desempenho para os filtros seguintes no comando de pesquisa.

2. Classificao de Operadores e Operandos

A tcnica baseada em Pontuao (ou peso) unitria de cada operando e operador permite um avaliao bastante direta e rpida do possvel desempenho de avaliao de uma expresso lgica.

SELECT * FROM Table_1 WHERE coluna_1 = 12345;

SELECT * FROM Table_1 WHERE 12345 = coluna_1;

melhor

que

SELECT * FROM Table_1, Table_2 WHERE coluna_1 > 5 AND Table_1.coluna_2 = Table_2.coluna_2;



Tabela 1. Pontuao de Operadores Condicionais

OPERADOR PONTUAO = 1 > 3 >= 3 < 3



SELECT * FROM Table_1 WHERE colunainteira_1 = '12345';

Resultado PONTUAO: 7 2 pontos, coluna sozinha (a esquerda) 3 pontos, operando do tipo nmerico inteiro 1 pontos, operador de = 1 pontos, valor numrico sozinho ( direita)

anlise

SELECT * FROM table_1 WHERE colunachar_2 >= (colunavarchar_3 || 'x');

Resultado PONTUAO: 30 2 pontos, operando de caracter sozinho esquerda (colunachar_2) 10 pontos, operando de caracter (colunachar_2) 3 pontos, operador de >= 5 pontos, expresso com multi-operandos direita (colunavarfchar_3 || 'x') 10 pontos, operando de caracteres (colunavarchar_3)

anlise

SELECT * FROM Table1 WHERE coluna_data = CURRENT_DATE AND coluna_inteira * 5 > 100.00 PONTUAO: 5 + 2 + 1 + (4) + 3 + 3 + 3 + (5) = 26

SELECT * FROM Table1 WHERE coluna_data = DATE '2002-01-01' AND coluna_inteira * 5 > 100 PONTUAO: 5 + 2 + 1 + (5) + 3 + 3 + 3 + (3) = 25

compare com



3. Combinao de Operadores Lgicos

AND

Seqncias de sentenas lgicas agrupadas por operadores AND so avaliadas da esquerda para a direta nos SGBDs, exceto no Oracle quando o otimizador baseado em custo est ativo. Na composio desta seqncia, coloque as sentenas mais simples para serem avaliadas primeiramente e destas preferencialmente as sentenas de maior impacto (maior quantidade de falsos).

OR

Seqncias de sentenas lgicas agrupadas por operadores OR so avaliadas da esquerda para a direta nos SGBDs, exceto no Oracle quando o otimizador baseado em custo est ativo. Na composio desta seqncia coloque as sentenas mais simples para serem avaliadas primeiramente e destas preferencialmente as sentenas de maior impacto (maior quantidade de verdadeiros).

IN

O operador IN pode oferecer duas vantagens. Uma expresso condicional mais compacta que leva a uma programao mais elegante e a uma transmisso mais eficiente do comando entre aplicativo e SGBD em uma rede. A outra vantagem um desempenho ligeiramente melhor do que a utilizao de uma seqncia de sentenas combinadas com OR.

( ) AND ( ) AND ( ) AND ( )

( ) OR ( ) OR ( ) OR ( )



LIKE

O operador LIKE bastante dispendioso de recurso de processamento. Se a comparao que se deseja for sobre uma string totalmente definida, utilize o operador = para obter melhor eficincia. Os caracteres coringa (% e _ ) que podem ser usados para especificar uma string parcialmente definida devem ser evitados, quando possvel, nas primeiras posies da cadeia de caracteres, para assim, existirem mais probabilidade de casos de falso ocorrem com pouco processamento do algoritmo de busca de substring.

UNION, UNION ALL

Com UNION, no so includos no result set as tuplas repetidas, ou seja, internamente realizado um operando DISTINCT. Com UNION ALL, as tuplas repetidas so mantidas no result set, Assim, deve-se analisar h necessidade e possibilidade de obteno de valores repetidos no resultado da consulta, pois o UNION ALL tem melhor desempenho que o operador UNION.

Em casos de similaridade de resultados, os substitutos naturais (combinaes de operadores AND ou OR) oferecem o mesmo desempenho.

Este operador pode proporcionar, quando disponvel, o processamento paralelo de cada SELECT em um servidor.

SELECT * FROM Table_1 WHERE coluna_2 IN (1, 2, 3, 5);

SELECT * FROM Table_1 WHERE (coluna_2 BETWEEN 1 AND 5) AND (coluna_2 4);

SELECT * FROM Table_1 WHERE coluna_2 >= 1 AND coluna_2



MINUS (EXCEPT), INTERSECT

Em casos de similaridade de resultados, os substitutos naturais (combinaes de operadores AND ou OR) oferecem o mesmo desempenho. Estes operadores podem proporcionar, quando disponvel, o processamento paralelo de cada SELECT em um servidor.

SELECT * FROM Table_1 WHERE coluna_1 > 5 UNION SELECT * FROM Table_1 WHERE coluna_1 < 2;

SELECT DISTINCT * FROM Table_1 WHERE coluna_1 > 5 OR coluna_1 < 2;

equivalente

a



NOT

O operador NOT oferece algum atraso na anlise de uma condio. Recomenda-se a eliminao, quando possvel deste operado, invertendo-se a condio de anlise.

4. Organizao da Expresso Condicional

A ordem em que as condies so colocadas em uma expresso tem impacto sobre o seu desempenho. Isto porque, o algoritmo de verificao da expresso realiza as comparaes na ordem da expresso desenvolvida na programao e se esta ordem corresponder ordem fsica (create table) de uma tupla (linha), mais rapidamente uma tupla pode ser descartada se alguma das condies no for satisfeita.

SELECT * FROM Table_1 WHERE NOT (coluna_1 > 5) AND NOT (coluna_2 = 3);

SELECT * FROM Table_1 WHERE (coluna_1 78.95 AND coluna3 = 'Joo' AND coluna4 coluna5;

CREATE TABLE table_1 (coluna1 NUMBER PRIMARY KEY, coluna2 NUMBER (5,2) , coluna3 CHAR(50), coluna4 NUMBER, coluna5 NUMBER )

considerando



Todos os melhores SGBDs possuem otimizadores que, mesmo no elaborando as condies na ordem fsica de uma tabela, transformam o cdigo de uma expresso condicional para a ordem mais eficiente (Plano de Execuo). Em alguns SGBDs, a transformao no ocorre quando nveis de parnteses so usados, pois a prioridade de avaliao indicada explicitamente pelo desenvolvedor no deve ser subvertida pelo otimizador.

Contudo, existem casos excepcionais que merecem a ateno dos desenvolvedores, como nos casos em que se deseja subverter a ordem para que um teste condicional sobre um atributo de maior impacto para o falso seja realizado antes dos demais.

5. Estilo de Programao

Existem diversas recomendaes sobre o estilo de programao de cdigo tendo como foco os aspectos de qualidade do processo, considerando diversos parmetros como:

LEGIBILIDADE: caracterstica do nvel de facilidade de leitura; PORTABILIDADE: caracterstica do nvel de facilidade de levar o cdigo

para outras plataformas tecnolgicas; REUSO: caracterstica do nvel de facilidade de reutilizao em outros

produtos; TESTABILILIDADE: caracterstica do nvel de facilidade de ser testado.

Mas no caso do desempenho, o estilo da programao est relacionado a criao de um Padro de Programao. Muitos SGBDs tm em seus parses (algoritmos de anlise do cdigo) a diferenciao de cdigo escrito em maiscula ou minscula, alm da mudana de posies de sentenas condicionais. Estes parser costumam armazenar os resultados de sua anlise e a otimizao correspondente. Assim, quando um cdigo SQL analisado pelo parser, busca-se inicialmente algum cdigo SQL com alguma semelhana de elementos, para se aproveitar o Plano de Execuo existente. Caso no se perceba alguma semelhana, todo o processo de anlise do cdigo realizado.



Sugere-se que a equipe de desenvolvedores de cdigo SQL estabelea um Padro de Programao para todos os sistemas a serem desenvolvidos. A equipe deve estabelecer o padro que lhe seja mais agradvel e compensador.

6. Simplificao de Condies

importante observar que algumas expresses condicionais compostas podem ser simplificadas, usando algumas propriedades e regras. (Estude Raciocnio e Lgica)

Associativa (A and B) and (B and C) A and B and C (A or B) or (B or C) A or B or C

Distributiva (A and B) or (A and C) A and (B or C)

SELECT * FROM Table_1 WHERE coluna_1 > 5 OR coluna_2 9;

SELECT * from Table_1 WHERE COLUNA_1> 5 OR 9 coluna_2 ;

diferente

de

PADRO - Palavras Reservadas escrita em Maiuscula - Tabelas com inicial em maiscula - Colunas em minscula - Espao entre palavras, identificadores e valores

SELECT * FROM Table_1 WHERE coluna_1 7;

Exemplo



(A or B) and (A or C) A or (B and C)

Substituies muito empregadas usam os Teoremas de De Morgan 1o. NOT ( A and B) NOT A or NOT B 2o. NOT ( A or B) NOT A and NOT B

Outras identidades que podem ser teis so: A or (A and B) A (A or B) and (A or C) A or (B and C) A or (NOT A and B) A or B

Outras equivalncias possveis exigem a avaliao da lgica para encontrar uma expresso com menor quantidade de operadores, como no exemplo a seguir.

Muitos erros de programao so causados por equvocos de lgica do programador, na tentativa de procurar uma melhor alternativa lgica.

SELECT * FROM Table_1

WHERE NOT (coluna_1 > 10 AND coluna_2 = 8);

SELECT * FROM Table_1 WHERE (NOT coluna_1 >10) OR (NOT coluna_2 = 8);

SELECT * FROM Table_1 WHERE coluna_1



Dead Code so cdigos que cuja lgica aparentemente contribuem para a obteno do result set desejado, mas que na prtica nunca so executados ou no tm nenhuma variao de resultado lgico, ou seja, so condies sempre verdadeiras ou falsas.

Deve-se revisar as expresses condicionais para reconhecer e eliminar Dead Code, que podem geram prejuzos ao desempenho. No so todos os Dead Code que so reconhecidos pelos otimizadores.

SELECT Table_1.coluna_1 FROM Table_1 T1 WHERE T1.coluna_2 IN ( SELECT Table_2.coluna_2 FROM Table_2 T2 WHERE T2.coluna_3 = @X ) AND T1.coluna_2 IN ( SELECT Table_2.coluna_2 FROM Table_2 T2 WHERE T2.coluna_3 = @Y )

SELECT Table_1.coluna_1 FROM Table_1 T1 , Table_2 T2 WHERE T1.coluna_2 = T2.coluna_2 AND T2.coluna_3 IN (@X , @Y);

no equivalente

SELECT * FROM Table_1 coluna_1 coluna_1 AND coluna_2 > 90; /* cdigo morto */

1

Nvel Desenvolvedor



7. Converses de Maisculas e Minsculas

A maioria dos SGBDs so Case Sensitive, ou seja, fazem distino de valor entre caracteres minsculos e maisculos. As funes para converso para maisculo (UPPER) e para minsculo (LOWER) degradam o desempenho de avaliao de uma expresso condicional, mas dependendo da aplicao pode ser impossvel evit-las. Se for inevitvel, preferencialmente utilize a funo LOWER, pois a funo UPPER pode gerar a perda das acentuaes, o que pode significar a alterao do dado comparado. Exemplo: UPPER('porqu').

8. ORDER BY

A clusula ORDER BY estabelece a ordenao da resultante de uma pesquisa em uma determinada ordem (crescente ou decrescente). O senso comum nos leva a considerar que h nesta clusula a solicitao de execuo de um algoritmo de ordenao aps a gerao de uma tabela resultante. Obviamente, o ORDER BY envolve ento um maior processamento para a finalizao da consulta solicitada e, portanto, deve ser evitado quando possvel.

A ordenao fsica de uma tabela pode ajudar o algoritmo a gerar mais rapidamente o result set ordenado. Assim, importante considerar a Organizao Fsica de uma tabela durante o Projeto Fsico do Banco de Dados. Alm disso, outros fatores influenciam o desempenho desta operao:

Quantidade de linhas selecionadas; Quantidade de colunas na clusula ORDER BY; Os tamanhos das colunas que esto na clusula ORDER BY.

A Figura 1 apresenta esquematicamente o padro de comportamento da degradao de desempenho considerando o uso da clusula ORDER BY, praticamente de Ordem Linear, pois o processo no envolve apenas o algoritmo de ordenao, mas tambm o gerenciamento de I/O. Testes de desempenho mudando o eixo Y para Quantidade de Colunas ou Tamanho das Colunas apresentam o mesmo comportamento da Figura 1.



Figura 1. Degradao de Desempenho (ORDER BY)

Os Tipos de dados das colunas envolvidas na clusula ORDER BY tambm estabelecem impacto no desempenho de sua execuo. Assim, ordenao de uma coluna INT tem melhor desempenho que uma ordenao de uma coluna CHAR.

A clusula ORDER BY pode ser evitada e mesmo assim obter a resultante ordenada. As situaes para isto acontecer so:

Recomenda-se, caso no haja necessidade de um filtro de seleo (WHERE) que se coloque uma condio sempre verdadeira (DEAD CODE) envolvendo a coluna que se deseja ordem, mas isto funcionar apenas se a coluna estiver indexada.

Criar uma indexao apenas para evitar a necessidade de um ORDER BY no a melhor opo. Afinal, h custos envolvidos na manuteno de um ndice.

A ordem em que so colocadas as colunas na clusula tambm tem impacto no desempenho. A seqncia de colunas analisada da esquerda para a direita. Se o usurio no tiver preferncia pela ordenao, monte esta seqncia iniciando com a

0 2000 4000 6000 8000

10000 12000

1 2 3 4 5 6 7 8 9 10 Qua

ntid

ade

de L

inha

s

Ciclos de Execuo (Nano seg.)

Tabela ordenada fisicamente pela coluna de interesse SELECT * FROM Table_1;

Coluna indexada (ou clusterizada) a coluna de interesse SELECT * FROM Table_1 WHERE coluna_1 < 87678 ;



coluna que possui o menor grau de disperso (ou Seletividade, medida que estabelece a porcentagem de valores distintos em um conjunto, tabela ou ndice) de valores, seguida da coluna com segundo menor grau e assim por diante.

O calculo da Seletividade de uma Coluna dado por:

(Total de Valores nicos Existente Na Coluna) / Total de Linhas

SELECT * FROM Table_1 ORDER BY coluna_3, coluna_2, coluna_1;

- coluna_1 tem Seletividade 10/10 = 1 - coluna_2 tem Seletividade 5/10 = 0.5 - coluna_3 tem Seletividade 2/10 = 0.2

/* Calculo de Seletividade */ SELECT CAST(COUNT(DISTINCT coluna_1) AS DECIMAL))/ COUNT(coluna_1) FROM Table_1



9. GROUP BY

A clusula GROUP BY estabelece o agrupamento da resultante de uma pesquisa. O senso comum nos leva a considerar que h nesta clusula a solicitao de execuo de um algoritmo de classificao aps a gerao de uma tabela resultante. Obviamente, o GROUP BY leva ento a um maior processamento para a finalizao da consulta solicitada e, portanto, deve ser evitada quando possvel.

A clusula WHERE executada antes da clusula GROUP BY, que executada antes da clusula HAVING. Assim, evite condies em HAVING que no estejam relacionados com os grupos formados ou que podem ser testados antes da formao do grupo. Colocar condies em HAVING que poderiam estar em WHERE implica, na maioria dos SGBDs, em realizar a pesquisa duas vezes nas tabelas envolvidas.

A ordenao fsica de uma tabela em Cluster pode ajudar o algoritmo a gerar mais rapidamente a resultante agrupada. Assim, importante considerar a Organizao Fsica de uma tabela durante o Projeto Fsico do Banco de Dados. Mas ao considerar que a clusula WHERE executada antes, a indexao que ajudaria no agrupamento perde o seu valor, pois depois do filtro o agrupamento ocorre sobre uma tabela temporria resultante, sem ndice.

Em SQL Server, as tabelas so Heap ou organizadas e indexadas por uma estrutura de B+Tree. A organizao fsica de uma tabela, mais adequada para situaes que exigem desempenho de pesquisa, deve ser determinada pelo seu nico ndice Clustered. Em Oracle, as tabelas so Heap (default) em que a cada nova insero realizada no primeio espao livre da tabela que foi localizado pelo SGBD. Outra opo so as IOT (Index-organized Table) organizadas e indexadas por uma estrutura de B+Tree.

SELECT coluna_1 FROM Table_1 WHERE coluna_2 = 5 GROUP BY coluna_1 HAVING coluna_1 > 6;

SELECT coluna_1 FROM Table_1 WHERE coluna_2 = 5 AND coluna_1 > 6 GROUP BY coluna_1;

Melhor assim



B+tree de ndice primrio - Clusterizado



As chaves secundrias em SQL Server so indexadas da mesma forma, mas somente permitido para ndices secundrios.

10. Funes Bsicas

MIN / MAX As funes MIN e MAX se beneficiam da existncia de ndices, pois respectivamente o menor valor e o maior valor correspondem ao primeiro e o ltimo dado do ndice que est ordenado de modo crescente. Isto vlido somente quando no h condio WHERE, pois estabeleceria um filtro que criaria uma tabela resultante temporria e o ndice no teria relao com esta tabela.

COUNT A funo COUNT se beneficia da existncia do ndice desde que este ndice corresponda a coluna ou colunas no parmetro de COUNT ( ). Isto vlido somente quando no h condio WHERE, pois estabeleceria um filtro que criaria uma tabela resultante temporria e o ndice no teria relao com esta tabela.

importante observar que valor NULL no indexado. Assim, a contagem de valores de uma coluna que permite o NULL no valida usando o ndice. Analise esta situao quando for criar uma tabela e definir as restries sobre as colunas desta tabela.

Esta funo se beneficia de estatsticas acumuladas pelo SGBD. Recomenda-se ger-las e mant-las atualizadas. Pode-se ponderar que o custo de mant-las atualizadas seja elevado em comparao com os ganhos que possam trazer para a otimizao de consultas, mas os dados estatsticos podem trazer outras informao para um DBA que necessita refinar seu projeto ou adequ-lo a novos requisitos.

SUM / AVG Estas funes exigem bastante processamento e a nica forma de evit-las seria utilizando uma tabela dump de dados derivados estatsticos. Este procedimento,

SELECT MIN(coluna_1) FROM Table_1 WHERE coluna_2 > 5;



pode causar efeito contrrio, piorando o desempenho, se no for analisado e experimentado.

11. NULL

Deve-se ficar atento ao uso do NULL, ou seja, a criao de tabelas sem a restrio de valores Nulos em colunas da Tabela. A comparao entre valores de duas colunas segue a lgica ANSI (tabela a seguir), adaptada para chaves secundrias.

Coluna_1 Coluna_2 Coluna_1 = Coluna_2

Valor Valor Verdadeiro ou Falso

Valor Nulo Falso

Nulo Valor Falso

Nulo Valor Falso

Nulo Nulo Falso

Alguns SGBDs, como Oracle, consideram que o valor Nulo no um valor, portanto, aceitvel o armazenamento de diversos nulos em uma coluna UNIQUE e seguindo esta lgica, o valor Nulo no passvel de indexao. O SQL Server no segue a mesma lgica do Oracle. Diferentemente, o DB2 tem um entendimento diferente: colunas NOT NULL so obrigatoriamente UNIQUE.

SELECT coluna_1 FROM Table_1 WHERE coluna_2 IS NULL



B. Junes (Joins) A operao de juno de duas ou mais tabelas exige bastante dos projetistas, analistas e administradores de banco de dados, afinal uma operao bastante dispendiosa de recursos (memria e processamento) e conseqentemente de tempo.

Uma operao de juno de tabelas envolve a realizao do produto cartesiano, ou seja, a combinao de todas as linhas de todas as tabelas envolvidas na operao. Assim, em uma juno de Table_1 (1000 linhas) com a Table_2 (1000 linhas) temos 1.000.000 combinaes geradas para anlise e processamento. Uma operao, neste nvel de demanda, deve ser requerida quando estritamente necessria.



A favor daqueles que precisam realizar este tipo de operao, existem estratgias de juno (join plan) para torn-la menos dispendiosa. Estas estratgias dependem de:

ndices existentes; Tamanho das tabelas; Seletividade.

As 4 estratgias mais conhecidas so:

Nested-loop; Sort-Merge Hash Cartersian

1. Nested-Loop Join

Esta estratgia de juno est baseada no algoritmo a seguir, em que percebe-se a diferena entre a driver table e driven table. A operao selecionar em quase todos os SGBDs o armazenamento temporrio dos rowids

das linhas selecionadas.

Considere uma melhora no algoritmo anterior, agora com dois looping de carregamento das pginas de registros das tabelas. O looping interno, de carregamento das pginas da Table_2, apesar de ser executado diversas vezes, apenas na primeira passagem realiza o carregamento das pginas, que ficam armazenadas em uma memria cach.

Para (cada linha de Table_1) /* loop externo (1000x) - driver table Para (cada linha de Table_2) /* loop interno (1000x) - driven table Se (Table_1.colunajuno op Table_2.colunajuno) ento selecionar



Desta forma, todas as pginas so carregadas apenas uma vez. No exemplo, teremos 21 carregamentos de pginas para a memria cach. claro que a tabela do looping interno pode ser enorme, a ponto de todas as suas pginas no poderem ser colocada na memria cach.

Adicionalmente, a indexao de tabelas envolvidas pode melhorar ainda mais o desempenho da juno, reduzindo a necessidade de leituras de pginas da tabela de dados para as pginas do ndice.

O melhor ndice da chave primria.

Para (cada pgina de Table_1) /* loop externo (11x) Para (cada pgina de Table_2) /* loop interno (10x) Para (cada linha na pgina deTable_1) Para (cada linha na pgina de Table_2) Se (Table_1.colunajuno op Table_2.colunajuno) ento selecionar

DBA

Estabelea memria cach para suportar a demanda por pginas para operaes de juno

Desenvolvedor SQL Driver table (outer) deve ser a tabela de maior tamanho.

Desenvolvedor SQL Driven Table (inner) deve ser a tabela com o melhor ndice.

SELECT * FROM Table_1, Table_2 WHERE Table_1.chave_secundaria = Table_2.chave_primaria;



A condio de juno conduz a combinao de linhas, mas a condio parametrizada um filtro redutor das linhas. Assim, para tornar as junes menos dispendiosas, a condio parametrizada deve ser executada antes. A tabela que passa pela condio parametrizada deve ser a Driver Table.

Caso a tabela de maior tamanho no tenha um filtro de seleo, recomenda-se criar uma condio artificial (despretensiosa) para forar a colocao desta tabela como driver.

2. Sort-Merge Join

Esta estratgia de juno, tambm conhecida pelos nomes de merge scan ou merge join, est baseada no algoritmo a seguir que apresenta a lgica para:

Uma juno inner; A operao de equi join (igualdade entre chaves, =); Sem repetio de valor na coluna de juno; Juno de chave simples.

SELECT * FROM Table_1, Table_2 WHERE Table_1.coluna_1 = Table_2.coluna_1 AND Table_1.coluna_2 > 7;

SELECT * FROM Table_1, Table_2 WHERE Table_1.coluna_1 = Table_2.coluna_1 AND Table_1.coluna_2 > 7 AND Table_2.coluna_3 ' ';



Em situaes em que a juno no apresenta as caractersticas acima, a lgica do algoritmo nesta estratgia mais complexa e conseqentemente mais dispendiosa.

Em comparao com a estratgia Nested-Loop, temos um custo inicial bastante elevado nesta estratgia Sorte-Merge com a necessidade da ordenao das tabelas envolvidas. Em ORACLE, deve ser definida uma rea de memria bastante grande para este processo (parmetro: SORT_AREA_SIZE em init.ora). Se as tabelas j estiverem ordenadas pela colunajuno ou se esta coluna unique e est indexada, este custo minimizado.

3. Hash Join

Esta estratgia de juno est baseada no algoritmo a seguir, em que uma estrutura de hash montada temporariamente para apoiar o procedimento. A lgica apresentada a seguir funcional para:

A operao de equi join (igualdade entre chaves, =); Sem repetio de valor nas colunajuno;

/* Fase SORT */ Ordenar Table_1 pela colunajuno (crescente) Ordenar Table_2 pela colunajuno (crescente) /* Fase MERGE */ Buscar primeira linha de Table_1 Buscar primeira linha de Table_2 Repetir at o trmino de linhas de uma das tabelas /* juno inner */ Se (Table_1.colunajuno < Table_2.colunajuno) ento Buscar prxima linha de Table_1 seno Se (Table_1.colunajuno > Table_2.colunajuno) ento Buscar prxima linha de Table_2 seno selecionar /* considerando a operao de equi join */ Buscar prxima linha de Table_1 Buscar prxima linha de Table_2

2

Nvel Analista



Em comparao com as outras estratgias, temos um custo com a necessidade de memria para a montagem da estrutura de Hash. Costumeiramente, no h necessidade de muita memria (menos de um 1Mb) pois na estrutura so armazenadas apenas as Rowids (freqentemente 32 bits cada). Em ORACLE, deve ser definida uma rea de memria dedicada para este processo (parmetro: HASH_AREA_SIZE em init.ora).

Figura 2. Esquema da Estrutura Hash

Para (cada linha de Table_1) /* loop (1000x) - driver table Calcular um endereo de Hash Armazenar rowid (Table_1) na estrutura de hash, no endereo calculado Para (cada linha de Table_2) /* loop (1000x) - driven table Calcular um endereo de Hash Se endereo de hash j utilizado (coliso positiva) ento Armazenar rowid (Table-2) na estrutura de hash, no endereo calculado Para cada endereo usado em Hash Se endereo tem dois rowids armazenados selecionar



4. Cartesian Join

Esta estratgia de juno aplicada em situaes em que o filtro de pesquisa no determinada nenhuma condio de juno. H SGBDs que no suportam este tipo de juno, sendo aplicado o Nested-Loop.

5. HINTS

O programador pode forar a execuo do algoritmo de juno que achar mais adequado se desejar desconsiderar a opo do otimizador. Para isto, o programador deve indicar a estratgia de juno usando JOIN HINTS (sugestes).

SELECT * /* em SQL Server */ FROM Table_1 CROSS JOIN Table_2;

/* Em SQL Server */ SELECT T1.coluna_2 FROM Table_1 T1, Table_2 T2 WHERE T1.coluna_1 = T2.coluna_1 OPTION (LOOP JOIN); /* MERGE ou HASH */

Figura 3. Hash com Coliso

0

1

2

3

M - 2

M - 1

K1

K2

K3

K4

K5

KM

KM-1

K6

KM-4



6. Chaves Compostas

Nos casos em que a juno realizada sobre uma chave composta, ndices sobre partes destas chaves no oferecem um desempenho to bom quanto um nico ndice sobre a chave composta.

Figura 4. Processo No Eficiente (Composio de ndices)

importante que as chaves compostas de ambas as tabelas da juno tenham o mesmo tipo e o mesmo tamanho, para que no haja prejuzo ao desempenho em um processo de converso de tipo ou de adaptao de tamanho.

A exceo so os ndices Bitmap que permitem timo desempenho na composio, pois envolvem simples operaes binrias.

/* Em Oracle */ SELECT /*+ USE_NL (T1 T2) */ T1.coluna_2 FROM Table_1 T1, Table_2 T2 WHERE T1.coluna_1 = T2.coluna_1; /* USE_MERGE ou USE_HASH */

Composio dos ndices

ndice 1

ndice 2

SELECT * FROM Table_1, Table_2 WHERE Table_1.coluna_1 = Table_2.coluna_1 AND Table_1.coluna_2 = Table_2.coluna_2;



7. Opes juno

Sendo uma operao muito dispendiosa, mesmo usando a melhor estratgia de juno, o ideal evitar Junes quando possvel. Algumas transformaes podem ser empregadas para contorn-las.



Outra opo, bastante interessante a criao de um ndice para suportar a juno, ou seja, exclusivamente para a operao sobre as chaves que so comparadas em juno. O desempenho est relacionado com a pesquisa envolver um nico ndice e os valores iguais estarem em posies consecutivas no ndice. Est opo est disponvel deve ser desenvolvida pelo programador.

Este tipo de ndice traz o efeito colateral indesejado de no ser eficiente para a pesquisa envolvendo apenas uma das tabelas, pois afinal, o ndice bem maior por manter tambm os dados de outra tabela.

SELECT coluna_1 FROM Table_1, Table_2 WHERE (Table_1.colunajuno = Table_2.colunajuno) AND Table_1.colunajuno = 67;

SELECT coluna_1 FROM Table_1, Table_2 WHERE Table_1.colunajuno = 67 AND Table_2.colunajuno = 67;

Melhor

ndice Table_2

a c f

Table_1

a b c

Table_2

a c f

ndice Table_1

a b c

ndice Table_1 e Table_2

a a b c c f



A composio de tabelas tambm uma alternativa se o projetista do banco de dados est disposto a fazer alguma migrao de custo, ou seja, reduzir o custo de operao de juno elevando o custo de insero, remoo e atualizao de dados.

A migrao de custo um procedimento que deve ser seguido em todos os casos em que se esgotaram as opes de reduo de custo. O administrador deve reconhecer que um ou mais processos (e consequentemente seus usurios) se beneficiaro com a melhoria conseguida e outros processos perdero o que j tinham.

Durante o projeto do banco de dados e de suas aplicaes, analise quais processos esto em disputa. A deciso crucial, mas no definitiva, pois cenrio de utilizao podem mudar com grande rapidez e a importncia dos processos neste cenrio segue o mesmo ritmo de mudanas. (Estude Gesto de Mudanas).

Figura 5. Matriz CRUD (Create (incluso), Read (leitura), Update (atualizao) e Delete (excluso))

No substitua um problema por outro de

mesmo tamanho/Complexidade



Claramente esta uma opo que no segue os princpios da Normalizao. O uso da tabela de composio de tabelas no normatizada no significa necessariamente que o projetista est subvertendo o principio da normatizao em seu projeto, pois esta tabela de composio apenas para apoiar as consultas com juno das tabelas envolvidas. A tabela de composio tem seu contedo e integridade mantida atravs de Triggers que so executados quando as tabelas originais passam por inseres, remoes ou atualizaes.

8. Mltiplas Junes

Considere a necessidade de diversas junes em uma operao de consulta. Quanto mais tabelas estiverem envolvidas, menor deve ser a confiana do desenvolvedor no otimizador de consultas.

CREATE TABLE Table_1 ( coluna_1 INTEGER PRIMARY KEY, coluna_2 CHARACTER (50), .... ) CREATE TABLE Table_2 ( coluna_3 INTEGER PRIMARY KEY, coluna_4 INTEGER ) /* estrangeira */

CREATE TABLE Composite_T1_T2 ( coluna_1 INTEGER PRIMARY KEY, coluna_2 CHARACTER (50), coluna_3 INTEGER, coluna_4 INTEGER , .... )

SELECT * FROM Composite_T1_T2 WHERE coluna_1 = coluna_4;

Melhor

com isto temos

3

Nvel Desenvolvedor



A estratgia dos otimizadores realizar as junes separadamente, ou seja, o resultado de uma juno gera uma tabela temporria que passa pela juno com a prxima tabela e assim por diante.

Os SGBDs com opo de processamento paralelo (ex. ORACLE) podem realizar simultaneamente junes que no possuam dependncias entre si.

A ordem destas junes estabelecida pelo otimizador que busca a seqncia de melhor desempenho. Todas as orientaes sobre tabela driver, condies despretensiosas e indexaes devem ser considerada para reduzir a quantidade de operaes realizadas.

SELECT * FROM Table_1, Table_2, Table_3, Table_4 WHERE Table_1.coluna_1 = Table_2.coluna_1 AND Table_2.coluna_2 = Table_3.coluna_2 AND Table_3.coluna_3 = Table4_coluna_3;

Juno_1_2_3_4

Juno_1_2_3

Juno_1_2

Table_1 Table_2

Table_3

Table_4

Juno_1_2_3_4

Juno_1_2

Table_1 Table_2

Juno_3_4

Table_3 Table_4



Para oferecer alternativa para o otimizador encontrar a melhor seqncia para um conjunto de junes, o projetista do banco de dados pode modelar caminhos redundantes que podem ser usados para junes.

Juno_1_2_3_4 (1.000.000 oper, 1000 lin)

Juno_1_2_3 (1.000.000 oper, 1000 lin)

Juno_1_2 (1.000.000 oper, 1000 lin)

Table_1 (1000 lin) Table_2 (1000 lin)

Table_3 (1000 lin)

Table_4 (1000 lin)

SELECT * FROM Table_1, Table_2, Table_3, Table_4 WHERE Table_1.coluna_1 = Table_2.coluna_1 /* Table_1 driver */ AND Table_2.coluna_2 = Table_3.coluna_2 AND Table_3.coluna_3 = Table4_coluna_3 AND Table_1.coluna_4 = Table_4.coluna4; /* Table_1 driver */

Table_3

Table_2

Table_4

Table_1



Os otimizadores utilizam informaes estatsticas sobre a utilizao das tabelas para estabelecer o melhor plano de execuo. Entre estas estatsticas est a Densidade (medida que estabelece a porcentagem mdia de linhas retornadas na totalidade de pesquisas realizadas em uma determinada tabela).

9. Sub-consultas

As sub-consultas (subqueries) so poderosas opes para a otimizao de consultas. importante lembrar que toda pesquisa desenvolvida em sub-consultas pode tambm ser desenvolvida com uma nica consulta, mas o contrrio no verdadeiro. Tambm no se deve presumir que a transformao de uma forma para outra direta e fcil.

Juno_1_2_3_4 (100x30 = 3.000 oper)

(max 100 lin)

Juno_1_2_3 (100x50 = 5.000 oper)

(max 100 lin)

Juno_1_2 (100x20 =2.000 oper)

(max 100 lin)

Table_1 (1000 lin)

(10 %)

Table_2 (1000 lin)

(2 %)

Table_3 (1000 lin)

(5%)

Table_4 (1000 lin)

(3 %)

Juno_2_3_4_1 (50x100 = 5.000 oper)

(max 100 lin)

Juno_2_3_4 (50 x30 = 1.500 oper)

(max 50 lin)

Juno_2_3 (20x50 = 1.000 oper)

(max 50 lin)

Table_2 (1000 lin)

(2 %)

Table_3 (1000 lin)

(5 %)

Table_4 (1000 lin)

(3 %)

Table_1 (1000 lin)

(10 %)

Opo 1 Opo 2



Quando usadas, as sub-consultas estabelecem que o otimizador deve (em muito casos) utilizar um plano de execuo Nested-Loop, mas com um diferena. Nas sub-consultas no realizado o produto cartesiano (todas as linhas de todas as tabelas envolvidas so testadas), pois ocorre a finalizao do teste de uma linha da tabela driver quando a condio de juno satisfeita.

Mesmo considerando esta diferena, h questionamentos entre os desenvolvedores se compensador ou no realizar sub-consultas, pois os fornecedores de SGBD tm valorizado mais as consultas nicas nos seus otimizadores por um fato

SELECT * FROM Table_1, Table_2 WHERE (Table_1.colunajuno = Table_2.colunajuno) AND Table_2.colunajuno = 5;

SELECT * FROM Table_1 WHERE colunajuno IN ( SELECT colunajuno FROM Table_2 WHERE colunajuno = 5);

Qual o resultado das consultas, considerando que as tabelas tm 3 linhas cada com os respectivos valores de colunajuno: Table_1 {1, 5, 5} Table_2 {2, 5, 5}

No igual

Simule p/ verificar

(1) Para (cada pgina de Table_1) /* loop externo- DRIVER (2) Para (cada pgina de Table_2) /* loop interno - DRIVEN (3) Para (cada linha na pgina de Table_1) (4) Para (cada linha na pgina de Table_2) (5) Se (Table_1.colunajuno op Table_2.colunajuno) (6) ento selecionar (7) Sair do Para (4)

4

Nvel Desenvolvedor



meramente cultural programa-se mais consultas nicas do que sub-consultas.

Um formato curioso de sub-consulta faz-las na clusula FROM. Este tipo de formao, conhecido como subquery column, est definido no padro ANSI / ISO e aceito pelos SGBDs Oracle, IBM e Microsoft. O efeito deste, no otimizador, forar a execuo da consulta presente na clusula FROM, para depois prosseguir com os demais processamentos.

10. IN, ANY e ALL

As sub-consultas usando o operador IN, ANY e ALL estabelecem um plano de execuo Nested-Loop in-to-out, ou seja, o SGBD inicia da consulta mais interna para a mais externa. No h diferena de desempenho entre os operadores que apresentam resultados idnticos.

IN = ANY NOT IN ALL

Para alguns otimizadores, h dois custos adicionais no algoritmo Nested-Loop para torn-lo eficiente em sub-consultas usando estes operadores. Ocorre a ordenao dos dados pesquisados e a eliminao de repeties, para, a partir deste ponto, a sub-consulta externa ser executada e ter mais eficincia. Caso no se tenha certeza que um otimizador utiliza ou no est lgica, recomenda-se acrescentar DISTINCT e ORDER BY na sub-consulta interna. Com estas duas operaes, h uma ligeira mudana no algoritmo bsico Nested-Loop.

SELECT * FROM ( SELECT coluna_1, coluna_2 FROM Table_1) AS Table_temp WHERE coluna_1 = 7;

5

Nvel Desenvolvedor



11. EXISTS

As sub-consultas usando o operador EXISTS estabelecem um plano de execuo Nested-Loop out-to-in, ou seja, o SGBD inicia da consulta mais externa para a mais interna. Com este operador, o algoritmo bsico Nested-Loop, com a inverso de papis das tabelas driver e driven.

Em tabelas pequenas, o otimizador deve optar pelo Hash Join.

SELECT * FROM Table_1 WHERE colunajuno IN ( SELECT colunajuno FROM Table_2 WHERE colunajuno = 7);

Passos de execuo da sub-consulta INTERNA: 1. Avaliao de todas as linhas de Table_2 2. Ordenao dos resultados do passo 1 3. Eliminao de redundncias do passo 2

Simule

SELECT coluna_1 FROM Table_1 WHERE EXISTS ( SELECT * FROM Table_2 WHERE Table_1.coluna_1 7 AND Table_2.coluna_2 8);

(1) Para (cada pgina de Table_2) /* loop externo- DRIVER (2) Para (cada pgina de Table_1) /* loop interno - DRIVEN (3) Para (cada linha na pgina de Table_2) (4) Para (cada linha na pgina de Table_1) (5) Se (condio) (6) ento selecionar (7) Sair do Para (4)



12. Estilos de Juno

H trs estilos de programao de juno que podem oferecer diferentes resultados de desempenho.

Estilo Tradicional

Estilo Tradicional com sub-consultas

Estilo ANSI / ISO

As diferenas nos usos destes estilos esto nas condies que estes permitem ajustar o que se deseja para o otimizador. O estilo tradicional, com e sem subselect, foi bastante discutido at esta seo. O estilo ANSI / ISO o nico que permite a programao de outer joins, portanto, o seu uso inevitvel para as necessidades que requerem a lgica de um outer join (LEFT, RIGHT ou FULL). Quanto otimizao, o problema com o estilo ANSI / ISO que a gerao da tabela temporria resultante da juno ocorre antes dos testes condicionais da clusula WHERE. Assim, condies dos usurios e condies despretensiosas no tm efeito para forar o uso de ndices ou estabelecer a tabela driver.

SELECT Table_1.* FROM Table_1, Table_2 WHERE Table_1.colunajuno = Table_2.colunajuno;

SELECT * FROM Table_1 WHERE Table_1.colunajuno IN ( SELECT Table_2.colunajuno FROM Table_2; )

SELECT Table_1.* FROM Table_1 JOIN Table_2 ON Table_1.colunajuno = Table_2.colunajuno;



Um substituto para o LEFT outer join pode ser escrito usando a unio de duas junes. Esta alternativa pode oferecer melhoria de desempenho se as condies de filtro reduzem bastante a quantidade de linhas para a juno. Portanto, deve ser utilizada somente nestes casos.

SELECT Table_1.* /* inner part*/ FROM Table_1, Table_2 WHERE Table_1.colunajuno = Table_2.colunajuno UNION ALL SELECT Table_1.* /* outer part */ FROM Table_1 WHERE colunajuno NOT IN (SELECT colunajuno FROM Table_2);



C. Tratamentos Na programao SQL, o programador deve ficar atento paras as situaes de:

ERRO: situaes em que o SGBD verificou uma situao de inconsistncia, durante a execuo de cdigo SQL .

EXCEO: tratamento de situaes de erro detectadas na execuo de cdigo SQL, permitindo a continuidade da execuo da lgica.



D. Cursores Explcitos Cursor um recurso de programao utilizado para a pesquisa de dados nas tabelas de um Banco de Dados. Os Cursores caracterizam-se por:

uma rea de memria para armazenamento temporrio de tuplas de uma tabela pesquisada;

um apontador para tupla na rea de armazenamento temporrio; um apontador de bloco na rea de armazenamento permanente.

Os cursos so necessrio em operaes de SELECT, UPDATE e DELETE, pois envolve a pesquisa de dados em tabelas. Os cursores so classificados segundo a figura a seguir.

Cursores Implcitos so criados, manipulados e destrudos pelo SGBD sem nenhuma atuao do programador. Cursores Explcitos so criados, manipulados e destrudos pelo programador.

Os Cursores Explcitos so necessrios quando a lgica de alteraes de dados exige alguma interveno em cada tupla que atenda ao filtro da pesquisa.

Cursor Explcito

Esttico

Dinmico Implcito



Cursores Explcitos Estticos exigem uma cpia temporria dos dados a serem usados. Para todas as solicitaes do cursor, so usados os dados na rea

/* Em Oracle */ DECLARE V_empnome VARCHAR2(100); CURSOR c_empr IS SELECT nome FROM Empregados; r_empr c_empr%ROWTYPE; CURSOR c_empr2 (posicao VARCHAR2(15)) IS SELECT nome FROM Empregados WHERE posicao_id = posicao; BEGIN OPEN c_empr; FETCH c_empr INTO V_empnome, r_empr ; WHILE c_empr %FOUND LOOP DBMS_OUTPUT.PUT_LINE(V_empnome); IF V_empnome = 'Luiz C Junior' THEN { r_empr.salario = r_empr.salario *1.5; UPDATE Empregado SET ROW = r_empr WHERE emp_id = r_empr.emp_id; } FETCH c_empr INTO V_empnome, r_empr ; END LOOP CLOSE c_empr; OPEN c_empr2('Gerente'); / * apenas o primeiro gerente */ FETCH c_empr2 INTO V_empnome; DBMS_OUTPUT.PUT_LINE(V_empnome); CLOSE c_empr2; END;



temporria (em SQL SERVER, tabela temporria em tempdb). As alteraes realizadas nas tabelas base no so refletidas nas operaes realizadas pelo cursor.

Cursores Explcitos Dinmicos no exigem uma cpia temporria dos dados a serem usados. Todas as alteraes realizados na tabela base esto disponveis para uso pelo cursor, desde que estejam no caminho de navegao do cursor (FETCH). Este tipo oferece uma carga maior de processamento do SGBD. Os valores de dados, ordem e associao das linhas podem sofrer alteraes a cada busca. Cursores dinmicos no oferecem suporte para a opo de busca ABSOLUTE.

possvel evitar o uso de cursores explcitos dinmicos em muitos casos. Algumas opes para evitar-los partem da utilizao de cursores explcitos estticos, tabelas auxiliares, tabelas derivadas, sub-consultas ou comandos CASE.

Em SQL SERVER (http://msdn.microsoft.com/pt-br/library/ms180169.aspx):

DECLARE cursor_name [ INSENSITIVE ] [ SCROLL ] CURSOR FOR select_statement [ FOR { READ ONLY | UPDATE [ OF column_name [ ,...n ] ] } ][;] Transact-SQL Extended Syntax DECLARE cursor_name CURSOR [ LOCAL | GLOBAL ] [ FORWARD_ONLY | SCROLL ] [ STATIC | KEYSET | DYNAMIC | FAST_FORWARD ] [ READ_ONLY | SCROLL_LOCKS | OPTIMISTIC ] [ TYPE_WARNING ] FOR select_statement [ FOR UPDATE [ OF column_name [ ,...n ] ] ] [;]

FETCH [ [ NEXT | PRIOR | FIRST | LAST | ABSOLUTE { n | @nvar } | RELATIVE { n | @nvar } ] FROM ] { { [ GLOBAL ] cursor_name } | @cursor_variable_name } [ INTO @variable_name [ ,...n ] ]



E. Tabelas Temporrias As Tabelas Temporrias so timos recursos para armazenamento de result set que sero usados em momentos seguintes de processamento. As constraints, trigger e ndices das tabelas temporrias podem ser usadas a favor da lgica de programao que selecionar dados ou realizar eventos relacionados.

No Oracle, Tabelas Temporrias tem um tempo de existncia limitado a uma sesso ou transao. Com o inicio da sesso ou transao, a tabela criada, podendo ser manipulada normalmente e ao termino de sesso todos os seus dados so descartados. Podem ser criados ndices para as tabelas temporrias, sendo estes ndices tambm so temporrios.

No SQL Server, as Tabelas Temporrias so criadas no banco de dados TempDB, sendo classificadas em:

Tabelas Temporrias Locais: criadas com o prefixo "#" e possuem visibilidade restrita para a conexo responsvel por sua criao;

Tabelas Temporrias Globais so criadas com o prefixo "##" e so visveis por todas as conexes.

6

Nvel Desenvolvedor

CREATE TABLE #Temp_1 ( coluna_1 INT PRIMARY KEY, coluna_2 INT);



F. Tabelas Derivadas (Derived Table) Tabelas Derivadas (ou inline views) so Tabelas Temporrias geradas especificamente para atender a uma necessidade de lgica de programao, sendo utilizadas tuplas de uma ou mais tabelas base para a criao das tuplas da Tabela Derivada. H trs alternativas sintticas para a programao de Tabelas Derivadas.

Tabelas Derivadas so opes para as Tabelas Temporrias, pois no requerem os comandos de criao e de remoo.

As Tabelas Derivadas e Temporrias so alternativas para evitar a Juno de Tabelas Base grandes, que teriam elevados custos de processamento.

SELECT * FROM Table_1 T1 , (SELECT coluna_1 FROM Table_2 WHERE coluna_2 > @x ) T2 WHERE (T1.coluna_1 = T2.coluna_1 T1.coluna_2 > @y);

SELECT coluna_2 FROM Table_1 T1 WHERE coluna_1 IN ( SELECT coluna_1 FROM Table_2 WHERE coluna_2 > @x ) T2;

SELECT coluna_1, (SELECT coluna_1 FROM Table_2 WHERE coluna_2 > @x ) T2 FROM Table_1 T1 LEFT OUTER JOIN T2 WHERE T1.coluna_3 > @y



Bibliografias

SQL Performance Tuning. Peter Gulutzan. Trudy Pelzer. Editora Addison Wesley, 2002. ISBN 0-201-79169-2.

SQL Tuning. Dan Tow. Editora OReilly, 2003. ISBN 0-596-00573-3. Site Oracle. doc.oracle.com Site Microsoft. http://msdn.microsoft.com/en-us/library/bb545450.aspx

A. Expresses Lgicas1. Modelo de Sentena Condicional2. Classificao de Operadores e Operandos3. Combinao de Operadores Lgicos4. Organizao da Expresso Condicional5. Estilo de Programao6. Simplificao de Condies7. Converses de Maisculas e Minsculas8. ORDER BY9. GROUP BY10. Funes Bsicas11. NULL

B. Junes (Joins)1. Nested-Loop Join2. Sort-Merge Join3. Hash Join4. Cartesian Join5. HINTS6. Chaves Compostas7. Opes juno8. Mltiplas Junes9. Sub-consultas10. IN, ANY e ALL11. EXISTS12. Estilos de Juno

C. TratamentosD. Cursores ExplcitosE. Tabelas TemporriasF. Tabelas Derivadas (Derived Table)

aula 1 - 2014 b

Documents