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 SELECT- FROM-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