Microsoft SQL Server 2005

Transcrição

1 Sistemas de Bases de Dados Faculdade de Ciências e Tecnologia Mestrado em Engenharia Informática Análise de um Sistema de Gestão de Bases de Dados: Microsoft SQL Server 2005 Trabalho realizado por: Arlindo Lima Nº Hugo Aguiar Nº Tiago Melo Nº de Dezembro de 2009

2 Contents 1 Introdução Introdução histórica Notas sobre instalação do sistema 2 2 Cobertura do SQL DDL DML Tipos de Dados 6 3 Armazenamento e file structure O Buffer Pool Acesso às páginas em memória Gestão de páginas na cache de dados Arquitectura NUMA Read-ahead Sistema de ficheiros Páginas e Extents Organização dos ficheiros Mecanismo de partições 13 4 Indexação e Hashing Estrutura B-tree Tipos de Índices Índices clustered Índices non-clustered Implementação de Índices Índices com colunas incluídas Indexação de views Indexação full-text Indexação XML Criação de Índices Argumentos do comando CREATE INDEX Opções do comando CREATE INDEX Indexação e Hashing - Oracle 10g vs MS SQL Processamento e Optimização de Queries Algoritmos para Junções Nested Loop Merge 31 i

3 ii Hash Grace Hash Join Remoto Escolha de Índices e avaliação de sub consultas Optimização de queries optimizadores baseados em sintaxe optimizadores baseados em custo fases de optimização Paralelismo Estatisticas Pistas em consultas Pistas do tipo Join Pistas do tipo Tabela Pistas do tipo Query 39 6 Gestão de transacções e controlo de concorrência Tipos de transacções Autocommit Transacções explícitas Transacções implícitas Batch-scoped Locks Níveis de granularidade Modos de lock Níveis de isolamento Locking Hints Deadlocks Transacções de longa duração 50 7 Suporte para bases de dados distribuídas Replicação Funcionamento Tipos Agentes Mirroring Log Shipping Transacções Distribuídas Acesso a outras Bases de Dados Federação 57 8 Outras características do sistema estudado 59

4 List of Figures 4.1 Exemplo da estrututa B-tree Índice com duas chaves Índice clustered Índice non clustered Sintaxe do comando CREATE INDEX Plano com um nested loop Plano com um merge join Plano com um hash join nested transaction Granularidade dos Locks Replicação Mirroring log shiping 56 iii

5

6 1 Introdução A sociedade moderna encontra-se inundada de dados - dados científicos, dados clínicos, dados demográficos, dados financeiros, entre outros. Estes dados precisam de ser armazenados, acedidos e alterados. Estas são as funções das bases de dados. Hoje em dia, poucas são as organizações que conseguem funcionar sem esta tecnologia. Para ajudar na manutenção das bases de dados, foram criados os Sistemas de Gestão de Bases de Dados (SGBD), que são um conjunto de programas que controlam a organização, armazenamento e acesso aos dados. Existem vários SGBD, sendo o sistema Oracle, considerado o melhor, pela indústria. No entanto, o SGBD da Microsoft, SQL Server, tem vindo a ganhar terreno, principalmente por oferecer uma elevada facilidade de instalação, para um SGBD do seu calibre. Neste relatório, iremos apresentar algumas características do Microsoft SQL Server, que mostram que este SGBD consegue concorrer com o seu rival comercial Oracle. 1.1 Introdução histórica Em 1987, a Microsoft e a Sybase aliaram-se para desenvolver um sistema de gestão de base de dados, baseado no software Sybase DataServer (ainda por ser lançado). A Sybase ficaria com os direitos para distribuir a versão para Unix e VMS (esta versão acabaria por se chamar Sybase SQL Server) e a Microsoft iria distribuir a versão para OS/2. Assim, em 1989, foi lançada a primeira versão do Microsoft SQL Server, SQL Server 1.0. Em 1990 foi lançada a versão para Windows: SQL Server 1.1. Na altura em que o Windows NT foi lançado, a popularidade do OS/2 tinha caído bastante. Além disso o Windows NT já suportava novas arquitecturas que o OS/2 não suportava. Isto fez 1

