otimização de consultas em sgbd relacional – estudo de caso

Mariana Gava
002200601383 – 10º semestre
OTIMIZAÇÃO DE CONSULTAS EM SGBD RELACIONAL –
ESTUDO DE CASO
Dezembro de 2010
Itatiba / SP
ii
Mariana Gava
002200601383 – 10º semestre
OTIMIZAÇÃO DE CONSULTAS EM SGBD RELACIONAL –
ESTUDO DE CASO
Monografia apresentada à disciplina
Trabalho de Conclusão de Curso, do
Curso de Engenharia de Computação da
Universidade São Francisco, sob a
orientação do Profa. Rafaela Girotte
Sampaio Maion, como exigência parcial
para conclusão do curso de graduação.
Dezembro de 2010
Itatiba / SP
iii
AGRADECIMENTOS
Agradeço primeiramente a Deus, por ter me concedido a oportunidade de poder
ingressar numa universidade e chegar ao final desse curso, superando os obstáculos e
desafios.
A realização desta Monografia só foi possível graças a inúmeras pessoas,
principalmente aos meus pais, que em todos os momentos souberam compreender e
motivar-me durante toda a graduação para que mais essa etapa fosse vencida. Aos meus
amigos, que sempre me deram apoio e entusiasmo nos momentos mais difíceis, dirigindome palavras de conforto. Aqui deixo um agradecimento especial a minha amiga Talita que
me ajudou muito na leitura, revisão e formatação desse trabalho. Ao meu amigo Decinho
que também revisou esse trabalho e me ajudou passando seus conhecimentos durante a
sua realização. E a todos manifesto aqui a minha gratidão. E de modo particular me refiro à
profª Rafaela G. Sampaio Maion pela sua tão importante orientação, dedicação e disposição
constante em todos os momentos da realização deste trabalho, proporcionando-me grande
estímulo e motivação para realização do mesmo. Agradeço também, aos professores do
curso de Engenharia de Computação, alguns hoje nem mais presentes no corpo docente
desta Universidade, porém foram de grande contribuição para o meu crescimento intelectual
e pessoal.
Enfim, a todas as pessoas que direta ou indiretamente compartilharam informações
úteis que colaboraram para a elaboração deste trabalho.
iv
GAVA, Mariana. Otimização de Consultas em SGBD Relacional – Estudo de Caso.
2010. 80f. Monografia – Curso de Engenharia da Computação da Unidade Acadêmica da
Área de Exatas da Universidade São Francisco, Itatiba.
RESUMO
Bancos de dados tornam-se cada dia mais importantes no cotidiano da sociedade atual.
Durante as atividades diárias, pessoas deparam-se interações com algum banco de dados,
embora na maioria das vezes sem ao menos perceberem tal feito. Pode-se afirmar que os
bancos de dados são amplamente utilizados em diversas aplicações presentes no dia-a-dia,
tais como: transações bancárias, transações com cartão de crédito, reservas de linhas
aéreas e informações de horários, reservas de hotel, vendas, revendedores on-line, dentre
outras aplicações. Devido ao grande volume de dados que estes precisam gerenciar e a
complexidade de suas aplicações, é fundamental que as operações sejam realizadas de
forma eficiente, pois o desempenho de um Sistema de Gerenciamento de Banco de Dados é
medido a partir da sua eficiência na realização de consultas e alterações. Através de uma
linguagem de manipulação de dados (DML) os dados são manipulados dentro do SGBD,
sendo possível realizar diferentes funções como, consultas, atualizações e fornecer
relatórios específicos. SGBDs têm como principal função proteger o banco de dados contra
ataques maliciosos ou acessos não autorizados e também precisam garantir que não haja
mau funcionamento ou falhas que podem ocorrer no hardware ou software. Outra função
importante é quanto à manutenção dos dados. Bancos de dados precisam estar protegidos
com relação a danos causados pelos usuários, quer sejam intencionais ou não. Visando a
agilidade na consulta desses dados, o objetivo deste trabalho é analisar as técnicas de
otimização e tuning de banco de dados, utilizando o banco de dados SQL SERVER 2008,
pois a seleção de uma boa estratégia faz toda diferença e, em termos do tempo de
avaliação, a diferença de custo pode chegar a várias ordens de grandeza.
Palavras-chave: SGBD, TUNING, OTIMIZAÇÃO.
v
ABSTRACT
Databases become increasingly important in the daily lot of society today. During the daily
activities, people are faced with some interaction with a database, although most often
without even realizing it done. It can be stated that databases are widely used in various
applications present on the day to day, such as: banking transactions, credit card
transactions, airline reservations and information on schedules, hotel reservations, sales,
online retailers, among other applications. Due to the large volume of data they need to
manage complexity and its applications, it is essential that operations are carried out
efficiently, because the performance of a Management System Database is measured from
its efficiency in carrying out consultations and changes. Through a data manipulation
language (DML) data are handled within the SGBD, and can perform different functions such
as queries, updates, and provide specific reports. SGBDs have the main function to protect
the database from malicious attacks or unauthorized access and must also ensure that no
malfunctions or failures that may occur in hardware or software. Another important function is
for the maintenance of the data. Databases must be protected against damage caused by
users, whether intentional or not. Aiming to speed up the consultation of such data, the
objective is to analyze the techniques of optimization and tuning database using the
database SQL SERVER 2008, because the selection of a good strategy makes all the
difference and in terms of time evaluation, the difference in cost can reach several orders of
magnitude.
Key Words: SGBD, TUNING, OPTIMIZATION
vi
SUMÁRIO
LISTA DE SIGLAS................................................................................................................... viii
LISTA DE FIGURAS ................................................................................................................ ix
LISTA DE TABELAS................................................................................................................ xi
1. INTRODUÇÃO ................................................................................................................... 12
1.1 Objetivos ........................................................................................................................... 13
2. CONCEITOS GERAIS SOBRE BANCO DE DADOS ......................................................... 14
3. STRUCTURED QUERY LANGUAGE – SQL ..................................................................... 15
3.1 Definição de dados e tipos do SQL.................................................................................... 16
4. OTIMIZAÇÃO DE BANCO DE DADOS SQL SERVER ....................................................... 20
4.1 Traduzindo consultas SQL para a álgebra relacional ......................................................... 21
4.1.2 Utilização de heurísticas na otimização de consultas...................................................... 21
4.1.3 Otimização heurística de árvores de consulta................................................................. 22
4.1.4 Otimização baseada em custo ........................................................................................ 23
4.1.5 Componentes do custo para execução de uma consulta ................................................ 23
4.1.6 Otimizando subconsultas aninhadas............................................................................... 25
5. SINTONIZAÇÃO (TUNING) DE BANCO DE DADOS EM SISTEMAS RELACIONAIS....... 28
5.1 Sintonização do projeto de banco de dados....................................................................... 30
5.1.2 Sintonização de consultas .............................................................................................. 31
5.2 Possíveis causas para o baixo desempenho ..................................................................... 32
5.3 Aumentando a perfomance da aplicação através da otimização de SQL........................... 33
6. ÍNDICES NO SQL SERVER ................................................................................................ 35
6.1 Estruturas de índices clusterizados.................................................................................... 35
6.1.2 Estruturas de índices não clusterizados.......................................................................... 37
6.1.3 De que maneira o otimizador sabe quando utilizar os índices?....................................... 38
6.2 Páginas e extends ............................................................................................................. 38
6.2.1 Unidade de alocação IN_ROW_DATA............................................................................ 39
6.2.2 Unidade de alocação ROW_OVERFLOW_DATA ........................................................... 40
6.2.3 Unidade de alocação LOB_DATA................................................................................... 40
6.3 Sintonização de índices ..................................................................................................... 40
7. O PLANO DE EXECUÇÃO NO SQL SERVER ................................................................... 42
7.1 O Otimizador de consulta................................................................................................... 42
7.2 Plano de execução estimado e plano de execução real..................................................... 43
7.2.1 Formato dos planos ........................................................................................................ 43
7.2.2 Interpretando planos de execução gráficos..................................................................... 47
vii
7.2.3 Facilitando a captura do plano de execução usando SQL SERVER Profiler ................... 51
7.2.4 Eventos do plano de execução ....................................................................................... 52
7.3 Um pouco mais sobre planos gráficos ............................................................................... 53
8. ESTUDO DE CASO............................................................................................................. 66
8.1 O SGBD............................................................................................................................. 66
8.1.2 Infraestrutura .................................................................................................................. 66
8.2 Aplicação da metodologia .................................................................................................. 66
8.2.1 Base de dados................................................................................................................ 67
8.2.2 Implementação das consultas......................................................................................... 67
8.3 Testes................................................................................................................................ 67
8.3.1 Teste 1 (subconsultas aninhadas – comandos EXISTS e INNER JOIN) ......................... 67
8.3.2 Teste 2 (Transformando expressões NOT em expressões afirmativas) .......................... 69
8.3.3 Teste 3 (Usando ou não índices) .................................................................................... 71
9. ANÁLISE DOS RESULTADOS ........................................................................................... 75
10. CONSIDERAÇÕES FINAIS............................................................................................... 77
REFERÊNCIAS BIBLIOGRÁFICAS........................................................................................ 78
viii
LISTA DE SIGLAS
ANSI – American National Standards Institute
BD – Banco de Dados
CLR – Common Language Runtime
CPU – Central Processing Unit
DBA – Database Administrator
DDL – Linguagem de Definição de Dados
DER – Diagrama Entidade Relacionamento
DML – Linguagem de Manipulação de Dados
GB – Gigabyte
GUI – Graphical User Interface
IAM – Index Allocation Map
ID – Identifier
ISO – International Organization for Standardization
I/O – Input/Output
KB – Kilobyte
MB – Megabyte
OLAP – Online Analytical Processing
RAM – Random Access Memory
SGBD – Sistema de Gerenciamento de Banco de Dados
SO – Sistema Operacional
SPID – System Process Identifier
SQL – Structure Query Language
XML – Extensible Markup Language
ix
LISTA DE FIGURAS
Figura 6.1 – Árvore B para um índice clusterizado.
Figura 6.2 – Árvore B para um índice não clusterizado.
Figura 6.3 – Árvore B padrão para um índice do SQL SERVER.
Figura 7.1 – Exemplo de texto estimado usando os comandos SET SHOWPLAN_ALL ON e
SET SHOWPLAN_ALL OF.
Figura 7.2 – Exemplo de um plano de texto estimado usando os comandos SET
SHOWPLAN_TEXT ON e SET SHOWPLAN_TEXT OFF.
Figura 7.3 – Exemplo de um plano de texto real usando os comandos SET
STATISTICS_PROFILE ON e SET STATISTICS_PROFILE OFF.
Figura 7.4 – Exemplo de um plano XML estimado usando os comandos SET
SHOWPLAN_XML e SET ON e SHOWPLAN_XML OFF.
Figura 7.5 – Exemplo de um plano de execução em XML.
Figura 7.6 – Exemplo de um plano de execução gráfico.
Figura 7.7 – Dados resultantes do ícone SELECT no plano de execução gráfico.
Figura 7.8 – Dados resultantes do ícone table scan.
Figura 7.9 – Exemplo de funcionamento do SQL profiler.
Figura 7.10 – Operador clustered index scan.
Figura 7.11 – Exemplo de consulta que retorna um clustered index scan.
Figura 7.12 – Operador clustered index seek
Figura 7.13 – Exemplo de consulta que retorna um clustered index seek
Figura 7.14 – Operador non clustered index seek.
Figura 7.15 – Exemplo de consulta que retorna um non clustered index seek.
Figura 7.16 – Operador key lookup.
Figura 7.17 – Exemplo de consulta que retorna um operador key lookup.
Figura 7.18 – Dados resultantes do operador non clustered index seek.
Figura 7.19 – Dados resultantes do operador key lookup.
Figura 7.20 – Operador nested loops.
Figura 7.21 – Operador sort.
Figura 7.22 – Operador table scan.
Figura 7.23 – Exemplo de consulta que retorna um table scan.
Figura 7.24 – Operador RID lookup.
Figura 7.25 – Exemplo de consulta que retorna um operador RID lookup.
Figura 7.26 – Operador merge join.
x
Figura 7.27 – Operador hash match.
Figura 7.28 – Exemplo de consulta que retorna os operadores merge join e hash match.
Figura 8.1 – Plano de execução gerado para o teste 1a.
Figura 8.2 – Plano de execução gerado para o teste 1b.
Figura 8.3 – Plano de execução gerado para o teste 2a.
Figura 8.4 – Plano de execução gerado para o teste 2b.
xi
LISTA DE TABELAS
Tabela 9.1 – Resultados obtidos através dos Testes 1 e 2.
Tabela 9.2 – Resultados obtidos através do Teste 3.
12
1.
INTRODUÇÃO
Atualmente banco de dados tornou-se peça fundamental nas atividades diárias das
pessoas. Muitas vezes nos deparamos com banco de dados nas nossas tarefas diárias e
nem ao menos sabemos disso. Alguns exemplos são: transações bancárias, transações
com cartão de créditos, reservas de passagens áreas, reserva de hotéis, compras on-line,
dentro outras aplicações.
Com o crescimento e o avanço tecnológico ao longo dos anos surgiram novas
aplicações dos sistemas de banco de dados. É possível citar bancos de dados multimídia,
que armazenam figuras, videoclipes e mensagens sonoras; bancos de dados geográficos,
que armazenam e também são capazes de analisar mapas, dados do tempo e imagens de
satélite; data warehouse e Online analytical processing (OLAP), que são utilizados em
muitas empresas para auxiliar em tomada de decisões, devido à capacidade de extrair e
analisar informações.
Segundo uma das definições de Elmasri e Navathe, “Um banco de dados é projetado,
construído e povoado por dados, atendendo a uma proposta específica. Possui um grupo de
usuários definido e algumas aplicações preconcebidas, de acordo com o interesse desse
grupo de usuários.” (2005, p.4)
A complexidade e o tamanho de um banco de dados são variáveis. Eles também
podem ser criados e mantidos manualmente ou então computadorizados através de um
grupo de aplicações como um sistema gerenciador de banco de dados (SGBD).
De acordo com Elmasri e Navathe (2005, p.4), “Um SGBD é uma coleção de
programas que permite aos usuários criar e manter um banco de dados.” Sendo assim, um
banco de dados é construído através de dados que são armazenados e assim são
controlados por um SGBD.
SGBDs têm como principal função proteger o banco de dados contra ataques
maliciosos ou acessos não autorizados e também precisam garantir que não haja mau
funcionamento ou falhas que podem ocorrer no hardware ou software. Outra função
importante é quanto à manutenção dos dados. Bancos de dados precisam estar protegidos
com relação aos danos causados pelos usuários, quer sejam intencionais ou não.
O principal problema enfrentado com relação a esses sistemas é o grande volume de
dados que estes precisam gerenciar e a complexidade de suas aplicações. Sendo assim, é
13
fundamental que as operações sejam realizadas de forma eficiente, pois o desempenho de
um SGBD é medido a partir da sua eficiência na realização de consultas e alterações.
Visando a agilidade na consulta desses dados, a otimização é um processo muito
utilizado para a escolha da maneira mais adequada na realização de uma consulta, pois em
geral, existem diferentes maneiras de realizá-la.
Diante disso, é de extrema importância realizar o processo de otimização e tuning,
pois a seleção de uma boa estratégia faz toda diferença e, em termos do tempo de
avaliação, a diferença de custo pode chegar a várias ordens de grandeza.
1.1
Objetivos
A elaboração deste trabalho tem como objetivo estudar as principais técnicas de
otimização e tuning em um banco de dados SQL SERVER, o qual é muito utilizado em
diversas aplicações, sendo de grande importância a escolha da solução mais adequada
para agilizar no processo de consultas.
14
2.
CONCEITOS GERAIS SOBRE BANCO DE DADOS
Segundo Silberschatz, “Um modelo de dados é uma coleção de ferramentas
conceituais para descrever dados, relações de dados, semântica de dados e restrições de
consistência.” (2006, p.5). Existem três maneiras para se descrever um projeto de um banco
de dados como no nível físico, lógico e de visão, que são divididos em quatro categorias
diferentes de classificação de modelos:
•
Modelo relacional: baseado em tabelas, que representam os dados e as relações
entre eles. Cada tabela possui um nome único. É formado por uma estrutura de
registros de tamanho fixo de vários tipos. Cada tipo de registro define a quantidade
de número dos campos ou atributos. Devido a sua simplicidade conceitual, pois
facilita o trabalho do programador, ainda hoje é o modelo mais utilizado.
•
Modelo de entidade/relacionamento: consiste em uma coleção de objetos básicos,
chamados de entidades e de relações entre eles. É um modelo muito útil no
mapeamento para um esquema conceitual.
•
Modelo de dados baseado em objetos: uma extensão do modelo de dados relacional,
incluindo orientação a objetos e tipos de coleção que possuem relações, conjuntos,
multiconjuntos e arrays.
•
Modelo de dados semi-estruturado: possui características contrárias aos dos
modelos acima citados, pois itens de dados individuais do mesmo tipo podem ter
diferentes conjuntos de atributos. Um exemplo desse modelo é a Extensible Markup
Language (XML).
Como citado anteriormente, um banco de dados relacional é formado por uma coleção
de tabelas, sendo que cada tabela possui um nome único. A relação entre um conjunto de
valores é representada pela linha de uma tabela.
15
3.
STRUCTURED QUERY LANGUAGE – SQL
De acordo com a definição de Silberschatz (2006, p.51),
Embora a SQL seja referenciada como “linguagem de consulta”, ela pode
fazer muito mais do que simplesmente consultar um banco de dados, pois
ela consegue definir a estrutura dos dados, modificar dados no banco de
dados e especificar restrições de segurança.
No início da década de 1970, a IBM desenvolveu a versão original da SQL, a qual foi
chamada de Sequel. Após anos de evolução, passou a ser chamada de SQL (Structure
Query Language), tornando-se a linguagem padrão de banco de dados relacional.
Em 1986, foi publicado um padrão SQL chamado de SQL-86 pelo American National
Standards Institute (ANSI) e a International Organization for Standardization (ISO). Em 1989,
o ANSI publicou o SQL-89 e depois surgiram as versões SQL-92 e SQL-1999. Atualmente a
versão utilizada é o SQL-2008. A linguagem SQL possui várias partes:
•
Linguagem de definição de dados (DDL): através da DDL é possível definir
esquemas de relação, excluir relações e modificar esquemas. Inclui comandos para
definir visões, especificar direitos de acesso para relações e visões e comandos para
especificar restrições de integridade às quais os dados armazenados precisam
satisfazer. Não é possível realizar atualizações que violam as restrições de
integridade.
•
Linguagem de manipulação de dados interativa (DML): inclui uma linguagem de
consulta baseada na álgebra relacional e no cálculo relacional de tabela. Também
possui comandos para inserir, excluir e modificar tabelas.
•
Integridade: A DDL SQL inclui comandos para especificar restrições de integridade
as quais os dados armazenados no banco de dados precisam satisfazer. As
atualizações que violam as restrições de integridade são proibidas.
•
Definição de view: A DDL SQL inclui comandos que definem as views.
•
Controle de transação: SQL inclui comandos que especificam o início e o fim das
transações.
16
•
SQL embutida e SQL dinâmica: definem como as instruções SQL podem ser
incorporadas dentro das linguagens de programação.
•
Autorização: A DDL inclui comandos que especificam direitos de acesso para
relações e views.
Devido ao fato de ter se tornado padrão para os bancos de dados relacionais, os
usuários não têm tanta preocupação ao migrar suas aplicações para outros tipos de
sistemas de banco de dados, como exemplo, em rede e hierárquico para sistema relacional.
3.1
Definição de dados e tipos do SQL
A SQL usa os termos tabela, linha e coluna, ao invés de relação, tabela e atributo para
o modelo relacional formal. De acordo com Elmasri e Navathe (2005), o principal comando
SQL para definição de dados é o CREATE, que pode ser usado para criar esquemas,
tabelas (relações) e domínios da mesma forma que outros construtores, como visões
(views), asserções (assertions) e gatilhos (triggers).
O padrão SQL SERVER 2008 aceita diversos tipos de domínio internos, como:
Tipos numéricos:
•
TINYINT: Faz o armazenamento de valores numéricos inteiros, variando de 0 a
255 – 1 byte;
•
SMALLINT: Faz o armazenamento de valores numéricos inteiros, variando de
(-) 32.768 à (+) 32.767 – 2 bytes;
•
INT: Faz o armazenamento de valores numéricos inteiros, variando de
(-)
2.147.483.648 à (+) 2.147.483.647 – 4 bytes;
•
BIGINT: Faz o armazenamento de valores numéricos inteiros, variando de (+)
9.223.372.036.854.775.808 à (-) 9.223.372.036.854.775.807 – 8 bytes;
17
•
SMALLMONEY: Armazena valores numéricos decimais variando de (-)
214.748.3648 à (+) 214.748.3647 – 4 bytes;
•
MONEY:
Armazena
valores
numéricos
decimais
variando
de
(-)
922.337.203.685.477.5808 à (+) 922.337.203.685.477.5807 – 8 bytes;
•
NUMERIC(18,0): Valores numéricos com casas decimais com precisão. O
primeiro número representa a quantidade de inteiros a serem armazenados e o
segundo, indica a quantidade de casas decimais do número;
•
DECIMAL(18,0): Possui as mesmas funcionalidades do tipo NUMERIC, com a
diferença que o DECIMAL faz parte do padrão ANSI e NUMERIC é mantido por
compatibilidade;
•
FLOAT: Valores numéricos aproximados com precisão de ponto flutuante,
variando de (-) 1.79E + 308 à (+) 1.79E + 308 – 4 ou 8 bytes;
•
REAL: Valores numéricos aproximados com precisão de ponto flutuante,
variando de (-) 3.40E + 38 à 3.40E + 38 – 4 bytes;
Tipo BIT:
•
BIT: Armazena bits, podendo conter valores lógicos 0 ou 1 – 1 bit;
Tipo data:
•
SMALLDATETIME: Faz o armazenamento de data e hora, com precisão de
minutos – 4 bytes;
•
DATETIME: Também armazena data e hora, porém com precisão de
centésimos de segundos – 8 bytes;
•
TIME: Armazena somente hora, podendo armazenar segundos até a fração de
9999999 – 3 a 5 bytes;
•
DATE: Somente data – 3 bytes;
•
DATETIME2: Combinação dos tipos de dados DATE e TIME, com a diferença
para o tipo DATETIME é a precisão ao armazenar as horas – 6 a 8 bytes;
18
•
DATETIMEOFFSET: Valores de data e hora com a combinação da hora do dia
com o fuso horário. O intervalo de deslocamento do fuso horário é de (-)14:00 à
(+) 14:00 – 8 a 10 bytes;
Tipos caracteres:
•
CHAR(N): Faz o armazenamento de N caracteres fixos (até 8.000) no formato
não Unicode. Independente da quantidade de caracteres utilizados, sempre irá
armazenar o tamanho de caracteres do campo, preenchendo o restante com
espaços em branco;
•
VARCHAR(N): Faz o armazenamento de N caracteres (até 8.000) no formato
não Unicode;
•
VARCHAR(MAX): Faz o armazenamento de caracteres no formato não
Unicode. MAX indica que o máximo a ser armazenado pode chegar a 2^31-1
bytes;
•
TEXT: Faz o armazenamento de caracteres no formato não Unicode. Esse tipo
de dado suporte até 2.147.483.647 caracteres e possui funções específicas
para trabalhar com esse tipo de dado;
•
NCHAR(N): Praticamente similar ao CHAR(N), com a diferença que armazena
N caracteres fixos (até 4.000) no formato Unicode;
•
NVARCHAR(N): Faz o armazenamento de (até 4.000) no formato Unicode;
•
NVARCHAR(MAX): Faz o armazenamento de caracteres no formato Unicode.
MAX indica que o máximo a ser armazenado pode chegar a 2^31-1 bytes;
•
NTEXT: Faz o armazenamento de caracteres no formato Unicode. Esse tipo de
dado suporte até 1.073.741.823 caracteres e possui funções específicas para
trabalhar com esse tipo de dado;
Por padrão todo caracter ocupa um byte. Se considerarmos que um byte representa
um octeto de oito bits e que cada bit tem duas possibilidades (ligado ou desligado), então
um byte pode representar 256 possibilidades (2^8). No passado, 256 possibilidades eram
suficientes para cobrir todo o conjunto de caracteres americano.
19
Outros tipos de dados:
•
BINARY(N): Faz o armazenamento de dados no formato binário, podendo
chegar até 8.000 bytes. Independente da quantidade de dados armazenados, o
restante do campo será preenchido com espaços em branco;
•
VARBINARY(N): Faz o armazenamento de dados no formato binário, podendo
chegar até 8.000 bytes. É diferente do tipo BINARY porque não faz o
preenchimento com espaços em branco.
•
VARBINARY(MAX): Faz o armazenamento de dados no formato binário,
podendo chegar até 2^31-1 bytes;
•
IMAGE: Faz o armazenamento de dados no formato binário, podendo chegar
até 2,147,483,647 bytes;
•
SQL_VARIANT: Faz o armazenamento de todos os tipos de dados em um
mesmo campo de uma tabela, com exceção dos tipos TEXT, NTEXT,
TIMESTAMP e SQL_VARIANT – até 8 K;
•
TIMESTAMP: Permite a geração automática de um valor binário para um
campo de uma tabela;
•
UNIQUEIDENTIFIER: Utilizado para a criação de um identificador global e
único para uma tabela do SQL SERVER – armazena 16 bytes;
•
GEOMETRY:
Faz
o
armazenamento
de
dados
espaciais
utilizando
representação plana da Terra (Flat Earth);
•
GEOGRAPHY: Faz o armazenamento de dados espaciais utilizando
representação redonda da Terra (Round Earth);
•
HIERARCHYID: Usado para representar uma posição em uma hierarquia. Uma
coluna não necessariamente irá representar automaticamente uma árvore. É
até a aplicação para gerar e atribuir valores hierarchyid de tal forma que a
relação desejada entre as linhas é refletida nos valores;
•
XML: Faz o armazenamento de dados no formato XML, não podendo exceder
a 2Gb;
20
4.
OTIMIZAÇÃO DE BANCO DE DADOS SQL SERVER
Segundo a definição de Silberschatz, otimização da consulta “É o processo de
selecionar o plano de avaliação de consulta mais eficiente dentre as muitas estratégias
normalmente possíveis para o processamento de determinada consulta, especialmente se
esta for complexa”. (2006, p.383). Os usuários não têm obrigação de saber escrever a
consulta para que a mesma seja processada de forma eficiente, mas o sistema deve
construir um plano de avaliação para que o custo da avaliação da consulta seja reduzido.
Além da busca ser realizada pelo sistema de uma maneira mais eficiente para
executar uma consulta, através de uma expressão similar na álgebra relacional, outros
aspectos também são observados tais como: algoritmos para execução de operações e
também índices específicos que serão utilizados.
O otimizador de consulta tem como tarefa gerar um plano de avaliação de consulta
que terá como base uma expressão em álgebra relacional e a transformará numa expressão
com menor custo. A geração de planos de avaliação envolve três etapas:
1. Definir expressões que sejam logicamente equivalentes a expressão dada;
2. Fazer uma estimativa do custo do plano de avaliação;
3. Realizar de forma alternativa anotações das expressões resultantes para gerar
planos de avaliação de consulta alternativos;
Primeiramente, as etapas 1 e 3 são realizadas, sendo as expressões geradas e
anotadas aos poucos. E em segundo plano a etapa 2 é feita com a coleta de informações
estatísticas sobre as relações para garantir uma boa estimativa do custo de um plano.
De acordo com Silberschatz (2006, p.384), o otimizador de consulta gera expressões
equivalentes a uma determinada expressão através de regras de equivalência que
especificam como transformar uma expressão em outra logicamente equivalente.
Existem diversas maneiras de uma consulta ser expressa, com diferentes custos de
avaliação. É bom ressaltar que, a ordem das tabelas é irrelevante, desde que seja
equivalente o conjunto de tabelas.
21
4.1 Traduzindo consultas SQL para a álgebra relacional
Em primeiro lugar, uma consulta SQL é traduzida para uma expressão equivalente na
álgebra relacional, sendo representada por uma estrutura de dados de árvore de consulta,
que após é otimizada. Uma regra de equivalência diz que expressões de duas formas são
equivalentes. É através delas que o otimizador transforma expressões em outras
logicamente equivalentes.
De acordo com Elmasri e Navathe (2005, p.356),
As consultas SQL são decompostas em blocos de consultas, que formam
as unidades básicas que podem ser traduzidas em operadores algébricos e
otimizadas. Um bloco de consulta contém uma única expressão SELECTFROM-WHERE, bem como cláusulas GROUP BY e HAVING, se elas forem
partes do bloco.
Sendo assim, consultas aninhadas dentro de uma consulta são identificadas como
blocos separados.
4.1.2 Utilização de heurísticas na otimização de consultas
As regras heurísticas são utilizadas para melhorar o desempenho das consultas,
através da modificação da representação interna de uma consulta, que na maioria das
vezes está na forma de dados de árvore de consulta ou de um grafo de consulta. Segundo
Elmasri e Navathe, “O analisador sintático de uma consulta de alto nível primeiro gera uma
representação interna inicial, que depois é otimizada de acordo com as regras de
heurística.” (2005, p.368). Após, um plano de execução de consulta é gerado, e o mesmo
tem como responsabilidade executar grupos de operações com base nos caminhos de
acesso disponíveis para os arquivos envolvidos na consulta.
Devido ao tamanho do arquivo resultante de uma operação binária, como JOIN,
utilizam-se as operações SELECT e PROJECT antes do JOIN de operações binárias, pois
essas operações reduzem o tamanho de um arquivo.
22
As regras de otimização heurísticas são aplicadas para converter uma árvore de
consulta numa árvore de consulta equivalente, que representa uma expressão diferente da
álgebra relacional e que é executada de forma mais eficiente, porém que produz o mesmo
resultado. Elmasri e Navathe (2005, p. 368), definem que:
Uma árvore de consulta é uma estrutura de dados de árvore que
corresponde a uma expressão da álgebra relacional. Ela representa as
relações de entrada de uma consulta como nós folhas da árvore e
representa as operações da álgebra relacional como nós internos.
Realiza-se a execução de uma operação de nó interno, se seus operandos estiverem
disponíveis, e em seguida a substituição do nó interno pela relação que resulta da execução
da operação, que é chamada de execução da árvore de consulta. Na árvore de consulta
existe a necessidade de preservar uma ordem específica de operações para execução de
uma consulta. Já uma representação mais neutra de uma consulta é notada de grafo de
consulta, na qual não indica uma ordem na qual as operações devem ser realizadas e
apenas um grafo corresponde a cada consulta. De acordo com Elmasri e Navathe (2005),
embora algumas técnicas de otimização sejam baseadas em grafos de consulta, as árvores
de consulta são preferíveis porque, na prática, o otimizador de consulta precisa mostrar a
ordem das operações para a execução da consulta, o que não é possível em grafos de
consulta.
4.1.3 Otimização heurística de árvores de consulta
Devido ao fato de existirem muitas expressões diferentes na álgebra relacional, muitas
árvores de consulta diferentes podem corresponder à mesma consulta. É criada uma árvore
de consulta inicial, correspondente à consulta SQL, sem nenhuma otimização através do
analisador sintático.
É tarefa do otimizador heurístico de consulta transformar a árvore de consulta inicial
em uma árvore de consulta final que seja eficiente. Incluem-se regras de equivalência entre
as expressões da álgebra relacional, que são utilizadas para transformar a árvore inicial na
árvore de consulta otimizada final.
Operações Cartesian Product seguidas de uma condição de junção podem ser
substituídas por uma operação Join para melhorar ainda mais a árvore de consulta.
23
Também é importante o mais cedo possível manter apenas os atributos necessários para as
operações subseqüentes nas relações intermediárias, por meio da inclusão de operações
Project (π).
Enfim, as heurísticas básicas para otimização algébrica são:
•
Aplicar o quanto antes operações que reduzem o tamanho dos resultados
intermediários, como operações de SELECT que reduzem o número de tabelas e
•
Operações Project que diminuem o número de atributos.
4.1.4 Otimização baseada em custo
Um otimizador de consultas não deve basear-se apenas em regras heurísticas, mas
também deve estimar e comparar diferentes estratégias de execução, considerando a
melhor estratégia aquela com menor estimativa de custo. Uma otimização mais elaborada é
indicada em consultas compiladas, que são consultas na qual a otimização é feita em tempo
de compilação, sendo consultas interpretadas indicadas para otimização parcial, que
ocorrem em tempo de execução.
A otimização baseada no custo, busca soluções para um problema e também uma
solução que minimize uma função de custo, porém essas funções são apenas estimativas,
pois o otimizador pode escolher uma estratégia de solução que não seja a estratégia ótima.
4.1.5 Componentes do custo para execução de uma consulta
Alguns componentes são necessários para o custo da execução de uma consulta,
como:
•
Custo de acesso ao armazenamento secundário: refere-se ao custo da busca, leitura
e escrita de blocos de dados que residem em armazenamento secundário,
principalmente em discos. Fatores como blocos de arquivos alocados de maneira
adjacente no mesmo cilindro ou disco afetam o custo de acesso.
24
•
Custo de armazenamento: custo de arquivos temporários que são gerados por uma
estratégia de execução de consulta.
•
Custo de computação: compõe o custo de realização, na memória, referente às
operações de buffers de dados durante a execução da consulta.
•
Custo do uso de memória: custo referente ao número de buffers de memória que são
solicitados durante a execução da consulta.
•
Custo de comunicação: custo que se refere ao transporte da consulta e de seus
resultados de um site de banco de dados para o site ou terminal onde a consulta
originou-se.
Em grandes bancos de dados, o foco é minimizar o custo de acesso ao
armazenamento secundário. Já em bancos menores, o ideal é minimizar o custo de
computação. Nos bancos de dados distribuídos, o custo de comunicação deve ser o foco de
minimização.
De acordo com Elmasri e Navathe (2005, p.377),
Para estimar custos de várias estratégias de execução, devemos manter
atualizadas quaisquer informações que sejam necessárias para as funções
de custo. Essas informações podem ser armazenadas no catálogo do
SGBD, onde são acessadas pelo otimizador de consulta.
Para o otimizador de consulta realizar a estimativa de custo das várias estratégias de
execução,
é preciso valores
razoavelmente próximos
de atualizados,
mas
não
necessariamente valores atualizados até o último minuto. As diferenças estratégias são
enumeradas e os custos das diferentes estratégias são estimados. A programação dinâmica
é uma técnica de otimização que pode ser utilizada para encontrar eficientemente a
estimativa de custo ótima, sem precisar considerar todas as possíveis estratégias de
execução.
Segundo Elmasri e Navathe, “Para desenvolver funções de custo razoavelmente
precisas para operações JOIN, é preciso ter uma estimativa do tamanho (número de
tabelas) do arquivo que resulta após a operação JOIN”. (2005, p.378). Dá-se o nome de
seletividade da junção (js), a proporção entre o tamanho do arquivo de junção resultante e o
tamanho do arquivo do produto cartesiano.
25
Para uma consulta complexa o número de planos de consulta diferentes que são
equivalentes pode ser muito grande. Várias técnicas são utilizadas para reduzir ainda mais o
custo da pesquisa por uma grande quantidade de planos. Para Silberschatz (2006, p.395),
Ao examinarmos os planos para uma expressão, podemos terminar depois
que examinarmos apenas uma parte da expressão, isso se determinarmos
que o plano mais barato para essa parte já é mais dispendioso do que o
plano de avaliação mais barato para uma expressão completa examinada
anteriormente.
A redução ainda maior do número de planos de execução pode ser conseguida
através de uma escolha heurística de um bom plano e estimando seu custo. Essas
otimizações podem diminuir significativamente a sobrecarga da otimização de consulta.
O SQL SERVER introduz grande complexidade nos otimizadores de consulta. Existem
diferentes técnicas de otimização, sendo que alguns sistemas como Microsoft SQL SERVER
são baseados em regras de equivalência, que possui como benefício à facilidade de
estender o otimizador com novas regras. De acordo com Silberschatz (2006), para que a
técnica funcione de modo eficiente, é preciso que haja técnicas eficientes para detectar
derivações duplicadas e uma forma de programação dinâmica para evitar a reotimização
das mesmas subexpressões.
4.1.6 Otimizando subconsultas aninhadas
No SQL SERVER, subconsultas são consultas aninhadas, que pode ser utilizada em
SELECT, INSERT, UPDATE ou DELETE, ou mesmo em subconsulta. Existem dois tipos de
subsconsultas aninhadas: Correlacionada e não correlacionada.
Subconsultas correlacionadas são consultas, onde a consulta aninhada depende de
campos da query externa. Quando se utiliza uma subquery correlativa com o comando
EXISTS, a perfomance é igual ao do INNER JOIN.
SELECT p.ProductID, p.Name, p.ListPrice
FROM Production.Product AS p
WHERE EXISTS (SELECT * FROM Sales.SalesOrderDetail AS sod
WHERE p.ProductID = sod.ProductID )
26
No exemplo abaixo, fazendo a mesma query com o INNER JOIN
SELECT DISTINCT p.ProductID, p.Name, p.ListPrice
FROM Production.Product AS p
INNER JOIN Sales.SalesOrderDetail sod ON p.ProductID = sod.ProductID
Subquery não-correlacionada – A subquery não depende de campos da query externa.
SELECT p.ProductID, p.Name, p.ListPrice
FROM Production.Product AS p
WHERE p.ListPrice > (SELECT AVG(p2.ListPrice) FROM Production.Product AS p2)
As tabelas derivadas – Quando a SELECT é embutido na clausula FROM.
SELECT B.BusinessEntityID, b.Jobtitle, a.NumTitle
FROM (SELECT e.JobTitle, COUNT(*) numtitle FROM HumanResources.Employee e
GROUP BY e.JobTitle) AS a
INNER JOIN HumanResources.Employee b ON b.JobTitle = a.JobTitle.
Demais exemplos:
Comando IN
SELECT Name, p.ProductSubcategoryID
FROM Production.Product p
WHERE ProductSubcategoryID IN ( SELECT ProductSubcategoryID FROM
Production.ProductSubcategory WHERE Name = 'Wheels' );
O mesmo exemplo que o acima, mas usando o JOIN ao invés do IN. A diferença é
que com o JOIN, consegue-se pegar os campos das duas tabelas e usar no SELECT, já
com o IN isso não é possível.
SELECT p.Name, s.Name, p.ProductSubcategoryID
FROM Production.Product p
INNER JOIN Production.ProductSubcategory s ON p.ProductSubcategoryID =
s.ProductSubcategoryID AND s.Name = 'Wheels';
27
Utilizando Valores no IN.
SELECT Name, ProductSubcategoryID
FROM Production.Product
WHERE ProductSubcategoryID IN (12, 17);
Utilizando o comando NOT IN
SELECT Name
FROM Production.Product
WHERE ProductSubcategoryID NOT IN ( SELECT ProductSubcategoryID FROM
Production.ProductSubcategory WHERE Name = 'Mountain Bikes' )
28
5.
SINTONIZAÇÃO
(TUNING)
DE
BANCO
DE
DADOS
EM
SISTEMAS RELACIONAIS
É de extrema importância que no projeto físico inicial de desenvolvimento de um
banco de dados sejam tomados certos cuidados, para que, quando o banco de dados esteja
em operação, fazendo uso das aplicações, transações, consultas e visões, não ocorram
problemas. É preciso realizar estimativas seguras de volumes de atividades e os tamanhos
dos dados e constantemente monitorar e revisar o projeto.
Para Elmasri e Navathe, “A utilização dos recursos, bem como o processamento
interno do SGBD, tais como otimização de consultas, podem ser monitorados para revelar
gargalos, como a disputa pelos mesmos dados ou dispositivos”. (2005, p.389). Os objetivos
da sintonização são:
•
Permitir que as aplicações sejam executadas mais rapidamente;
•
Fazer com que as consultas/transações possam ter um tempo de resposta menor;
•
Melhorar o desempenho geral das transações;
A sintonização pode ser considerada como um ajuste continuado do projeto, pois as
mesmas decisões do projeto precisam ser revistas. Os SGBDs podem coletar as seguintes
estatísticas:
•
Tamanhos de tabelas individuais;
•
Número de valores distintos em uma coluna;
•
Número de vezes que uma consulta ou transação em particular é submetida ou
executada num determinado intervalo de tempo;
•
Os tempos necessários para as diferentes fases do processamento de consultas e
transações (para um dado conjunto de consultas e transações).
A sintonização de um banco de dados envolve tratar os seguintes tipos de problemas:
•
Como evitar excessivas disputas por bloqueios, para que não ocorra a concorrência
entre as transações;
29
•
Como diminuir a sobrecarga dos registros de logs e o armazenamento
desnecessário de dados;
•
Como realizar a otimização do tamanho do buffer e o escalonamento de processos;
•
De que maneira alocar recursos, como discos, RAM e também processos para que
haja uma utilização mais eficiente;
Os DBAs passam por treinamentos para tratar de problemas de sintonização em
SGBDs específicos. Alguns problemas podem ser resolvidos através de ajustes de
parâmetros físicos do SGBD, como alteração da configuração de dispositivos, de
parâmetros do sistema operacional e de outras atividades similares.
É preciso levar em consideração vários aspectos para que se consiga um
desempenho adequado de um banco de dados. Para isso é necessário tomar algumas
decisões durante o projeto.
De acordo com Carneiro (2009), uma das principais considerações a se levar em
conta na fase de projeto é quanto ao volume esperado de dados em cada relação do
sistema e quais consultas serão realizadas com mais freqüência. Porém, em alguns
sistemas percebe-se o real desempenho, somente após algum tempo de uso, e também
muitas vezes, as considerações feitas pelos projetistas podem estar equivocadas. Por isso
que se tornam necessários o monitoramento e a revisão do projeto físico de banco de
dados, para descobrir a existência de gargalos ou mesmo a disputa dos mesmos dados ou
dispositivos. Através desse monitoramento, algumas outras informações são obtidas, tais
como:
•
Estatísticas de armazenamento: dados a respeito da alocação de armazenamento
para espaço de tabelas, espaço de índices e portas de buffer.
•
Estatísticas de desempenho de I/O: atividade total de leitura/escrita (paginação) do
disco.
•
Estatísticas de processamento de consultas: Quantidade de tempo utilizado para
execução de cada consulta e também do tempo de otimização das mesmas.
•
Estatísticas relacionadas a bloqueios/registros de log: taxas de definição de
diferentes bloqueios, de desempenho de transações e registros de log de atividades.
Apesar das estatísticas acima referirem-se a transações, controle de concorrência e
recuperação de dados, o tuning de banco de dados trata diretamente de problemas
relacionados a excessivas disputas, que podem ser amenizados por meio de bloqueios,
aumentando a concorrência entre as transações, minimizando a sobrecarga de registros,
30
logs e o armazenamento desnecessário dos dados. Também é de extrema importância que
seja feita a otimização do tamanho do buffer e o escalonamento de processos, bem como,
alocar recursos de memória, discos e processos para uma utilização mais eficiente.
5.1 Sintonização do projeto de banco de dados
De acordo com Elmasri e Navathe, “Se um dado projeto físico de banco de dados não
atinge os objetivos esperados, podemos voltar ao projeto lógico do banco de dados, fazer
ajustes no esquema lógico e remapeá-lo num novo conjunto de tabelas e índices físicos”.
(2005, p. 390).
Todo projeto de banco de dados deve ser direcionado por requisitos de
processamento e requisitos de dados, nos quais o primeiro altera-se dinamicamente, sendo
necessário o projeto responder por meio de alterações no esquema conceitual, refletindo
tais mudanças no esquema lógico e físico do projeto. Elmasri e Navathe, citam algumas
dessas alterações, (2005, p.390, 391):
•
Tabelas existentes podem ser desnormalizadas, porque certos atributos de duas ou
mais são freqüentemente necessários em conjunto;
•
Pode haver outras escolhas alternativas no projeto, para um dado conjunto de
tabelas;
•
Uma relação da forma R(K, A, B, C, D, ...), onde K é um conjunto de atributos-chave
(que está na FNBC), pode ser armazenada em múltiplas tabelas que também estão
na FNBC, replicando-se a chave K em cada tabela, como exemplo, R1 (K, A, B),
R2(K, C, D) e R3(K, ...). Dá-se o nome de partição vertical;
•
Atributo(s) de uma tabela pode(m) ser repetido(s) em outra mesmo que isso crie
redundância e uma anomalia potencial;
•
Da mesma forma que a partição vertical divide uma tabela verticalmente em
múltiplas tabelas, a partição horizontal toma fatias horizontais de uma tabela e as
armazena como tabelas distintas. Por exemplo, os dados de vendas de produtos
podem ser separados em dez tabelas baseadas em dez linhas de produtos. Cada
31
tabela possui o mesmo conjunto de colunas (atributos), porém, contém um conjunto
distinto de tabelas.
5.1.2 Sintonização de consultas
Há principalmente duas indicações pela qual a sintonização da consulta pode ser
indicada, segundo Elmasri e Navathe (2005, p. 391):
1.
Quando existem muitos acessos a disco resultantes de uma consulta;
2.
Um plano de consulta mostra que os índices relevantes não estão sendo
utilizados;
Situações típicas que indicam a necessidade de sintonização de consultas:
•
Muitos otimizadores de consulta não utilizam índices na presença de expressões
aritméticas, de comparações numéricas de atributos de diferentes tamanhos e níveis
de precisão, comparações com NULL e comparações com substrings;
•
Freqüentemente os índices não são utilizados em consultas aninhadas usando IN;
•
Algumas cláusulas DISTINCT podem ser redundantes e podem ser evitadas sem a
modificação do resultado, pois ele causa uma operação de ordenação e deve ser
evitado sempre que possível.
•
O uso desnecessário de tabelas de resultado temporário pode ser evitado por meio
da aglutinação de múltiplas consultas em uma única consulta, a menos que a relação
temporária seja necessária para algum processamento intermediário. Em algumas
situações que envolvem o uso de consultas correlacionadas, os temporários são
úteis;
•
Se for possível utilizar várias opções de condições de junção, a melhor opção é a
escolha que use um índice clustered, e evite as que contenham comparações de
cadeias de caracteres;
•
Uma particularidade dos otimizadores de consulta é que a ordem das tabelas na
cláusula FROM pode afetar o processamento de junções. Às vezes, é necessário
32
alterar a ordem de forma que a menor das relações seja varrida e a maior relação
usada como um índice adequado;
5.2 Possíveis causas para o baixo desempenho
A causa do baixo desempenho pode estar relacionada ao hardware, que inclui a rede
disponível, processador, memória RAM, entre outros, ou também nos softwares. Esses
problemas geram gargalos que interferem no bom desempenho do banco de dados.
Quando se trata de banco de dados relacional as causas de baixo desempenho
também podem estar relacionadas a(o):
a) Sistema operacional (SO), por razões de má parametrização;
b) SGBD relacional, relacionada às inadequadas configurações nas áreas de buffers,
organização do logging, alocação de arquivos, entre outros;
c) Rede, devido a impactos no tráfego em razão de processamento de dados
efetuados no servidor ou na rede;
d) Modelo físico de dados, por razão de inadequação na definição da estrutura das
tabelas e índices;
e) Aplicação, com relação a problemas na estrutura lógica efetuada pelo
programador, o que compreende a linguagem hospedeira e os comandos em SQL
SERVER.
Entretanto, segundo Picini e Schimiguel, os problemas estão relacionados pela
seguinte proporção:
•
60% correspondem ao mau uso de expressões SQL;
•
20% estão relacionados à má modelagem do BD;
•
10% referem-se à má configuração do SGDB;
•
10% referem-se à má configuração do SO;
Além disso, é importante citar que o conhecimento sobre a aplicação influencia
bastante, pois a baixa performance pode não estar ligada diretamente ao banco. Outro fator
importante é que as alterações devem ser realizadas aos poucos, divididas e analisadas
verificando os resultados um a um, pois se vários procedimentos forem modificados ao
mesmo tempo, corre-se o risco de não perceber algum erro e não conseguir repará-lo com
facilidade.
33
De acordo com Mullins (2005), “Quase 80% dos problemas de performance em banco
de dados são causados por códigos SQL mal elaborados”. Reduzir o tempo dos SQL e o
custo é importantíssimo para que uma grande parte dos problemas seja reduzida.
5.3 Aumentando a performance da aplicação através da otimização
do SQL SERVER
De acordo com Couto (2006), existem algumas observações a serem feitas para
aumentar a performance do banco de dados, como:
•
Definir corretamente o buffer do banco de dados (shared_pool, buffer chache, log
buffer, etc.), colocando os objetos grandes e muito acessados em memória para
prevenir freqüentes reloads;
•
É necessário que os arquivos de banco de dados estejam com o tamanho correto e
um local que prove um mínimo de I/O;
•
Observar os eventos que acontecem no banco relativo à locks, latches e wait e se
possível eliminá-los.
•
Monitorar e definir os parâmetros de CPU, I/O e memória de forma a melhorar o
desempenho do banco;
Como já explicado anteriormente, a otimização consiste em mostrar ao usuário a
informação com tempo e custo menores, através do caminho mais eficiente.
Couto (2006), ainda explica em seu artigo que a metodologia de tuning de SQL
envolve identificar as queries que consomem mais recursos para então otimizá-las.
Geralmente, um número pequeno de queries é responsável pela maior parte das atividades
que ocorrem no banco de dados. É essencial que se tente entender por completo a
aplicação, focando a atenção nos SQL ou tabelas onde os benefícios do tuning excederão
os custos. Devem-se observar alguns passos:
•
É preciso ter certeza de que o código esteja correto antes de otimizá-lo;
•
Garantir a escrita igual dos comandos para facilitar a reutilização;
•
Trazer apenas as informações necessárias do banco de dados;
34
•
Sempre manter atualizado as estatísticas das tabelas;
•
Identificar problemas potenciais antes de mandá-los para produção;
•
Otimizar primeiro os SQL mais críticos, não perdendo tempo otimizando códigos que
raramente são utilizados;
•
Utilizar índices, porém não criá-los em demasia. Alguns índices podem trazer um
resultado com efeito adverso no desempenho. O critério básico da escolha de
índices é a seletividade. Quando um banco de dados resolve uma consulta,
geralmente, ele precisa percorrer mais registros do que aqueles realmente
retomados pela consulta. Os registros percorridos que forem rejeitados representam
o trabalho perdido. Quanto menor for o trabalho perdido, mais perto estará da
performance ótima para resolver a consulta;
•
Construir índices a partir das restrições dos SELECTs (cláusula WHERE); As
comparações usando “<>”, “NOT”, “NULL”, “LIKE” podem invalidar o índice;
•
Evitar full table scans se o resultado pode ser recuperado via índice, a menos que a
tabela seja pequena e o custo diminua. Quando a tabela é pequena, o trabalho
envolvido em acessar o índice, pegar o endereço e acessar a tabela é maior que o
esforço de ler a tabela inteira;
•
Queries muito grandes devem ser divididas em queries menores. Lógicas complexas
de negócio no SQL devem ser evitadas;
•
Evitar usar os comandos que produzem sort como: GROUP BY, ORDER BY,
DISTINCT, etc. No sort, o banco recupera todas as informações necessárias
primeiramente, para após realizar a ordenação;
•
Os comandos “EXIST” e “NOT EXIST” geralmente possuem menor custo do que
comandos como “IN” e “NOT IN”.
•
A condição NOT deve ser transformada em uma expressão afirmativa;
•
Substituir por junções os blocos SELECT embutidos utilizando IN, =ALL, =ANY e
=SOME;
•
Se uma junção de igualdade for definida entre duas tabelas, o predicado de faixa
(condição de seleção) para o atributo de junção definido em uma tabela pode ser
repetido para a outra tabela;
35
6.
ÍNDICES NO SQL SERVER
Um índice torna rápida a recuperação de linhas de uma tabela, pois contém chaves de
uma ou mais colunas da tabela que são criadas e armazenadas em uma estrutura de
árvore. Desta maneira o SQL SERVER faz a associação dos valores de chave com as
linhas de pesquisa. Os índices podem ser:
Clustered: Através dos valores de chave é que esse tipo de índice classifica e
armazena suas linhas de dados. Por existir apenas um índice desse tipo em uma tabela, a
classificação das linhas de dados é feita em ordem única.
Quando a tabela não possui um índice clusterizado, seus dados ficam armazenados
numa estrutura denominada heap. Denomina-se heap porque os dados não têm uma ordem
lógica e são gravados nas páginas que tem espaço disponível. As páginas de dados não
são ligadas a uma lista vinculada. O espaço alocado para o heap é gerenciado pela coluna
de páginas Index Allocation Map (IAM). A movimentação pelo heap é feita pelo SQL
SERVER através das páginas IAM. Não existe vínculo entre as páginas de dados e as
linhas dentro delas.
Não Custerizado: Nesse tipo de índice a estrutura é diferente das linhas de dados,
pois possui um ponteiro que armazena o valor de chave do índice. O ponteiro de uma linha
de índice é denominado localizador de linhas.
Os dois tipos de índices podem ser exclusivos, garantindo que duas linhas não tenham
o mesmo valor que a chave do referido índice.
No momento da criação de uma tabela, quando se define restrições de Primary Key e
Unique os índices são automaticamente criados na coluna.
6.1 Estruturas de índices clusterizados
No SQL SERVER, os índices são organizados como árvores B. Pelo fato de ser
balanceada, a árvore B localiza qualquer registro, propiciando o rápido acesso aos dados
através da pesquisa de um valor-chave do índice.
36
Cada página em uma árvore B de índice é chamada de nó do índice. Os nós inferiores
são conhecidos por folha, os superiores por raiz e qualquer um que esteja entre os dois são
conhecidos como níveis intermediários. Os nós folha possuem as páginas de dados da
tabela subjacente. Já os nós raiz e intermediário, possuem páginas de índices com linhas de
índice.
Cada índice clusterizado, tem um particionamento único. Caso algum índice possua
particionamentos múltiplos, cada um terá uma estrutura de árvore B com os dados
específicos dele. Para cada particionamento usado pelo índice, os índices clusterizados tem
uma linha em sys.partions com índex_id = 1.
Os tipos de dados é que definem a estrutura de alocação para armazenar e gerenciar
o índice. Cada índice possui no mínimo uma unidade de alocação IN_ROW_DATA (linhas
de dados ou índices que contenham todos os dados, exceto dados de LOB), LOB_DATA
(dados
de
objeto
grande
armazenados
em
um
ou
mais
tipos
de
dados)
e
ROW_OVERFLOW_DATA (excesso do tamanho de linha).
O SQL SERVER possui métodos específicos para localizar a linha correspondente a
uma chave de índice clusterizado.
Figura 6.1 - Árvore B para um índice clusterizado.
Fonte: http://www.batebyte.pr.gov.br/modules/conteudo/conteudo.php?conteudo=1184
37
6.1.2 Estruturas de índices não clusterizados
Os índices não clusterizados possuem a mesma estrutura de árvore B que os índices
clusterizados, com algumas diferenças importantes:
•
Não existe uma ordem na classificação e no armazenamento das linhas de dados;
•
A camada de folha de um índice possui páginas de índice, diferente do índice
clusterizado que possui página de dados;
Cada linha desse índice possui o valor de chave e um ponteiro que aponta para a linha
de dados no índice clusterizado ou no heap.
É chamado de RID, o ponteiro que é criado através de um identificador do número de
página e o número da linha do arquivo.
Figura 6.2 - Árvore B para um índice não clusterizado.
Fonte: http://www.batebyte.pr.gov.br/modules/conteudo/conteudo.php?conteudo=1184
38
6.1.3 De que maneira o Otimizador sabe quando utilizar os
índices?
Visando sempre o melhor desempenho no momento de realizar operações, os índices
são grandes aliados em muitas instruções como SELECT, UPDATE, DELETE ou MERGE.
Um exemplo é quando uma consulta é realizada, o otimizador lê as linhas da tabela, estuda
as possibilidades de recuperação de dados e escolhe qual é o método mais eficaz, filtrando
assim as que atendem a pesquisa solicitada. Porém, todo esse trabalho do otimizador gera
várias operações de I/O e muitos recursos são exigidos.
Quando o otimizador não encontra um índice disponível, ele realiza a verificação de
tabela para que assim possa criar e projetar índices que serão apropriados. Essa é outra
importante função do Otimizador de consulta.
No SQL SERVER existe uma ferramenta que auxilia na análise e seleção de índices
mais apropriados que é chamada de “Orientador de otimização do mecanismo de banco de
dados”.
Geralmente os índices contêm poucas colunas por linha e ficam classificadas em
ordem, tornando assim, bem mais rápida a busca do que se fosse feita na tabela. Quando a
pesquisa é feita através do índice, o otimizador busca as colunas de chave e encontra o
local pelo qual estão armazenadas as linhas para aquela consulta específica.
6.2 Páginas e extends
Um arquivo de dados (.mdf ou .ndf) no SQL SERVER é armazenado em páginas
contíguas, que possuem o tamanho de 8 Kilobytes (KB). A leitura ou a gravação são feitas
em páginas de dados inteiras. A quantidade de páginas por megabytes (MB) é de 128,
sendo que a página inicia-se com um cabeçalho de 96 bytes, onde ficam armazenadas as
informações de sistema, como número, tipo, quantidade de espaço livre e o ID de alocação
do objeto da página. Em seguida, iniciam-se as linhas de dados.
39
O máximo de dados que uma linha suporta é 8.060 bytes (8KB), não incluindo os
dados armazenados em tabelas que possuem colunas varchar, nvarchar, varbinary ou
SQL_variant. Caso ocorra excesso de dados, o SQL SERVER move uma ou mais colunas
de comprimento variável para páginas na unidade chamada de ROW_OVERFLOW_DATA.
Se houver diminuição do tamanho da linha, através de uma operação subseqüente, o SQL
SERVER transportará novamente a coluna para a página de dados original.
Já as extensões, são um conjunto de oito páginas contíguas ou 64 KB e tem como
função o gerenciamento eficaz das mesmas. Sendo assim, o SQL SERVER têm 16
extensões por MB. O SQL SERVER possui dois tipos de extensões:
•
Uniformes: Possui um objeto proprietário;
•
Mistas: Podem ser compartilhadas por até oito objetos, podendo cada página
pertencer a um objeto diferente;
Geralmente, quando a tabela ou índice é novo, utiliza-se a alocação de páginas de
extensões mistas. Porém quando há um crescimento, passa-se a utilizar a alocação por
extensões uniformes.
Figura 6.3 - Árvore B padrão para um índice do SQL SERVER.
Fonte: http://www.batebyte.pr.gov.br/modules/conteudo/conteudo.php?conteudo=1184
6.2.1 Unidade de alocação IN_ROW_DATA
É composta por coleções de páginas de dados que são baseados em ponteiros de
página na exibição de sistema. Cada partição de tabela, índice e exibição indexada é
identificada por um ID de contêiner (container_ID).
40
6.2.2 Unidade de alocação ROW_OVERFLOW_DATA
Existe uma unidade de alocação ROW_OVERFLOW_DATA para toda partição usada
por uma tabela, índice ou exibição indexada. Possui zero página até que uma linha de
dados exceda o limite. Caso isso aconteça, o SQL SERVER move uma coluna com a
largura maior daquela linha para uma página na unidade de alocação.
6.2.3 Unidade de alocação LOB_DATA
Gerencia o armazenamento de diferentes tipos de dados, tais como text, ntext, image,
xml, varchar(max), nvarchar(max), varbinary(max) e tipos de dados Common Language
Runtime (CLR) definidos pelo usuário.
6.3 Sintonização de índices
De acordo com Pilecki, “O índice é, em essência, uma cópia menor da tabela,
contendo um subconjunto de colunas da tabela. Apenas as colunas necessárias para
responder as consultas são incluídas no índice”.
Utiliza-se a criação de índices abrangentes para ajustes nas consultas executadas
com maior freqüência. É essencial em casos em que a tabela possui várias colunas, porém
apenas algumas delas são freqüentemente referenciadas por consultas. Dessa maneira,
criando um ou mais índices abrangentes, é possível melhorar muito o desempenho das
consultas afetadas, pois elas estarão acessando um volume de dados bem menor e, assim,
incorrendo em menor I/O. Todavia, há um custo oculto de manutenção de índices adicionais
durante as operações de modificação de dados (INSERT, UPDATE e DELETE).
Às vezes torna-se necessária uma revisão para a escolha inicial de índices, pelas
seguintes razões, segundo Elmasri e Navathe, (2005, p.389, 390):
•
Devido à ausência de um índice, certas consultas podem demorar demais para
serem executadas;
41
•
Alguns índices podem não ser utilizados;
•
Certos índices podem estar causando sobrecarga excessiva, porque são baseados
em um atributo que sofre freqüentes alterações;
A maioria dos SGBDs possui um comando ou um meio de rastreamento (trace facility)
que pode ser usado para solicitar ao sistema quais operações foram realizadas e em que
ordem e quais estruturas de acesso secundário foram utilizadas, pois assim, através dessas
análises de planos de execução, é possível diagnosticar as causas dos problemas citados
acima.
Segundo Elmasri e Navathe, “O objetivo da sintonização é avaliar dinamicamente os
requisitos, os quais às vezes variam sazonalmente ou durante diferentes períodos do mês
ou da semana e reorganizar os índices para proporcionar melhor desempenho geral”. (2005,
p. 390).
42
7.
O PLANO DE EXECUÇÃO NO SQL SERVER
É através dos dados armazenados nas estatísticas das tabelas, referentes aos
registros das tabelas, que o SQL SERVER decide qual será o melhor plano de execução a
escolher. Desta maneira, é de suma importância manter as estatísticas sempre atualizadas,
pois do contrário, o otimizador não terá informações necessárias para aperfeiçoar
determinada consulta, gerando assim, um plano de execução com estimativas erradas.
Quando uma solicitação é feita e enviada ao servidor, a mesma é guiada por um plano de
execução, que se bem executado, trará o mais eficiente caminho da solicitação. O plano de
execução também auxilia na identificação qual parte do código SQL que está causando o
problema.
O plano de execução é composto por operadores que na maioria das vezes são
aplicados em certa ordem. É através do plano de execução, que se determina a ordem e
acesso das tabelas que estão envolvidas na query, quais índices que serão utilizados e
métodos para aplicá-los.
7.1 O otimizador de consulta
O otimizador do SQL gera diversos planos, mas escolhe o que apresenta melhor
performance, ou seja, o que apresenta o menor tempo para responder a consulta. Ele é
quem decide como os dados serão acessados, por meio de índices, os tipos de JOINs a
utilizar. É através de cálculos de custo, como processamento de CPU e operações de I/O,
gerados pelo plano de execução que determinará qual será o caminho mais rápido de
execução. É importante ressaltar que o custo estimado é apenas uma estimativa.
Em casos, onde é realizada uma consulta simples, o otimizador não perde tempo
tentando calcular o plano ideal, ele simplesmente aplica um plano trivial único a estes tipos
de procedimentos. Porém, se a consulta não é trivial, o otimizador realiza um custo base de
cálculo para selecionar um plano, baseado em estatísticas que são mantidas pelo SQL
SERVER. Porém, nem todas as possibilidades são avaliadas, pois o custo é muito alto e
desta forma compromete-se o ganho do desempenho. O plano de execução é determinado
através de testes com diferentes associações, reorganizando a ordem de junções, tentando
43
diferentes índices e assim sucessivamente até chegar ao que ele pensa ser o plano mais
rápido.
7.2 Plano de execução estimado e plano de execução real
Existem dois tipos de planos de execução. O primeiro, conhecido como plano de
execução estimado é o que representa a saída do otimizador. Os operadores, ou etapas,
são representativos dos otimizadores de vista do plano. O próximo, mais conhecido como
plano de execução real representa a saída da execução da consulta atual, o qual mostra o
que realmente aconteceu quando a consulta foi executada.
Geralmente, não existe diferença entre os dois planos, todavia algumas circunstâncias
causam diferenças, como:
•
Estatísticas desatualizadas, que ocorrem ao longo do tempo, quando dados são
adicionados e excluídos, fazem com que ocorram diferenças entre elas e os dados
reais;
•
Em alguns casos, como os que utilizam tabela temporária, uma vez que a consulta
não tenha sido executado, a tabela temporária também não existirá e desta maneira
o plano de estimativa não irá funcionar;
•
Em casos de requisições de consultas paralelas, quando o plano encontra
paralelismo, no qual dois planos de execução são criados.
7.2.1 Formato dos planos
O SQL SERVER oferece apenas um tipo de plano de execução, sendo três diferentes
formatos:
• Planos gráficos (Graphical plans);
• Planos de texto (Text plans);
• Planos XML (XML plans);
44
Planos gráficos: Oferecem uma maneira rápida e fácil de leitura, porém os dados
nesse tipo de plano ficam mascarados. Tanto o plano atual, como o estimado podem ser
vistos da mesma maneira.
Planos de Texto: Considerado um pouco mais difícil de ler, contudo, a informação é
encontrada imediatamente. Existem três formatos:
•
SHOWPLAN_ALL: conjunto completo de dados, que mostra o plano de execução
estimado para o plano de consulta.
•
SHOWPLAN_TEXT: Mostra apenas o plano de execução estimado. Fornece um
conjunto muito limitado de dados, que são usados com ferramentas como osql.exe.
•
STATISTICS_PROFILE: é praticamente similar ao SHOWPLAN_ALL, com exceção
que representa os dados para o plano de execução real.
Planos XML: Esses planos apresentam o mais completo conjunto de dados
disponíveis num plano, com a estrutura no formato de XML. Existem duas formas:
•
SHOWPLAN_XML: É utilizado pelo plano de estimativa, pois é gerado pelo
otimizador antes da execução.
•
STATISTICS_XML: Utilizado pelo plano de execução real.
A seguir, exemplos de Planos de Texto (TEXT plans) e Planos XML (XML plans):
45
Figura 7.1 – Exemplo de um plano de texto estimado usando os comandos SET
SHOWPLAN_ALL ON e SET SHOWPLAN_ALL OFF.
Figura 7.2 – Exemplo de um plano de texto estimado usando os comandos
SHOWPLAN_TEXT ON e SHOWPLAN_TEXT OFF.
46
Figura 7.3 – Exemplo de um plano de texto real usando os comandos SET
STATISTICS_PROFILE ON e SET STATISTICS_PROFILE OFF.
Figura 7.4 – Exemplo de um plano XML estimado usando os comandos SET
SHOWPLAN_XML e SET ON e SHOWPLAN_XML OFF.
47
Clicando no link gerado, o SQL direcionará para outra janela, na qual abrirá o plano de
execução no formato XML, conforme demonstra a figura abaixo:
Figura 7.5 – Exemplo de um plano de execução em XML.
Através da exibição desses planos é claramente possível observar que o
SHOWPLAN_ALL é mais completo, pois exibe maiores informações de maneira imediata.
7.2.2 Interpretando planos de execução gráficos
Um plano de execução deve ser lido da direita para a esquerda e de cima para baixo.
Na figura abaixo, observa-se apenas que houve uma varredura de tabelas (table scan), no
qual se produziu um conjunto de resultados, representados através do comando SELECT. A
quantidade de dados que são passados na consulta, é o fator que representa a espessura
da seta, pois quanto mais grossa a linha, maior será a quantidade de dados. É possível
saber o número de linhas representado, passando o ponteiro do mouse sobre as flechas,
confirmando assim se o número apresentado está correto. Na figura 7.6 é possível
visualizar:
48
Figura 7.6 – Exemplo de um plano de execução gráfico.
Abaixo de cada ícone exibi-se um número com uma porcentagem, que representa o
custo relativo à consulta para esse operador. Esse custo que é retornado pelo otimizador, é
o custo do tempo de execução para aquela determinada operação. No caso da consulta do
exemplo acima, o custo maior refere-se à operação “table scan”, que ocorre quando o
mecanismo de armazenamento é obrigado a ler linha por linha, retornando todas as
informações, pois nenhuma outra cláusula foi especificada, como a cláusula WHERE.
Entretanto, é importante ressaltar que como as porcentagens referem-se a razões e não
números reais, então mesmo um operador que tenha 0 % terá um pequeno custo associado.
Acima dos ícones é possível visualizar o custo de 100% que representa grande parte
da seqüência de consulta. Desta maneira, como cada consulta pode ter várias etapas, e
cada uma dessas etapas tem um custo em relação à consulta, é possível executar também
diversas consultas dentro de um lote e obter planos de execução para eles.
Passando o ponteiro do mouse sobre o ícone SELECT, observa-se os dados que são
apresentados na figura 7.7:
49
Figura 7.7 – Dados resultantes do ícone SELECT no plano de execução gráfico
•
Cached plan size ou tamanho do plano em cachê: Quantidade de memória em
cachê, que a consulta terá, demonstrado através do plano de execução. Através
desse número, é possível diagnosticar problemas de desempenho, selecionando os
planos que estão ocupando mais memória;
•
Degree of parallelism ou grau de paralelismo: Quantidade de planos de execução
gerados;
•
Estimated operator cost ou custo estimado do Operador: Custo estimado referente
ao operador, neste caso “SELECT”;
•
Estimated subtree cost ou custo estimado da Subárvore: Custo do otimizador
acumulado atribuído a esta etapa e todas as etapas anteriores. É importante
ressaltar novamente, que o plano de execução deve ser lido da direita para a
esquerda e de cima para baixo. Apesar de esse número ser insignificante no mundo
real, é uma avaliação matemática utilizado pelo otimizador.
•
Estimated numbers of rows ou número estimado de linhas: Estimativa referente ao
número de linhas da consulta.
Da mesma maneira, observam-se na figura 7.8, os dados demonstrados no ícone
Table Scan.
50
Figura 7.8 – Dados resultantes do ícone table scan.
Cada um dos diferentes operadores mostrados na figura acima terá um conjunto
distinto de dados.
Os operadores lógicos compõem o resultado dos cálculos de otimização que são feitos
quando uma consulta é executada. Os operadores físicos representam o que de fato
ocorreu. Na maioria das vezes esses operadores sempre são parecidos.
Em seguida, é possível observar as estimativas dos custos de operações de I/O, CPU,
e subárvore. A subárvore representa uma simples seção da execução, sempre analisando
da direita para a esquerda e de cima pra baixo. Todas as estimativas baseadas em
estatísticas referem-se a colunas e índices disponíveis nas tabelas. Os custos das
operações de I/O e de CPU representam o custo atribuído pelo otimizador através de
cálculos. Esses números são úteis para determinar se a maior parte do custo é de I/O, ou se
é necessário colocar uma carga na CPU.
O Custo do Operador e da subárvore são
parecidos, desde que haja apenas um operador. Para árvores mais complexas, com mais
51
operadores, o custo é acumulado individualmente para cada operador e depois adicionado
no total.
Em seguida, novamente pode-se observar a estimativa do número de Linhas.
Outra importante análise de informação, que também auxilia na solução de problemas
de desempenho, é a variável “Ordered ou Ordenada” que exibe o valor em booleano. Em
uma instrução SELECT, podem ser necessários que os dados sejam colocados em uma
determinada ordem, classificados por um determinado valor ou conjunto de valores.
Finalmente, Node ID é o número ordinal, que significa simplesmente numerado em
ordem, do próprio nó, da esquerda para a direita.
7.2.3 Facilitando a captura do plano de execução usando SQL
SERVER Profiler
Uma ferramenta poderosa existente no SQL SERVER, é o SQL Profiler, que realiza a
captura de dados sobre eventos, tais como a execução de T-SQL ou então procedimentos
armazenados, que ocorrem dentro do SQL SERVER.
Essa ferramenta mostra como o SQL SERVER resolve consultas internas fornecendo
uma interface gráfica para a funcionalidade oferecida pelo Rastreamento SQL. Com o SQL
SERVER Profiler, é possível capturar atividades geradas por uma carga de trabalho em uma
instância do SQL SERVER. Através de modelos pré-definidos, os eventos que são
capturados e exibidos podem ser definidos, e assim podendo realizar a modificação de
modelos fornecidos pelo sistema para criar os seus próprios. A carga de trabalho, que
servirá para uma futura avaliação, também pode ser capturada em uma tabela ou um
arquivo. Rastreamentos podem ser iniciados a qualquer momento a partir do SQL SERVER
Management Studio, baseado em seu contexto de conexão. O comando Rastrear Consulta
no SQL SERVER Profiler, auxilia no rastreamento da execução de instruções em uma
determinada sessão do Editor de Consulta, usando o SPID da janela de consulta como um
filtro.
Os eventos Profiler podem ser rastreados manualmente, ou através de uma interface
gráfica ou vestígios podem ser definidos através da T-SQL (ou o GUI) e automatizado para
52
executar em certos momentos e em certos períodos. Tais vestígios podem ser visualizados
na tela ou enviados para um arquivo ou uma tabela em um banco de dados.
Figura 7.9 - Exemplo de funcionamento do SQL profiler.
7.2.4 Eventos do plano de execução
Diversos eventos, como os listados abaixo, geram o rastreamento do plano de
execução:
•
Showplan
Text:
Parecido
com
o
plano
de
estimativa
que
o
evento
SHOWPLAN_TEXT gera, esse evento dispara a cada execução de uma consulta.
•
Showplan Text (unencoded): A mesma definição do anterior, porém com a diferença
que os dados são trazidos em forma de string e não como binário.
•
Showplan All: Possui o mesmo tipo de plano de execução que os anteriores,
apresentando também as mesmas dificuldades.
•
Showplan All para compilação de consulta: Esse evento possui os mesmos dados
que o Showplan All event, mas apenas dispara quando ocorre a compilação da
consulta.
53
•
Showplan Statistics Profile: Esse evento refere-se ao plano de execução real e utiliza
o comando STATISTICS PROFILE.
•
Showplan XML: É disparado a cada execução de consulta e usado para gerar o
plano de execução estimado, através do comando SHOWPLAN_XML.
•
Showplan XML para compilação de consulta: Igual ao Showplan XML acima, porém
só dispara quando alguma consulta está sendo compilada.
•
Performance Statistics: É similar ao Showplan XML para compilação de um evento
da consulta, com exceção que este evento captura métricas de desempenho e
também o plano. Este evento capta apenas a saída XML para subclasses em
determinados eventos. Ele é disparado toda vez que um plano está em cachê, é
compilado, recompilado ou é removido do cachê.
•
Showplan XML Statistics Profile: Esse evento gera o plano atual para cada consulta
executada.
7.3
Um pouco mais sobre planos gráficos
No plano de execução gráfico, são exibidos quatro tipos de operadores:
•
Operadores lógicos e físicos: Representam a execução da consulta ou a linguagem
de manipulação de dados (DML). São conhecidos como ícones azuis.
•
Operadores de paralelismo físico: Representam operações de paralelismo e também
são ícones azuis. De certa maneira, são subconjuntos dos operadores lógicos e
físicos, porém são considerados a parte, pois indicam um nível totalmente diferente
de análise do plano de execução.
•
Cursor de Operações: Possui ícones amarelos e representam transações de cursor
SQL.
•
Elementos de Linguagem: São representados por ícones verdes e representam
transações SQL de elementos de linguagem, como atribuição, declaração, If,
SELECT, While dentre outras.
54
Alguns operadores, como os de ordenação (sort), hash, match e junção de join exigem
uma quantidade variável de memória para executar e por causa disso, consultas com esses
operadores podem ter que aguardar por memória disponível antes da execução, podendo
assim afetar o desempenho. A maioria dos operadores comporta-se de duas maneiras
distintas: bloqueio e sem bloqueio. Um operador de bloqueio precisa para produzir sua
saída, obter todos os dados. Esse tipo de operador pode contribuir significativamente para
problemas de concorrência, prejudicando assim o desempenho. Já o operador sem bloqueio
recebe a entrada e ao mesmo tempo cria a saída.
Segue abaixo exemplos de simples consultas em Tabelas da Base de dados do
Adventure Works, no qual é possível observar alguns operadores que aparecem com mais
freqüência nos planos de execução:
Figura 7.10 – Operador Clustered index scan.
Os índices no SQL SERVER são armazenados em uma estrutura de árvore-B (uma
série de nós que aponta para um dos pais). Um índice clustered armazena não apenas a
estrutura essencial que é um índice regular, mas também armazena e classifica os dados,
sendo que existe apenas um índice clustered por tabela. Um clustered index scan possui
praticamente o mesmo conceito de um uma table scan. O índice percorre linha por linha
para identificar dados necessários para a consulta.
Às vezes, quando ocorre um index scan, é preciso saber se o plano de execução está
retornando mais linhas do que realmente é necessário. Desta maneira, há necessidade de
um fino ajuste na consulta utilizando a cláusula WHERE, para que assim o plano retorne
apenas as linhas que realmente são necessárias, pois caso contrário, ocorrerá o desperdício
de recursos do SQL SERVER, prejudicando o desempenho geral.
55
Figura 7.11 – Exemplo de consulta que retorna um clustered index scan
Figura 7.12 – Operador clustered index seek
Índices seek são totalmente diferentes dos índices scan, que percorrem linha a linha
para encontrar os dados que a consulta solicita. Um índice seek, clustered ou não, ocorre
quando o otimizador é capaz de localizar um índice que pode ser usado para recuperar os
dados feitos na solicitação da consulta. Sendo assim, o mecanismo de armazenamento
recebe a ordem para procurar os valores com base nas chaves do índice determinado. É
possível verificar nesse exemplo do índice seek, que a propriedade ORDERED agora é
verdadeira, indicando que os dados foram ordenados pelo otimizador.
56
Figura 7.13 – Exemplo de consulta que retorna um clustered index seek
Figura 7.14 – Operador nonclustered index seek
Como nos índices clustered, um índice nonclustered utiliza um índice para realizar a
busca de linhas a serem devolvidas. Esse tipo de índice acontece quando todos os dados se
encontram nele.
57
Figura 7.15 – Exemplo de consulta que retorna um nonclustered index seek
Figura 7.16 – Operador key lookup
58
O operador key lookup pode ser observado na figura abaixo:
Figura 7.17 – Exemplo de consulta que retorna um operador key lookup.
Conforme se observa esse plano envolve mais que uma única operação. Como dito
anteriormente, o plano deve ser lido da direita para a esquerda e de cima para baixo. A
primeira operação é relacionada a um índice seek, que não é um índice non-unique, nonclustered e non-covering. Um índice non-covering é um índice que não retorna todos os
dados necessários para uma consulta, pois não contém todas as colunas. Sendo assim, ele
força o otimizador a ler o índice cluster também, para que assim possa reunir todos os
dados solicitados e devolver a consulta.
59
Figura 7.18 – Dados resultantes do operador nonclustered index seek.
Nessa figura é possível observar as descrições de saída do índice seek como as
colunas como EmailAddress e ContactId.
60
Figura 7.19 – Dados resultantes do operador key lookup.
Observa-se na figura acima, que os valores-chave são utilizados na key lookup na
PK_Contact_ContactID índice clustered para encontrar as linhas correspondentes com a
lista de colunas de saída LastName e Phone.
A Key Lookup ou Bookmark Lookup como era chamado no SQL SERVER 2000 é visto
em tabelas com índices clustered. Esse operador demonstra que o otimizador não consegue
recuperar as linhas com uma única operação e por isso necessita de uma clustered Key (ou
linha ID) para que assim retorne as linhas correspondentes usando um índice clustered (ou
da própria tabela). O operador Key Lookup é quando temos uma tabela com um índice
clustered, e o índice non clustered busca a chave da pesquisa no outro índice.
A clustered Key indica que o desempenho da consulta pode beneficiar-se da presença
de um índice covering ou índices inclusos. A Key Lookup é sempre acompanhada da
operação de junção Nested Loop que combina os resultados das duas operações.
Figura 7.20 – Operador nested loops
61
A Nested Loop join é uma operação padrão de associação, e não indica por si só
problema de desempenho. Para que esse tipo de operação seja requisitado é preciso
combinar as linhas do Index Seek e Key Lookup. Caso um índice de cobertura esteja
disponível, a Key lookup não será necessária e o operador Nested Loops não aparecerá no
plano de execução gráfico.
Figura 7.21 – Operador sort
Quando outras cláusulas básicas são adicionadas a consulta, diferentes operadores
podem surgir. O operador Sort é muito simples. Geralmente usado para indicar quando o
otimizador de consulta classifica os dados dentro do plano de execução. Se uma cláusula
ORDER BY não especificar a ordem, a ordem padrão é ascendente.
Se esse operador não for realmente necessário, sugere-se que ele seja retirado, para
que assim diminua a sobrecarga.
Figura 7.22 – Operador table scan
Esse operador é bastante auto-explicativo. É possível verificar através de uma
varredura da tabela, as linhas que foram devolvidas, linha a linha.
62
Figura 7.23 – Exemplo de consulta que retorna um table scan.
A table scan pode ocorrer por diversos motivos, porém geralmente é porque não
existem índices úteis na tabela, sendo assim necessário o otimizador de consulta pesquisar
todas as linhas em ordem para identificar as linhas que devem ser retornadas.
Outro motivo comum pelo qual ocorre uma table scan é quando todas as linhas de
uma tabela são retornadas. Quando a maioria das linhas trazidas pelo otimizador retorna
cada uma um índice.
Em algumas vezes, na maioria em tabelas com poucos registros, o otimizador de
consulta determina que seja mais rápido realizar a varredura de cada linha do que utilizar
um índice para retornar as linhas.
Em casos onde a pesquisa é realizada em tabelas grandes e muitas linhas são
devolvidas, sendo necessário analisar e reescrever a consulta para que a mesma retorne
um número menor de linhas ou então adicionar um índice que seja apropriado para acelerar
o desempenho.
63
Figura 7.24 – Operador RID lookup
No exemplo da consulta abaixo é possível verificar a combinação entre o Index Seek e
a RID Lookup.
Figura 7.25 – Exemplo de consulta que retorna um operador RID lookup.
No resultado dessa consulta, o otimizador de consulta primeiramente executa um
Index Seek na chave primária. Enquanto o índice é útil na identificação de linhas que são
encontradas com a cláusula WHERE, todas as colunas de dados necessários não estão
presentes no índice.
64
Operadores Merge Join e Hash Match
Figura 7.26 – Operador merge join
Figura 7.27 – Operador hash match
Na consulta abaixo é possível verificar os operadores acima:
Figura 7.28 – Exemplo de consulta que retorna os operadores merge join e hash
match
Merge Join: O otimizador de consulta também pode executar uma junção MERGE,
que correspondem a linhas de tabelas de entrada devidamente ordenadas explorando a sua
ordem de classificação.
65
Hash Match: Operações Hash são a segunda operação mais cara do plano de
execução. Hashing é uma técnica de programação onde os dados são convertidos em uma
forma simbólica que torna mais fácil e rápida a procura. Por outro lado, é uma estrutura de
dados que divide todos os elementos em categorias regularizadas, permitindo o acesso
rápido aos elementos. A junção Hash Match ocorre quando o SQL SERVER une duas
tabelas, juntando linhas da menor com a maior, verificando as linhas que precisam ser
unidas e inserindo-as em uma outra tabela hash. Portanto, se ambas as tabelas são muito
grandes, um junção Hash Match pode ser muito ineficiente em comparação com outros tipos
de associações.
66
8.
ESTUDO DE CASO
8.1 O SGBD
O SGBD escolhido para realização deste estudo foi o SQL SERVER 2008.
8.1.2 Infraestrutura
•
Hardware:
Um servidor com processador Intel Core 2 duo T6600 - 2.20 GHz;
4 GB de memória RAM;
•
Software:
Abaixo segue relacionado respectivamente, o sistema operacional e a versão
correspondente ao SGBD SQL SERVER utilizados durante os testes:
•
Windows 7 Home Basic;
•
SQL SERVER 2008 R2;
8.2 Aplicação da metodologia
Os testes foram realizados a partir de consultas que sofrem alterações de acordo com
a utilização de métodos de junção diferentes, utilização ou não de índices, chaves primárias
e chaves de junção.
67
O desempenho é avaliado através do estudo dos planos de execução gerados para
cada consulta.
8.2.1 Base de dados
Para realização deste estudo de caso foi utilizada a base de dados AdventureWorks,
base esta, própria da Microsoft, contendo o tamanho de 20.10 MB.
8.2.2 Implementação das consultas
As
consultas
foram
desenvolvidas
utilizando
tabelas
do
banco
de
dados
AdventureWorks, as quais já possuem índices criados. Contudo, para complementar a
demonstração desse estudo de caso, foi criada uma nova tabela, e também seus índices
clustered e non clustered. Nessa nova tabela foram inseridos 60.346 registros.
O objetivo desse estudo de caso é demonstrar, dentre as consultas realizadas quais
apresentam diferenças com relação ao desempenho.
8.3 Testes
8.3.1 Teste 1 (subconsultas aninhadas – comandos EXISTS e
INNER JOIN)
No exemplo abaixo, uma subconsulta aninhada é executada, usando a cláusula
WHERE com o comando EXISTS.
68
a) SELECT p.ProductID, p.Name, p.ListPrice
FROM Production.Product AS p
WHERE EXISTS (SELECT * FROM Sales.SalesOrderDetail AS sod
WHERE p.ProductID = sod.ProductID )
Resultados obtidos:
•
Linhas afetadas: 266;
•
Tempos de Execução do SQL SERVER: CPU = 46 ms; tempo decorrido = 148 ms.
•
Tempo de análise e compilação do SQL SERVER: CPU = 0 ms; tempo decorrido = 0
ms.
•
TotalSubtreeCost: 0,384156
Plano de execução:
Figura 8.1 – Plano de execução gerado para o teste 1a
A consulta abaixo traz as mesmas informações que a anterior, porém ao invés de
utilizar o comando EXISTS, foi utilizado o comando INNER JOIN.
b) SELECT DISTINCT p.ProductID, p.Name, p.ListPrice
FROM Production.Product AS p
INNER JOIN Sales.SalesOrderDetail sod ON p.ProductID = sod.ProductID
69
Resultados obtidos:
•
Linhas afetadas: 266;
•
Tempos de Execução do SQL SERVER: CPU = 47 ms; tempo decorrido = 115 ms.
•
Tempo de análise e compilação do SQL SERVER: CPU = 0 ms; tempo decorrido = 0
ms.
•
TotalSubtreeCost: 0,384156
Plano de execução:
Figura 8.2 – Plano de execução gerado para o teste 1b
Observa-se nos casos acima, que não houve diferença relevante entre as duas
consultas. Portanto, nesses casos os comandos EXISTS e INNER JOIN possuem a mesma
funcionalidade.
8.3.2 Teste 2 (Transformando expressões NOT em expressões
afirmativas)
a) SELECT Name,ProductSubcategoryID
FROM Production.Product
WHERE ProductSubcategoryID NOT IN ( SELECT ProductSubcategoryID FROM
Production.ProductSubcategory WHERE Name = 'Mountain Bikes' )
ORDER BY ProductSubcategoryID
70
Resultados Obtidos:
•
Linhas afetadas: 263;
•
Tempos de Execução do SQL SERVER: CPU = 0 ms; tempo decorrido = 0 ms.
•
Tempo de análise e compilação do SQL SERVER: CPU = 7 ms; tempo decorrido = 7
s.
•
TotalSubtreeCost: 0,0927731
Plano de execução:
Figura 8.3 – Plano de execução gerado para o teste 2a
b) SELECT Name,ProductSubcategoryID
FROM Production.Product
WHERE ProductSubcategoryID IN ( SELECT ProductSubcategoryID FROM
Production.ProductSubcategory WHERE Name <> 'Mountain Bikes' )
ORDER BY ProductSubcategoryID
Resultados obtidos:
•
Linhas afetadas: 263;
•
Tempos de Execução do SQL SERVER: CPU = 0 ms; tempo decorrido = 0 ms.
•
Tempo de análise e compilação do SQL SERVER: CPU = 0 ms; tempo decorrido =
11 ms.
•
TotalSubtreeCost: 0,0412433
71
Plano de execução:
Figura 8.4 – Plano de execução gerado para o teste 2b
Nos testes acima, foi possível constatar que no item a, o qual se utilizou o comando
NOT IN, gerou um plano de execução com um número maior de operadores com relação ao
item b, apesar de fazer uso de índices para realização da consulta. Devido a isso, a consulta
possui um desempenho menor com relação ao item b, que possui um número menor de
operadores, sendo assim utilizando menos recursos do SQL SERVER.
8.3.3 Teste 3 (Usando ou não índices)
Para realização deste teste, foi criado uma nova tabela na base de dados
AdventureWorks chamada de Curso.Pessoa. Abaixo seguem os passos:
Criação da tabela Curso.Pessoa. Por padrão a PRIMAY KEY é um índice cluster.
CREATE TABLE Curso.Pessoa
( Codigo BIGINT IDENTITY(1,1) NOT NULL PRIMARY KEY,
Nome CHAR(100) NOT NULL,
Idade TINYINT NULL
)
GO
72
Inserção de dados na tabela. O comando CROSS JOIN faz um produto cartesiano na
tabela.
INSERT INTO Curso.Pessoa (Nome, Idade)
SELECT F.Fname + ' ' + L.LName, 0
FROM curso.FirstName AS F
CROSS JOIN Curso.LastName AS L
A consulta abaixo mostra apenas o resultado para os 300 primeiros registros da
tabela.
SELECT TOP 300 * FROM Curso.Pessoa
GO
Essa consulta demonstra informações dos tipos de índices existentes na tabela. Nesse
momento, o resultado trará apenas um índice clustered, que por padrão do SQL SERVER é
criado no momento que se define a primary key.
SELECT * FROM sys.indexes
WHERE Object_ID = object_id('Curso.Pessoa')
Na execução da consulta abaixo, o comando SET STATISTICS IO ON, traz
informações refentes a quantidade de atividade em disco gerada pelas intruções. Porém,
analisando o plano de execução gerado, foi possível observar que o SQL utilizou o índice
clustered. O índice clustered foi utilizado, devido a cláusula WHERE, que especifica a
condição com o Codigo, que é a chave do índice clustered.
SET STATISTICS IO ON
SELECT p.Idade FROM Curso.Pessoa p
WHERE Codigo = 20000
73
Nessa consulta, observa-se que o SQL não utilizou o índice, fazendo apenas um index
scan, isto é, faz uma varredura em toda a tabela, pois a cláusula WHERE especifica como
parâmetro o atributo Nome, que não é uma chave para o índice clustered.
a) Clustered index scan
SELECTt * FROM Curso.Pessoa
WHERE Nome = 'Carolina Silva'
GO
O resultado obtido para essa consulta a) foi:
•
Linhas afetadas: 1;
•
Tempos de execução do SQL SERVER: CPU = 31 ms; tempo decorrido = 31 ms.
•
Tempo de análise e compilação do SQL SERVER: CPU = 0 ms; tempo decorrido = 1
ms.
•
TotalSubtreeCost: 0,7267
Cria-se então um índice nonclustered contendo como chave o atributo Nome, com o
comando abaixo:
CREATE NONCLUSTERED INDEX idx_Nome
ON Curso.Pessoa (Nome)
GO
Em seguida, executa-se novamente a consulta abaixo para verificar o desempenho,
pois agora o SQL fará uso do índice nonclustered, porém como a busca requer todos os
dados da tabela, então o SQL fará uso dos dois tipos de índices disponíveis, pois o
nonclustered apenas, não possui todos os campos solicitados.
b) Nonclustered index seek + Clustered index
SELECT * FROM Curso.Pessoa
WHERE Nome = 'Carolina Silva'
GO
74
Abaixo os resultados obtidos:
•
Linhas afetadas: 1;
•
Tempos de execução do SQL SERVER: CPU = 0 ms; tempo decorrido = 2 ms.
•
Tempo de análise e compilação do SQL SERVER: CPU = 0 ms; tempo decorrido = 0
ms.
•
TotalSubtreeCost: 0,0065704
É possível visualizar, comparando o resultado do campo TotalSubtreeCost sem o
índice e em seguida com o índice, que houve uma melhora grande no desempenho quando
o SQL usa o índice para buscar o resultado desejado.
No teste abaixo, observa-se que o SQL fez uso apenas do índice nonclustered, pois
na SELECT foi solicitado os campos Codigo e Nome, campos estes existentes no índice
nonclustered.
c) Nonclustered Index seek
SELECT Codigo, Nome
FROM Curso.Pessoa
WHERE Nome LIKE 'Luciano%'
Resultados Obtidos:
•
Linhas afetadas: 211;
•
Tempos de execução do SQL SERVER: CPU = 0 ms; tempo decorrido = 77 ms.
•
Tempo de análise e compilação do SQL SERVER: CPU = 0 ms; tempo decorrido = 0
ms.
•
TotalSubtreeCost: 0,0057454
75
9.
ANÁLISE DOS RESULTADOS
Diante dos testes realizados, foi possível notar casos onde o desempenho não fez
diferença, e também casos em que o desempenho teve uma melhora relevante. No Teste 1,
notou-se que operações com os comandos EXISTS e INNER JOIN produziram o mesmo
resultado final. Desta maneira, não existe diferença no custo total dessas operações,
podendo usar um ou outro que a perfomance será a mesma.
Entretanto, no Teste 2, comprovou-se que operações com expressões negativas como
o NOT IN, devem ser transformadas em expressões afirmativas, pois existe uma diferença
significativa no desempenho delas. Portanto, sempre que possível, antes de executar essas
operações, é válido transformá-las em expressões afirmativas, para que não ocorra
sobrecarga.
Tabela 9.1 – Resultados obtidos através dos Testes 1 e 2.
Tempo execução no
SQL (ms)
CPU Tempo decorrido
Teste 1a Expressão
EXISTS
Teste 1b Expressão
INNER JOIN
Teste 2a Expressão
NOT IN
Teste 2b Transforman
do a
expressão
NOT em
afirmativa
Tempo análise e
compilação (ms)
Tempo decorrido
CPU
TotalSubtreeCost
46
148
0
0
0,384156
47
115
0
0
0,384156
0
0
7
7
0,0927731
0
0
0
11
0,0412433
No Teste 3, que analisa o uso ou não de índices, demonstrado na tabela abaixo, foi
possível visualizar que quando o SQL faz o uso de índices, o desempenho torna-se melhor,
com um custo total menor. É importante também fazer uma análise das consultas que são
executadas com mais freqüência, para que desta maneira seja possível criar e projetar
76
índices apropriados, para que assim a performance seja a melhor possível através da
otimização. É importante ressaltar, que mesmo tendo índices disponíveis, às vezes o SQL
não os utiliza. Isso se deve porque o SQL deduz que é mais fácil realizar uma table scan,
devido ao fato da tabela ser pequena, tendo um custo menor do que ir até o índice, buscar a
chave e devolver a consulta através dele. Abaixo segue a tabela com o resultado do Teste
3:
Tabela 9.2 – Resultados obtidos através do Teste 3.
Tempo execução no
Tempo análise e
SQL (ms)
compilação (ms)
CPU Tempo decorrido CPU Tempo decorrido
Teste 3a Clustered
index scan
Teste 3b Nonclustered
index seek +
Clustered
index
Teste 3c Nonclustered
Index seek
TotalSubtreeCost
31
31
0
1
0,7267
0
2
0
0
0,0065704
0
77
0
0
0,0057454
77
10. CONSIDERAÇÕES FINAIS
É de grande importância que desde o projeto inicial (modelagem do banco de dados),
o processo de otimização e tuning de banco de dados seja algo que se tenha certos
cuidados, devendo sempre haver um acompanhamento constante na manutenção.
Diante disso, os ajustes no banco de dados devem ser feitos de maneira adequada,
para que se possam perceber quaisquer modificações, evitando-se assim que ocorram
conseqüências que possam prejudicar a integridade do banco de dados.
É importante lembrar, que os fatores ligados ao baixo desempenho são muitos,
podendo ser desde fatos relacionados ao hardware bem como aspectos da aplicação,
estrutura e até mesmo ao software (SGBD).
Sendo assim, o estudo de caso pode ajudar e comprovar que pequenos ajustes
acarretam em grandes saltos no desempenho, porém deve-se ter cautela de modo a não
prejudicar outros aspectos do SGBD, por exemplo, fazendo uso de índices em demasia.
Enfim, é de extrema importância que os desenvolvedores tenham conhecimento
específico na estruturação das consultas, pois é a partir delas que o plano de execução será
gerado pelo otimizador de consultas, e, uma consulta mal estruturada gera um plano de
execução deficiente, acarretando em baixo desempenho, sobrecarga e nas consultas,
causando e sobrecarga de recursos.
78
REFERÊNCIAS BIBLIOGRÁFICAS
AMORIM, Fabianno N. SQL – Query Optimizer – Updates e NonClustered Index.
Disponível em:
<http://fabianosqlserver.spaces.live.com/blog/cns!52EFF7477E74CAA6!1625.entry?sa=3936
35256>. Acesso em: 19 ago. 2010.
_______. 10 pontos que devem ser observados quanto a performance de uma
consulta Parte 1. Disponível em:
<http://fabianosqlserver.spaces.live.com/blog/cns!52EFF7477E74CAA6!490.entry>. Acesso
em: 19 ago. 2010.
_______. 10 pontos que devem ser observados quanto a performance de uma
consulta Parte 2. Disponível em:
<http://fabianosqlserver.spaces.live.com/blog/cns!52EFF7477E74CAA6!491.entry>. Acesso
em: 19 ago. 2010.
_______. O que é melhor? Um Index Seek ou Clustered Index Scan?. Disponível em:
<http://fabianosqlserver.spaces.live.com/blog/cns!52EFF7477E74CAA6!693.entry>. Acesso
em: 21 ago. 2010.
_______. Operador do Dia – Bookmark Lookup. Disponível em:
<http://fabianosqlserver.spaces.live.com/blog/cns!52EFF7477E74CAA6!1160.entry>. Acesso
em: 21 ago. 2010.
_______. SQL – Query Optimizer – Updates e NonClustered Index. Disponível em:
<http://fabianosqlserver.spaces.live.com/blog/cns!52EFF7477E74CAA6!1625.entry>. Acesso
em: 26 ago. 2010.
CARNEIRO, Alessandro P.; MOREIRA, Julinao L.; FREITAS, Andre L.C. Tuning –
Técnicas de Otimização de Banco de Dados – Um Estudo Comparativo: Mysql e
Postgresql. Disponível em: <http://www.projetos.unijui.edu.br/erbd2009/arquivo/51990.pdf>.
Acesso em: 03 mar. 2010.
79
CINTRA, João Paulo S.; CAPELLO, Renato. Otimização de Consultas de Relacionais.
Disponível em: <http://www.ic.unicamp.br/~geovane/mo410-091/Ch15-Resumo.pdf>. Acesso
em: 08 mar. 2010.
COUTO, Eder. Aumentando a performance da aplicação através da otimização de SQL.
Disponível em:
<http://imasters.uol.com.br/artigo/4055/bancodedados/aumentando_a_performance_da_apli
cacao_atraves_da_otimizacao_de_SQL/>. Acesso em: 08 mar. 2010.
ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de Banco de Dados. 4. ed. São
Paulo: Pearson, 2005. 724 p.
FRITCHEY, Grant. Dissecting SQL SERVER Execution Plans. Disponível em: <http://cid52eff7477e74caa6.skydrive.live.com/self.aspx/Publica/Art%20of%20High%20Performance%
20SQL%20Code%20by%20Grant%20Fritchey.pdf#resId/52EFF7477E74CAA6!781>.
Acesso em: 09 set. 2010.
MACHADO, Claudia. Tuning de Banco de Dados. Disponível em:
<http://linhaseletrasweb.blogspot.com/2010/03/tuning-de-bancos-de-dados.html>. Acesso
em: 01 jun. 2010.
MOREIRA, Luciano C. Porque o SQL SERVER não usa o meu índice?. Disponível em:
<http://blogs.msdn.com/b/luti/archive/2008/02/15/porque-o-sql-server-n-o-usa-o-meundice.aspx>. Acesso em: 18 ago. 2010.
MULLINS, Craig S. SQL Performance Tuning Basics. Disponível em:
<http://www.craigsmullins.com/zjdp_017.htm> Acesso em: 02 jun. 2010.
PICINI, Rodrigo; SCHIMIGUEL, Juliano. Desempenho de Banco de Dados: a Técnica de
Otimização com Tuning. Disponível em: <http://www.devmedia.com.br/post-11323Metodologia-Tuning.html>. Acesso em: 02 jun. 2010.
PILECKI, Maciej. Como otimizar o desempenho da consulta do SQL SERVER.
Disponível em: <http://technet.microsoft.com/pt-br/magazine/2007.11.sqlquery.aspx>.
Acesso em: 07 ago. 2010.
80
SILBERSCHATZ, Abraham, KORTH, Henry F., SUDARSHAN S. Sistema de bancos de
dados. 3. Ed. São Paulo: Makron, 2006. 781 p.
SOARES, Leonardo F. Boas Práticas para Otimização de Consultas a Bancos de Dados
usando SQL SERVER 2005. Disponível em:
<http://www.pdfqueen.com/html/aHR0cDovL3d3dy5zaWdhY29uc3VsdC5jb20uYnIvbWFudW
Fpcy9maWxlcy9NaWNyb3NpZ2FfRVJQL3NxbC9hcnRpZ29zcWwucGRm>. Acesso em: 08
mar. 2010.
SQL. Disponível em: <http://www.dca.fee.unicamp.br/cursos/PooJava/javadb/sql.html>
Acesso em: 02 jun. 2010.
Um Estudo sobre Técnicas de Otimização de Banco de Dados Tuning. Disponível em:
<http://www.oficinadanet.com.br/apostilas/detalhe/28/otimizacao_de_consultas_sql> Acesso
em: 16 mai. 2010.
VIEIRA, Eduardo B.; TAKANO, Leonardo M.; FORNACIARI, Lucas C. Metodologia para
Ajuste de Performance . Disponível em:
<http://www.shammas.eng.br/acad/sitesalunos0606/rpt/tun_met.html>. Acesso em: 01 jun.