Aula 1

Aula 1
Programao e
Otimizao em
SQL
CET - 0604

Especializao
Engenharia e Administrao de
Sistemas de Banco de Dados

Prof. Dr. Luiz Camolesi J nior
FT / UNICAMP - Limeira

J aneiro de 2014
copyrights reserved
CET 0604 Programao e Otimizao em SQL
Especializao em Engenharia e Administrao de Sistemas de Banco de Dados - - F FT T / U UN NI IC CA AM MP P

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.
<operando coluna> <operador comparao> <operando literal>
SELECT * FROM Table_1
WHERE coluna_1 = 12345;
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
<= 3
LIKE 8
<> 10
AND 3
OR 3
NOT 1
Aritmticos (*, / , +. -) 4

Baseadas nos operadores tpicos fornecidos pelos fabricantes de SGBDs, considere
as tabelas 1 e 2. A pontuao apresentada uma aproximao de estimativa de
custo que pode variar em cada SGBD, pois todos oferecem algoritmos distintos
para otimizao destas operaes.
Quanto menor a pontuao menor o custo de
utilizao do elemento (operando ou operador). O
desenvolvedor deve consultar a documentao
especfica do SGBD que utiliza para reconhecer as
melhores prticas de programao com SQL, ou realizar a experimentao dos
custos reais.
Tabela 2. Pontuao de Operandos em Expresses Condicionais
OPERANDO PONTUAO
Valor Literal Sozinho (a direita ou esquerda) 1
Coluna Sozinha (a direita ou esquerda) 2
Coluna com operao (a direita ou esquerda) 3
Parmetro Sozinho (a direita ou esquerda) 2
Funes 4
Tipo de Dados Numrico Inteiro 3
Multi-operandos 5
Outro Tipo de Dados Numrico 5
Tipo de Dados Temporal 5
Tipo de Dados Caracteres 10
NULL 10

0
Nvel
Desenvolvedor


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.
(<operando coluna> <operador comparao> <operando literal>) AND
(<operando coluna> <operador comparao> <operando literal>)
(<operando coluna> <operador comparao> <operando literal>) OR
(<operando coluna> <operador comparao> <operando literal>)


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.
WHERE coluna_2 IN (1, 2, 3, 5);
WHERE (coluna_2 BETWEEN 1 AND 5) AND
(coluna_2 <> 4);
WHERE coluna_2 >= 1 AND coluna_2<=5 AND
coluna_2 <> 4;

melhor
que

equivalente
a


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.

WHERE coluna_1 > 5
UNION
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.

WHERE NOT (coluna_1 > 5) AND
NOT (coluna_2 = 3);
WHERE (coluna_1 <= 5) AND
(coluna_2 <> 3);

Melhor
que
SELECT*
FROM Table_1
WHERE coluna1 = 7 AND coluna2 > 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)
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.

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

equivalante
a
o
melhor



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 (
FROM Table_2 T2
WHERE T2.coluna_3 = @X )
AND T1.coluna_2 IN (
FROM Table_2 T2
WHERE T2.coluna_3 = @Y )
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 Q
u
a
n
t
i
d
a
d
e

d
e

L
i
n
h
a
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

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;
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.

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 *
WHERE Table_1.coluna_1 = Table_2.coluna_1
AND Table_1.coluna_2 > 7;
SELECT *
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 *
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
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_4 INTEGER ) /* estrangeira */
CREATE TABLE Composite_T1_T2 (
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
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)
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)
(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.
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
WHERE EXISTS (
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
(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.*
WHERE Table_1.colunajuno = Table_2.colunajuno;
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*/
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 cur sor _name [ I NSENSI TI VE ] [ SCROLL ] CURSOR
FOR sel ect _st at ement
[ FOR { READ ONLY | UPDATE [ OF col umn_name [ , . . . n ] ] } ] [ ; ]
Tr ansact - SQL Ext ended Synt ax
DECLARE cur sor _name CURSOR [ LOCAL | GLOBAL ]
[ FORWARD_ONLY | SCROLL ]
[ STATIC | KEYSET | DYNAMIC | FAST_FORWARD ]
[ READ_ONLY | SCROLL_LOCKS | OPTI MI STI C ]
[ TYPE_WARNI NG ]
FOR sel ect _st at ement
[ FOR UPDATE [ OF col umn_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

Aula 1 - 2014 B

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Aula 1 - 2014 B

Diunggah oleh

Hak Cipta:

Format Tersedia

Anda mungkin juga menyukai