7 1. INTRODUÇÃO 1.2. Notas sobre instalação do sistema com que a Microsoft quisesse passar a desenvolver o SQL Server exclusivamente para o Windows, usando as capacidades do seu sistema operativo. A Sybase, no entanto, queria continuar a desenvolver software multi-plataforma, pelo que as duas empresas se separaram. Assim, em 1995, a Microsoft lançou o SQL Server 6.0 que, pela primeira vez, estava completamente integrado com o Windows NT. Na tentativa de tornara o seu SGBD cada vez mais intuitivo, foi lançado em 1998 o SQL Server 7.0, o primeiro SGBD com uma verdadeira interface gráfica. A marcha não ficou por aqui. Em 2000 foi lançado o SQL Server 2000 que dava continuidade a um produto que por esta altura já era bastante reconhecido no mercado empresarial (em 2003 seria lançada a versão 64 bits - que também se tornaria na primeira versão deste SGBD a fazer uso desta arquitectura). Em 2005 foi lançado o SQL Server 2005 (a versão estudada neste relatório) e, recentemente, em Agosto de 2008, foi lançada a versão Para a realização deste trabalho foram consultados os manuais [10], [6], [5], [4], [8], [7], [3], [2], [9] e o site [1]. 1.2 Notas sobre instalação do sistema Antes de instalar: 1. Desinstale a Framework.NET 1.2 (as versões 1.0 e 1.1 não têm de ser obrigatoriamente desinstaladas). A seguir instale a Framework.NET Instale o SQL Server 2005, seguindo os vários passos: 3. Depois de satisfeitos os pré-requisitos, siga com a instalação clicando em "install". 4. Escolha os componentes a instalar (todos). 5. Em seguida, escolha o local de instalação dos componentes. 6. Clique "seguinte" nos restantes ecrãs e a instalação será iniciada. 2

8 2 Cobertura do SQL 2.1 DDL DDL é um subconjunto de operações do SQL que contem os comandos para definir dados. Os principais comandos deste conjunto são o CREATE, ALTER e DROP. O T-SQL tem suporte para criação, alteração e destruição de Base de Dados, Funções, Índices, Procedimentos, Tabelas, Triggers, Utilizadores e Views. De entre estes o mais usado é o CREATE, nomeadamente para criação de tabelas, que iremos detalhar de seguida. Na sua forma mais simples, CREATE TABLE table_name (column_name1 data_type, column_name2 data_type,...), é criada uma tabela onde só estão definidos o seu nome, o nome das colunas e o tipo de dados que cada coluna irá suportar, sem estar limitado por quais queres restrições. Para o caso de se desejar ter uma base de dados mais poderosa e coesa o T-SQL disponibiliza, entre muitos outros, os seguintes parâmetros e restrições: Database_Name: onde podemos indicar em que base de dados será criada a tabela, essa cláusula remove a necessidade de usar o USE. Owner: poderá especificar outro dono para a tabela, caso não seja especificado o utilizador actual fica como dono. Identity: especifica que coluna vai servir como identificador da tabela. Seed: se quiser que o ID da tabela não comece a 1, poderá indicar o valor neste argumento. 3

9 2. COBERTURA DO SQL 2.1. DDL Increment: poderá indicar que incremento usar em cada novo tuplo, por omissão este valor é 1. Not for Replication: Se esta condição estiver activa, o sistema de base de dados não irá tentar impor novos valores de ID aos dados inseridos por um processo replicante, mantendo o ID original. Os dados inseridos por outros processos não serão afectados. Null: que indica se o valor de uma coluna poderá ser ou não Null. Primary Key: indica se uma coluna ou conjunto de colunas formam um valor identificativo de uma tabela, implica que os valores, ou pares de valores, sejam únicos. Unique: obriga que os valores de uma coluna sejam únicos. ON DELETE [CASCADE NO ACTION]: indica que acção tomar quando um tuplo, referenciado através de uma Foreign Key, é removido. Por omissão esta opção encontrase como NO ACTION, tendo que ser alterado para CASCADE para o caso de se querer remover todos os outros tuplos. Estes parâmetros também estão disponíveis para o ALTER. Para destruir estruturas, é usado o comando DROP com a seguinte sintaxe básica: DROP type name. A quando da remoção de uma tabela todas os tuplos, índices e triggers específicos dessa tabela irão ser removidos, mas Views e Procedimentos que têm referencias para a tabela terão de ser removidos manualmente usando o DROP View/Procedure. Como indicado anteriormente os tuplos de outras tabelas que tem como Foreign Key alguma coluna desta tabela, só irão ser removidos caso esteja activa a opção ON DELETE CASCADE. 4

10 2. COBERTURA DO SQL 2.2. DML 2.2 DML DML é o conjunto das operações que manipulam os dados. Quer isso dizer que serão usadas para inserir, remover e editar dados, nomeadamente com os comandos INSERT, UPDATE e DELETE. Também está incluido nesse conjunto o comando SELECT, para acesso aos dados, que será a longe prazo o mais usado. Para poder trabalhar com os dados temos de primeiro inseri-los. O INSERT do T-SQL é muito versátil deixando, entre outros, inserir dados Null, tuplos com menos dados que colunas, por diferentes ordens, através de tabelas temporárias e views e até usar o SELECT e EXECUTE dentro do INSERT. Podemos posteriormente alterar estes dados com o UPDATE. Este suporta copiar dados de outras tabelas, alterar só um valor com o SET e indicando o nome da coluna, seleccionar que tuplos actualizar usando o WHERE e podemos até inferir diferentes valores usando a cláusula CASE. A forma mais comum de remover dados é indicando a tabela e que condições o tuplo precisa de ter, mas o T-SQL também tem suporte para remover sem indicar condições, remover vários tuplos, remover o tuplo onde se encontra um cursor e até remover tuplos seleccionados com uma sub consulta. Caso não deseje editar os dados o T-SQL disponibiliza o comando SELECT, com suporte para a estrutura do SELECT do standard SQL, para aceder aos dados. Dados esses que podem ser Views, cursores, tabelas, subconjunto de tabelas e mesmo resultados de outro SELECT. Podemos usar o SELECT desde a sua forma mais básica, SELECT Hello World, que simplesmente irá devolver Hello World ou SELECT (select_list) INTO (new_table) FROM (table source) WHERE (search_condition) GROUP BY (group_by_expression) HAVING (search_condition) ORDER BY (order_expression) [ASC / DESC], onde já se encontram algumas das muitas clausulas para o qual há suporte. Iremos agora explicar algumas das cláusulas: AS: permite renomear as colunas. INTO: guarda os resultados noutra tabela. FROM: define que tabela irá ser interrogada. WHERE/HAVING: clausula condicional, que restringe os resultados. GROUP BY: permite agrupar os resultados indicando as colunas. ODER BY [ASC DESC]: ordena os resultados pelos valores da coluna indicada. COMPUTE: permite fazer cálculos como a média, o Max, mínimo e somatório. FOR XML: indica que o resultado da query deve ter o formato XML. JOINS: é o produto entre duas ou mais resultados. Tem suporte para INNER e [LEFT RIGHT TOTAL] OUTTER JOIN. UNION: une dois resultados. 5

11 2. COBERTURA DO SQL 2.3. Tipos de Dados 2.3 Tipos de Dados O T-SQL tem suporte para os seguintes tipos de dados: Valores numéricos inteiros: bigint int smallint tinyint bit decimal numeric money smallmoney Valores numéricos aproximados: float real Data e hora: datetime smalldatetiem Strings: char varchar text nchar nvarchar ntext 6

12 2. COBERTURA DO SQL 2.3. Tipos de Dados Strings binárias: binary varbinary image Outros: cursor sql_variant table timestamp uniqueidentifier xml 7

13

14 3 Armazenamento e file structure 3.1 O Buffer Pool O principal componente de memória do SQL Server 2005 é o buffer pool. Toda a memória que não esteja a ser usada por outros componentes de memória, permanece no buffer pool, onde é usada como cache de dados para páginas lidas dos ficheiros da base de dados (em disco). O gestor de buffer (buffer manager) controla as funções de I/O do disco, com o objectivo de carregar as páginas para essa cache de dados (de modo a que essa informação possa ser acedida por todos os utilizadores). Quando outros componentes necessitam de memória, podem pedir um buffer (página em memória do mesmo tamanho que uma página de dados/índices) do buffer pool. Após estes pedidos, os buffers são, normalmente, transferidos para outros tipos de caches (como, por exemplo, a cache responsável por guardar as queries e procedimentos SQL executados recentemente - procedure cache). Ocasionalmente, o SQL Server precisa de blocos de memória contíguos superiores ao tamanho máximo das páginas usadas pelo buffer pool (8 KB). Quando assim é, é reservada memória fora do espaço de endereçamento deste. No entanto, o uso de grandes blocos de memória é minimizado, de modo a que chamadas directas ao sistema operativo representem uma fracção mínima do uso de memória. O SQL Server, ao arrancar, calcula o tamanho do espaço de endereçamento virtual (virtual address space - VAS) do seu processo, que depende da arquitectura (x86 ou x64) e do sistema operativo. De notar que os sistemas x86 apenas podem endereçar (directamente) 4 GB de memória. No entanto, o SQL Server pode fazer uso da API (do Windows) Address Windowing Extensions (AWE) que, actuando como uma terceira área de memória, permite ultrapassar esta 9

15 3. ARMAZENAMENTO E FILE STRUCTURE 3.2. Acesso às páginas em memória restrição. Nos sistemas x64 esta restrição não existe, pelo que é ignorada a configuração para esta API. Além do tamanho do VAS, é calculado o número de páginas que se espera ser possível alocar (este valor é designado por Target Memory). É possível ver estas informações, bem como outras relevantes ao buffer pool, na Dynamic Management View (DMV) chamada sys.dm_os_sys_info. Colunas interessantes incluem: physical_memory_in_bytes - memória física disponível. virtual_memory_in_bytes - memória virtual disponível. bpool_commited - número de páginas no buffer pool (não inclui memória reservada). bpool_commit_target - Target Memory. 3.2 Acesso às páginas em memória O SQL Server tenta manter o acesso às páginas, na cache de dados, rápido (não é eficiente pesquisar em toda a cache) pelo que as páginas são guardadas numa hash table (implementada como uma página que contém um array - que na verdade é uma lista ligada - de apontadores para as páginas na cache), em que a combinação dos identificadores da base de dados (serve para identificar a que base de dados o ficheiro pertence), do ficheiro e da página, são os argumentos de entrada da função de hash. 3.3 Gestão de páginas na cache de dados No SQL Server, o mesmo mecanismo é responsável por escrever as alterações das páginas em disco e por marcar como livre a memória ocupada por páginas que não sejam referenciadas há algum tempo (sendo mantida uma lista ligada com os endereços das páginas "livres"). Cada buffer na cache de dados tem um cabeçalho que contém informação sobre as duas últimas vezes que cada página foi referenciada, além de outras informações sobre o estado dessas mesmas páginas, incluindo o facto de uma página estar ou não dirty (o seu conteúdo ter alterado desde que foi lida de disco). Esta informação é usada na implementação da política de substituição de páginas, que usa o algoritmo LRU-K (Least Recently Used-K). Este algoritmo baseia-se na filosofia do algoritmo LRU, mas mantém-se a par das últimas K vezes que a página foi referenciada (sendo usado o valor 2 para K, na implementação do SQL Server). Assim, buffers que contenham páginas consideradas mais importantes, mantêm-se no buffer pool activo, enquanto buffers com páginas menos referenciadas acabam por regressar à lista de buffers livres. O trabalho de percorrer o buffer, escrevendo páginas "dirty" em disco e adicionando buffers à lista de buffers livres é feito por um processo assíncrono, denominado lazywriter. Este também é responsável por diminuir ou aumentar a cache de dados, de modo a manter a memória física livre do sistema operativo em cerca de 5MB, de modo a evitar paginação. Existe outro processo também responsável por percorrer a cache de buffer, periodicamente, 10

16 3. ARMAZENAMENTO E FILE STRUCTURE 3.4. Arquitectura NUMA e escrever em disco páginas "dirty": checkpoint. A diferença entre os processos lazywriter e checkpoint é o facto de este último nunca colocar buffers na lista livre. O único objectivo do checkpoint é assegurar que páginas alteradas há mais de x tempo são, efectivamente, escritas em disco, de modo a minimizar o tempo que o SQL Server necessitaria para recuperar de uma falha. Este processo também corre automaticamente, mas também pode ser accionado manualmente através do comando CHECKPOINT. Uma característica que existia nas versões do SQL Server anteriores à 2005 era a possibilidade de marcar tabelas, de modo a que as suas páginas fossem mantidas em memória, indefinidamente. Este processo, chamado pinning de uma tabela, podia ser accionado usando a opção pintable do procedimento sp_tableoption. Este comando ainda existe no SQL Server 2005, mas não tem efeito (de modo a se manter retro-compatível). 3.4 Arquitectura NUMA O SQL Server 2005 é compatível com a arquitectura Non-Uniform Memory Access (NUMA). A maior vantagem desta arquitectura é o facto de ser uma solução escalável para o aumento do número de CPUs nos computadores. Na arquitectura NUMA os CPUs estão agrupados em pequenos conjuntos, designados por nós NUMA, sendo cada nó servido por um bus de sistema, além de ter a sua própria memória interna. Cada CPU pode aceder à memória de outros nós, de forma coerente, embora seja mais rápido aceder à memória local do seu nó. Assim, ao contrário da arquitectura Symmetric Multiprocessing (SMP), onde todo o acesso a memória é feito pelo mesmo bus partilhado (o que até funciona bem para um pequeno numero de CPUs), NUMA alivia este "bottleneck" limitando o número de CPUs num mesmo bus. O SQL Server tem ainda a vantagem de permitir subdividir um (ou mais) nós NUMA físicos em nós mais pequenos, denominados software NUMA (soft-numa). Tipicamente, usa-se soft- NUMA quando se está na presença de vários CPUs, mas não de hardware NUMA. O uso de soft-numa permite reduzir o I/O e "bottlenecks" provocados pelo processo lazywriter. Por exemplo, num computador com oito CPUs e sem hardware NUMA, temos apenas uma thread para I/O e um lazywriter (o que pode causar entupimentos). Configurando quatro nós soft-numa, passamos a ter quatro threads para I/O e quatro lazywriters, o que ajuda na performance. 3.5 Read-ahead O SQL Server suporta um mecanismo chamado "read-ahead" que antecipa as necessidades de páginas de dados e índices, carregando, para o buffer pool, estas páginas antes delas serem pedidas. Esta optimização aumenta bastante a eficiência do processamento de dados. Este mecanismo é gerido internamente, sem necessidade de ser configurado. 11

17 3. ARMAZENAMENTO E FILE STRUCTURE 3.6. Sistema de ficheiros 3.6 Sistema de ficheiros Uma base de dados no SQL Server 2005 pode ser vista como uma colecção de ficheiros que contêm dados e meta-dados, correspondendo cada ficheiro da base de dados a um ficheiro do Windows (no entanto, cada ficheiro tem um nome lógico e um nome físico). Esta dependência, embora diminua a portabilidade deste SGBD, tem a vantagem de permitir fazer uso das ferramentas disponibilizadas por esses sistemas de ficheiros (tal como encriptação e definição de quotas/permissões) de modo totalmente transparente para o SQL Server. Existem os seguintes três tipos de ficheiros no SQL Server: Ficheiros de dados primários - contêm informação sobre todos os ficheiros na base de dados, além de guardarem dados. Ficheiros de dados secundários - guardam dados dos utilizadores (índices, vistas, tabelas e procedimentos). Têm a função de replicar esta informação por vários discos. Ficheiros Log - contêm informação necessária para a recuperação de todas as transacções efectuadas. Os ficheiros de dados podem ser atribuídos a um filegroup, uma característica que permite agrupar ficheiros. Isto pode ser útil para colocar dados (e índices) numa unidade de disco especifica ou para a criação de um regime de backup que apenas salvaguarda os ficheiros de determinados filegroups. Os ficheiros log, no entanto, não podem ser atribuídos a um filegroup porque são guardados separadamente dos ficheiros de dados. 3.7 Páginas e Extents A um nível de abstracção superior ao do sistema de ficheiros, o armazenamento da base de dados no SQL Server 2005 é feito em páginas e extents. O objecto de armazenamento básico é a página (que, tal com já foi dito, tem 8KB), cuja estrutura é semelhante à de outros objectos do sistema operativo Windows. Primeiro, a página é identificada por um identificador único. Em seguida, contém um cabeçalho (header), de 96 bytes, com informação pertinente sobre a página incluindo o seu tipo, espaço livre, etc. Seguemse as linhas com os dados (podendo, no máximo, uma linha ocupar bytes), que crescem do início da página para o final. No fim da página, encontra-se o slot array com apontadores para cada linha de dados (cresce do final da página para o início). O tamanho das linhas (de dados) de uma página não se pode "exceder" para outras páginas, pelo que, para armazenar tipos de dados que ocupem mais espaço (como imagens, texto muito longo e XML) são combinadas mais páginas. Os extents são usados para alocar espaço para tabelas e índices e são a unidade básica de gestão de memória. Cada extent contém até oito páginas contíguas, fazendo com que o seu tamanho máximo seja de 64KB. 12

18 3. ARMAZENAMENTO E FILE STRUCTURE 3.8. Organização dos ficheiros 3.8 Organização dos ficheiros Existem três modos de organizar as páginas no Sql Server: heap (modo por defeito) - as páginas não estão ordenadas. Assim, as linhas (de dados) são inseridas em qualquer espaço. clustered index - as páginas são ligadas através de uma lista duplamente ligada, usando o índice (que deve ser único) como chave. O índice é guardado numa árvore B+ ordenada. non-clustered index - semelhante ao modo clustered index, mas os índices na árvore B+ não se encontram em nenhuma ordem especial (já não existindo a restrição do índice único). Outros modos de organização (como multitable clustering e hash) não são suportados. 3.9 Mecanismo de partições No SQL Server, a partição de dados é um mecanismo apenas disponível na versão Enterprise Edition. Um objecto encontra-se particionado quando se encontra dividido (internamente) em unidades físicas (separadas) que podem ser armazenadas em diferentes localizações, no entanto, as partições são invisíveis para os utilizadores e programadores de T-SQL. Podem se usar partições para tornar mais eficiente (ou menos pesado) a utilização de objectos grandes (tabelas de 2GB, por exemplo) ou quando alguns tuplos passaram a ser acedidos apenas para leitura, separando-se estes dos tuplos actualizáveis, etc. No SQL Server, criar partições é um processo de três passos. Passo 1 - Criação da função de partição No primeiro passo, cria-se uma função de partição (ou seja, é definido o critério de divisão dos dados) com o comando CREATE PARTITION FUNCTION, cuja sintaxe é: CREATE PARTITION FUNCTION partition_function_name ( input_parameter_type) AS RANGE [ LEFT RIGHT ] FOR VALUES ( [ boundary_value [,..., n ] ] ) [;] Os parâmetros deste comando são: partition_function_name - identificador SQL válido input_parameter_type - tipo de dados da coluna de partição (pode ser qualquer um excepto text, ntext, image, xml, timestamp, varchar(max), nvarchar(max), varbinary(max), alias e tipos CLR (Common Language Runtime) definidos pelo utilizador). boundary_value - lista de limites que define as partições LEFT ou RIGHT - define a que lado do valor limite a partição pertence. Passo 2 - Criação do esquema de partição 13

19 3. ARMAZENAMENTO E FILE STRUCTURE 3.9. Mecanismo de partições Neste passo cria-se um esquema de partição. Este esquema define como as partições serão fisicamente definidas na base de dados (se ficarão em filegroups diferentes ou não). O comando para este passo é CREATE PARTITION SCHEME, cuja sintaxe é: CREATE PARTITION SCHEME partition_scheme_name AS PARTITION partition_function_name [ ALL ] TO ( file_group_name [ PRIMARY ] [,...n ] ) [;] Os parâmetros deste comando são: partition_scheme_name - identificador SQL válido partition_function_name - nome da função de partição à qual associar este esquema de partição. file_group_name - lista dos filegroups aos quais este esquema deverá ser associado, ou PRIMARY para associar todas as partições ao filegroup primário (o filegroup por omissão do SQL Server). A palavra reservada ALL especifica que todas as partições deverão ir para esse filegroup. Passo 3 - Criação da tabela/índice Neste último passo, é criada a tabela ou índice que usa o esquema de partição criado. Uma tabela é criada com o comando CREATE TABLE, enquanto uma partição é criada com o comando CREATE INDEX. A sintaxe de CREATE TABLE é: CREATE TABLE... [ ON partition_scheme_name ( partition_column_name ) filegroup "default" ] [ TEXTIMAGE_ON filegroup "default" ] [;] A diferença principal entre a criação de uma tabela particionada e uma tabela não-particionada é a adição de partition_scheme_name (partition_column_name). Isto permite-nos especificar qual a coluna em que a partição ocorrerá. A sintaxe de CREATE INDEX é: CREATE... INDEX... [ ON partition_scheme_name ( column_name ) filegroup_name default ] [;] Tal como para criar uma tabela, a diferença principal entre a criação de um índice tradicional e a criação de um índice particionado é a adição de ON partition_scheme_name ( column_name ). 14

20 3. ARMAZENAMENTO E FILE STRUCTURE 3.9. Mecanismo de partições O SQL Server 2005 disponibiliza ainda comandos para alterar, arquivar e eliminar partições. Existe também uma DMV para recolher informação sobre as partições, designada sys.dm_db_partition_stats. 15

21

22 4 Indexação e Hashing O SQL Server 2005 processa o acesso a dados de duas formas distintas. A primeira é através de um table scan onde todas as páginas, começando no inicio da tabela, são varridas extraindo assim a informação definida na query. A segunda é através de índices. Os índices são estruturas que foram desenhadas para aumentar a velocidade de acesso ao repositório de dados de um SGBD. Se simplificarmos a utilidade destes índices percebemos que funcionam como o índice de um livro - ao usarmos índices podemos encontrar rapidamente dados específicos sem termos que ler todo o conteúdo de uma tabela. Os índices não são estruturas obrigatórias, afectam a performance das queries mas não afectam a sua funcionalidade. No entanto, esta diferença de performance pode ter um impacto muito grande no sistema. Esta performance é aumentada reduzindo o trabalho de pesquisa às queries. Sem índices, é necessário ler todos os dados de uma tabela. De facto o uso dos índices está directamente ligado aos movimentos de I/O. Quando é executado um table scan, são gerados milhares de I/O, estas operações têm um custo elevado. Com o uso de índices são necessárias menos leituras e consequentemente a performance aumenta e a utilização de recursos diminui. Nesta secção explica-se como funcionam e como podem ajudar a melhorar a performance de um sistema. 4.1 Estrutura B-tree A estrutura de indexação é implementada por árvores B+. Uma árvore é constituída por uma raiz (root), ramos (branch nodes) e folhas(leaf nodes). A árvore começa com a primeira página do índice (nó raiz). Esta raiz contem a gama das chaves de pesquisa e os ponteiros para 17

23 4. INDEXAÇÃO E HASHING 4.1. Estrutura B-tree outras páginas do índice. Os nós entre o nó raiz e os nós folha também contêm as chaves e os ponteiros para nós inferiores e eventualmente nós folha. Os nós folha têm apontadores para os dados na tabela ou guardam eles próprios os dados, dependendo do tipo de índice escolhido (iremos falar sobre os tipos de índice posteriormente). É possivel navegar através dos ramos da árvore até que seja alcançado um nó folha. Figure 4.1: Exemplo da estrututa B-tree Como podemos ver na figura 4.1 cada nó da árvore está ordenado pela chave de pesquisa. Os apontadores de cada entrada guiam a pesquisa para uma sub-árvore que contém entradas consideradas menores que a entrada actual. O nó à direita do nó actual contém uma sub-árvore em que todos os nós são considerados maiores que qualquer nó da sub-árvore do nó actual. Desta forma garante-se a ordenação da árvore. Mantendo a árvore equilibrada e ordenada, permite-se um acesso aos nós folha em poucas iterações. Para manter este equilibro é necessário assegurar que cada nó ramo mantenha um número de sub-árvores que varie entre n e n/2, onde n representa o número de níveis da árvore. A ordenação depende da forma como é criado o índice. Como o índice já está ordenado, às vezes o sistema não precisa de ordenar os dados quando é usado um ORDER BY (assumindo que o índice é usado e que a ordem pretendida é igual à do índice). Com o crescimento da base de dados, os nós da árvore do índice têm tendência a encher. Quando há uma inserção sobre um nó cheio é necessário parti-lo em duas partes - este processo denomina-se page split e implica reorganizar a estrutura para atingir um novo estado de equilíbrio, este processo tem um custo (overhead) indesejável. No entanto é possivel configurar o parâmetro fill factor que indica qual o espaço livre que deve ser deixado quando um nó é criado. Iremos falar deste e de outros parâmetros mais à frente. No SQL Server as árvores B+ são 18

24 4. INDEXAÇÃO E HASHING 4.1. Estrutura B-tree utilizadas para a indexação e para a organização de ficheiros. Exemplo 1 prático sobre índices Para tirarmos vantagem do uso dos índices é necessário inclui-los na clausula WHERE. Se um índice for criado com as chaves lastname e firstname, os dados são ordenados primeiro por último nome e depois pelo primeiro (figura 4.2). Figure 4.2: Índice com duas chaves 1) O índice é acedido com grande eficiência no seguinte caso: SELECT PhoneNumber FROM mytable WHERE lastname = smith AND firstname = john ; 2) O índice ainda é útil no próximo exemplo: SELECT PhoneNumber FROM mytable WHERE lastname = smith ; 3) Neste exemplo o indíce não e utilizado sendo feito um table scan: SELECT PhoneNumber FROM table WHERE firstname = john ; Neste exemplo podemos que o benificio do uso do índice depende da forma como as chaves são usadas. 1 Exemplo adaptado de [10] 19