Ms SQL Server

Sistemas de Bases de Dados
Faculdade de Cincias e Tecnologia

Mestrado em Engenharia Informtica
Anlise de um Sistema de Gesto de Bases de Dados:
Microsoft SQL Server 2005
Trabalho realizado por:

Arlindo Lima N 26651 Hugo Aguiar N 29672 Tiago Melo N 32629
9 de Dezembro de 2009
Contents
1 Introduo 1.1 Introduo histrica 1.2 Notas sobre instalao do sistema Cobertura do SQL 2.1 DDL 2.2 DML 2.3 Tipos de Dados Armazenamento e le structure 3.1 O Buffer Pool 3.2 Acesso s pginas em memria 3.3 Gesto de pginas na cache de dados 3.4 Arquitectura NUMA 3.5 Read-ahead 3.6 Sistema de cheiros 3.7 Pginas e Extents 3.8 Organizao dos cheiros 3.9 Mecanismo de parties Indexao e Hashing 4.1 Estrutura B-tree 4.2 Tipos de ndices 4.2.1 ndices clustered 4.2.2 ndices non-clustered 4.3 Implementao de ndices 4.3.1 ndices com colunas includas 4.3.2 Indexao de views 4.3.3 Indexao full-text 4.3.4 Indexao XML 4.4 Criao de ndices 4.4.1 Argumentos do comando CREATE INDEX 4.4.2 Opes do comando CREATE INDEX 4.5 Indexao e Hashing - Oracle 10g vs MS SQL 2005 Processamento e Optimizao de Queries 5.1 Algoritmos para Junes 5.1.1 Nested Loop 5.1.2 Merge i 1 1 2 3 3 5 6 9 9 10 10 11 11 12 12 13 13 17 17 20 20 21 23 23 23 23 24 24 25 25 27 29 30 30 31
ii 5.1.3 Hash 5.1.4 Grace Hash 5.1.5 Join Remoto Escolha de ndices e avaliao de sub consultas Optimizao de queries 5.3.1 optimizadores baseados em sintaxe 5.3.2 optimizadores baseados em custo 5.3.3 fases de optimizao Paralelismo Estatisticas Pistas em consultas 5.6.1 Pistas do tipo Join 5.6.2 Pistas do tipo Tabela 5.6.3 Pistas do tipo Query 32 33 33 34 34 34 34 34 35 35 37 37 38 39 41 42 42 42 45 45 46 46 47 49 50 50 50 53 53 54 54 54 55 55 56 56 57 59
5.2 5.3
5.4 5.5 5.6
Gesto de transaces e controlo de concorrncia 6.1 Tipos de transaces 6.1.1 Autocommit 6.1.2 Transaces explcitas 6.1.3 Transaces implcitas 6.1.4 Batch-scoped 6.2 Locks 6.2.1 Nveis de granularidade 6.2.2 Modos de lock 6.2.3 Nveis de isolamento 6.2.4 Locking Hints 6.2.5 Deadlocks 6.3 Transaces de longa durao Suporte para bases de dados distribudas 7.1 Replicao 7.1.1 Funcionamento 7.1.2 Tipos 7.1.3 Agentes 7.2 Mirroring 7.3 Log Shipping 7.4 Transaces Distribudas 7.5 Acesso a outras Bases de Dados 7.6 Federao Outras caractersticas do sistema estudado
List of Figures
4.1 4.2 4.3 4.4 4.5 5.1 5.2 5.3 6.1 6.2 7.1 7.2 7.3 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 Replicao Mirroring log shiping 18 19 20 22 24 31 32 33 44 46 53 55 56
iii
1
Introduo
A sociedade moderna encontra-se inundada de dados - dados cientcos, dados clnicos, dados demogrcos, dados nanceiros, entre outros. Estes dados precisam de ser armazenados, acedidos e alterados. Estas so as funes das bases de dados. Hoje em dia, poucas so as organizaes que conseguem funcionar sem esta tecnologia. Para ajudar na manuteno das bases de dados, foram criados os Sistemas de Gesto de Bases de Dados (SGBD), que so um conjunto de programas que controlam a organizao, armazenamento e acesso aos dados. Existem vrios SGBD, sendo o sistema Oracle, considerado o melhor, pela indstria. No entanto, o SGBD da Microsoft, SQL Server, tem vindo a ganhar terreno, principalmente por oferecer uma elevada facilidade de instalao, para um SGBD do seu calibre. Neste relatrio, iremos apresentar algumas caractersticas do Microsoft SQL Server, que mostram que este SGBD consegue concorrer com o seu rival comercial Oracle.
1.1 Introduo histrica

Em 1987, a Microsoft e a Sybase aliaram-se para desenvolver um sistema de gesto de base de dados, baseado no software Sybase DataServer (ainda por ser lanado). A Sybase caria com os direitos para distribuir a verso para Unix e VMS (esta verso acabaria por se chamar Sybase SQL Server) e a Microsoft iria distribuir a verso para OS/2. Assim, em 1989, foi lanada a primeira verso do Microsoft SQL Server, SQL Server 1.0. Em 1990 foi lanada a verso para Windows: SQL Server 1.1. Na altura em que o Windows NT foi lanado, a popularidade do OS/2 tinha cado bastante. Alm disso o Windows NT j suportava novas arquitecturas que o OS/2 no suportava. Isto fez 1
1. I NTRODUO
1.2. Notas sobre instalao 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 lanou 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 lanado em 1998 o SQL Server 7.0, o primeiro SGBD com uma verdadeira interface grca. A marcha no cou por aqui. Em 2000 foi lanado o SQL Server 2000 que dava continuidade a um produto que por esta altura j era bastante reconhecido no mercado empresarial (em 2003 seria lanada a verso 64 bits - que tambm se tornaria na primeira verso deste SGBD a fazer uso desta arquitectura). Em 2005 foi lanado o SQL Server 2005 (a verso estudada neste relatrio) e, recentemente, em Agosto de 2008, foi lanada a verso 2008. Para a realizao deste trabalho foram consultados os manuais [10], [6], [5], [4], [8], [7], [3], [2], [9] e o site [1].
1.2
Notas sobre instalao do sistema
Antes de instalar: 1. Desinstale a Framework .NET 1.2 (as verses 1.0 e 1.1 no tm de ser obrigatoriamente desinstaladas). A seguir instale a Framework .NET 2.0. 2. Instale o SQL Server 2005, seguindo os vrios passos: 3. Depois de satisfeitos os pr-requisitos, siga com a instalao clicando em "install". 4. Escolha os componentes a instalar (todos). 5. Em seguida, escolha o local de instalao dos componentes. 6. Clique "seguinte" nos restantes ecrs e a instalao ser iniciada.
2
Cobertura do SQL
2.1 DDL
DDL um subconjunto de operaes do SQL que contem os comandos para denir dados. Os principais comandos deste conjunto so o CREATE, ALTER e DROP. O T-SQL tem suporte para criao, alterao e destruio de Base de Dados, Funes, ndices, Procedimentos, Tabelas, Triggers, Utilizadores e Views. De entre estes o mais usado o CREATE, nomeadamente para criao 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 esto denidos o seu nome, o nome das colunas e o tipo de dados que cada coluna ir suportar, sem estar limitado por quais queres restries. Para o caso de se desejar ter uma base de dados mais poderosa e coesa o T-SQL disponibiliza, entre muitos outros, os seguintes parmetros e restries: Database_Name: onde podemos indicar em que base de dados ser criada a tabela, essa clusula remove a necessidade de usar o USE. Owner: poder especicar outro dono para a tabela, caso no seja especicado o utilizador actual ca como dono. Identity: especica que coluna vai servir como identicador da tabela. Seed: se quiser que o ID da tabela no comece a 1, poder indicar o valor neste argumento. 3
2. C OBERTURA DO SQL
2.1. DDL
Increment: poder indicar que incremento usar em cada novo tuplo, por omisso este valor 1. Not for Replication: Se esta condio estiver activa, o sistema de base de dados no ir tentar impor novos valores de ID aos dados inseridos por um processo replicante, mantendo o ID original. Os dados inseridos por outros processos no sero afectados. Null: que indica se o valor de uma coluna poder ser ou no Null. Primary Key: indica se uma coluna ou conjunto de colunas formam um valor identicativo 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 aco tomar quando um tuplo, referenciado atravs de uma Foreign Key, removido. Por omisso esta opo encontrase como NO ACTION, tendo que ser alterado para CASCADE para o caso de se querer remover todos os outros tuplos. Estes parmetros tambm esto disponveis para o ALTER. Para destruir estruturas, usado o comando DROP com a seguinte sintaxe bsica: DROP type name. A quando da remoo de uma tabela todas os tuplos, ndices e triggers especcos dessa tabela iro ser removidos, mas Views e Procedimentos que tm referencias para a tabela tero 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 iro ser removidos caso esteja activa a opo ON DELETE CASCADE.
2.2. DML
2.2
DML
DML o conjunto das operaes que manipulam os dados. Quer isso dizer que sero usadas para inserir, remover e editar dados, nomeadamente com os comandos INSERT, UPDATE e DELETE. Tambm 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 verstil deixando, entre outros, inserir dados Null, tuplos com menos dados que colunas, por diferentes ordens, atravs de tabelas temporrias 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 clusula CASE. A forma mais comum de remover dados indicando a tabela e que condies o tuplo precisa de ter, mas o T-SQL tambm tem suporte para remover sem indicar condies, remover vrios tuplos, remover o tuplo onde se encontra um cursor e at remover tuplos seleccionados com uma sub consulta. Caso no 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 bsica, 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 clusulas: AS: permite renomear as colunas. INTO: guarda os resultados noutra tabela. FROM: dene 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 clculos como a mdia, o Max, mnimo e somatrio. 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
2.3. Tipos de Dados
2.3
Tipos de Dados
O T-SQL tem suporte para os seguintes tipos de dados: Valores numricos inteiros: bigint int smallint tinyint bit decimal numeric money smallmoney Valores numricos aproximados: oat real Data e hora: datetime smalldatetiem Strings: char varchar text nchar nvarchar ntext 6
2.3. Tipos de Dados
Strings binrias: binary varbinary image Outros: cursor sql_variant table timestamp uniqueidentier xml
3
Armazenamento e le structure
3.1 O Buffer Pool
O principal componente de memria do SQL Server 2005 o buffer pool. Toda a memria que no esteja a ser usada por outros componentes de memria, permanece no buffer pool, onde usada como cache de dados para pginas lidas dos cheiros da base de dados (em disco). O gestor de buffer (buffer manager) controla as funes de I/O do disco, com o objectivo de carregar as pginas para essa cache de dados (de modo a que essa informao possa ser acedida por todos os utilizadores). Quando outros componentes necessitam de memria, podem pedir um buffer (pgina em memria do mesmo tamanho que uma pgina de dados/ndices) do buffer pool. Aps estes pedidos, os buffers so, normalmente, transferidos para outros tipos de caches (como, por exemplo, a cache responsvel por guardar as queries e procedimentos SQL executados recentemente - procedure cache). Ocasionalmente, o SQL Server precisa de blocos de memria contguos superiores ao tamanho mximo das pginas usadas pelo buffer pool (8 KB). Quando assim , reservada memria fora do espao de endereamento deste. No entanto, o uso de grandes blocos de memria minimizado, de modo a que chamadas directas ao sistema operativo representem uma fraco mnima do uso de memria. O SQL Server, ao arrancar, calcula o tamanho do espao de endereamento 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 enderear (directamente) 4 GB de memria. No entanto, o SQL Server pode fazer uso da API (do Windows) Address Windowing Extensions (AWE) que, actuando como uma terceira rea de memria, permite ultrapassar esta 9
3. A RMAZENAMENTO E FILE STRUCTURE
3.2. Acesso s pginas em memria
restrio. Nos sistemas x64 esta restrio no existe, pelo que ignorada a congurao para esta API. Alm do tamanho do VAS, calculado o nmero de pginas que se espera ser possvel alocar (este valor designado por Target Memory). possvel ver estas informaes, 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 - memria fsica disponvel. virtual_memory_in_bytes - memria virtual disponvel. bpool_commited - nmero de pginas no buffer pool (no inclui memria reservada). bpool_commit_target - Target Memory.
3.2
Acesso s pginas em memria
O SQL Server tenta manter o acesso s pginas, na cache de dados, rpido (no eciente pesquisar em toda a cache) pelo que as pginas so guardadas numa hash table (implementada como uma pgina que contm um array - que na verdade uma lista ligada - de apontadores para as pginas na cache), em que a combinao dos identicadores da base de dados (serve para identicar a que base de dados o cheiro pertence), do cheiro e da pgina, so os argumentos de entrada da funo de hash.
3.3
Gesto de pginas na cache de dados
No SQL Server, o mesmo mecanismo responsvel por escrever as alteraes das pginas em disco e por marcar como livre a memria ocupada por pginas que no sejam referenciadas h algum tempo (sendo mantida uma lista ligada com os endereos das pginas "livres"). Cada buffer na cache de dados tem um cabealho que contm informao sobre as duas ltimas vezes que cada pgina foi referenciada, alm de outras informaes sobre o estado dessas mesmas pginas, incluindo o facto de uma pgina estar ou no dirty (o seu contedo ter alterado desde que foi lida de disco). Esta informao usada na implementao da poltica de substituio de pginas, que usa o algoritmo LRU-K (Least Recently Used-K). Este algoritmo baseia-se na losoa do algoritmo LRU, mas mantm-se a par das ltimas K vezes que a pgina foi referenciada (sendo usado o valor 2 para K, na implementao do SQL Server). Assim, buffers que contenham pginas consideradas mais importantes, mantm-se no buffer pool activo, enquanto buffers com pginas menos referenciadas acabam por regressar lista de buffers livres. O trabalho de percorrer o buffer, escrevendo pginas "dirty" em disco e adicionando buffers lista de buffers livres feito por um processo assncrono, denominado lazywriter. Este tambm responsvel por diminuir ou aumentar a cache de dados, de modo a manter a memria fsica livre do sistema operativo em cerca de 5MB, de modo a evitar paginao. Existe outro processo tambm responsvel por percorrer a cache de buffer, periodicamente, 10
3.4. Arquitectura NUMA
e escrever em disco pginas "dirty": checkpoint. A diferena entre os processos lazywriter e checkpoint o facto de este ltimo nunca colocar buffers na lista livre. O nico objectivo do checkpoint assegurar que pginas alteradas h mais de x tempo so, efectivamente, escritas em disco, de modo a minimizar o tempo que o SQL Server necessitaria para recuperar de uma falha. Este processo tambm corre automaticamente, mas tambm pode ser accionado manualmente atravs do comando CHECKPOINT. Uma caracterstica que existia nas verses do SQL Server anteriores 2005 era a possibilidade de marcar tabelas, de modo a que as suas pginas fossem mantidas em memria, indenidamente. Este processo, chamado pinning de uma tabela, podia ser accionado usando a opo pintable do procedimento sp_tableoption. Este comando ainda existe no SQL Server 2005, mas no tem efeito (de modo a se manter retro-compatvel).
3.4
Arquitectura NUMA
O SQL Server 2005 compatvel com a arquitectura Non-Uniform Memory Access (NUMA). A maior vantagem desta arquitectura o facto de ser uma soluo escalvel para o aumento do nmero de CPUs nos computadores. Na arquitectura NUMA os CPUs esto agrupados em pequenos conjuntos, designados por ns NUMA, sendo cada n servido por um bus de sistema, alm de ter a sua prpria memria interna. Cada CPU pode aceder memria de outros ns, de forma coerente, embora seja mais rpido aceder memria local do seu n. Assim, ao contrrio da arquitectura Symmetric Multiprocessing (SMP), onde todo o acesso a memria feito pelo mesmo bus partilhado (o que at funciona bem para um pequeno numero de CPUs), NUMA alivia este "bottleneck" limitando o nmero de CPUs num mesmo bus. O SQL Server tem ainda a vantagem de permitir subdividir um (ou mais) ns NUMA fsicos em ns mais pequenos, denominados software NUMA (soft-NUMA). Tipicamente, usa-se softNUMA quando se est na presena de vrios CPUs, mas no 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). Congurando quatro ns 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 pginas de dados e ndices, carregando, para o buffer pool, estas pginas antes delas serem pedidas. Esta optimizao aumenta bastante a ecincia do processamento de dados. Este mecanismo gerido internamente, sem necessidade de ser congurado. 11
3.6. Sistema de cheiros
3.6
Sistema de cheiros
Uma base de dados no SQL Server 2005 pode ser vista como uma coleco de cheiros que contm dados e meta-dados, correspondendo cada cheiro da base de dados a um cheiro do Windows (no entanto, cada cheiro tem um nome lgico e um nome fsico). Esta dependncia, embora diminua a portabilidade deste SGBD, tem a vantagem de permitir fazer uso das ferramentas disponibilizadas por esses sistemas de cheiros (tal como encriptao e denio de quotas/permisses) de modo totalmente transparente para o SQL Server. Existem os seguintes trs tipos de cheiros no SQL Server: Ficheiros de dados primrios - contm informao sobre todos os cheiros na base de dados, alm de guardarem dados. Ficheiros de dados secundrios - guardam dados dos utilizadores (ndices, vistas, tabelas e procedimentos). Tm a funo de replicar esta informao por vrios discos. Ficheiros Log - contm informao necessria para a recuperao de todas as transaces efectuadas. Os cheiros de dados podem ser atribudos a um legroup, uma caracterstica que permite agrupar cheiros. Isto pode ser til para colocar dados (e ndices) numa unidade de disco especica ou para a criao de um regime de backup que apenas salvaguarda os cheiros de determinados legroups. Os cheiros log, no entanto, no podem ser atribudos a um legroup porque so guardados separadamente dos cheiros de dados.
3.7 Pginas e Extents

A um nvel de abstraco superior ao do sistema de cheiros, o armazenamento da base de dados no SQL Server 2005 feito em pginas e extents. O objecto de armazenamento bsico a pgina (que, tal com j foi dito, tem 8KB), cuja estrutura semelhante de outros objectos do sistema operativo Windows. Primeiro, a pgina identicada por um identicador nico. Em seguida, contm um cabealho (header), de 96 bytes, com informao pertinente sobre a pgina incluindo o seu tipo, espao livre, etc. Seguemse as linhas com os dados (podendo, no mximo, uma linha ocupar 8 060 bytes), que crescem do incio da pgina para o nal. No m da pgina, encontra-se o slot array com apontadores para cada linha de dados (cresce do nal da pgina para o incio). O tamanho das linhas (de dados) de uma pgina no se pode "exceder" para outras pginas, pelo que, para armazenar tipos de dados que ocupem mais espao (como imagens, texto muito longo e XML) so combinadas mais pginas. Os extents so usados para alocar espao para tabelas e ndices e so a unidade bsica de gesto de memria. Cada extent contm at oito pginas contguas, fazendo com que o seu tamanho mximo seja de 64KB. 12
3.8. Organizao dos cheiros
3.8
Organizao dos cheiros
Existem trs modos de organizar as pginas no Sql Server: heap (modo por defeito) - as pginas no esto ordenadas. Assim, as linhas (de dados) so inseridas em qualquer espao. clustered index - as pginas so ligadas atravs 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+ no se encontram em nenhuma ordem especial (j no existindo a restrio do ndice nico). Outros modos de organizao (como multitable clustering e hash) no so suportados.
3.9 Mecanismo de parties

No SQL Server, a partio de dados um mecanismo apenas disponvel na verso Enterprise Edition. Um objecto encontra-se particionado quando se encontra dividido (internamente) em unidades fsicas (separadas) que podem ser armazenadas em diferentes localizaes, no entanto, as parties so invisveis para os utilizadores e programadores de T-SQL. Podem se usar parties para tornar mais eciente (ou menos pesado) a utilizao de objectos grandes (tabelas de 2GB, por exemplo) ou quando alguns tuplos passaram a ser acedidos apenas para leitura, separando-se estes dos tuplos actualizveis, etc. No SQL Server, criar parties um processo de trs passos. Passo 1 - Criao da funo de partio No primeiro passo, cria-se uma funo de partio (ou seja, denido o critrio de diviso 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 parmetros deste comando so: partition_function_name - identicador SQL vlido input_parameter_type - tipo de dados da coluna de partio (pode ser qualquer um excepto text, ntext, image, xml, timestamp, varchar(max), nvarchar(max), varbinary(max), alias e tipos CLR (Common Language Runtime) denidos pelo utilizador). boundary_value - lista de limites que dene as parties LEFT ou RIGHT - dene a que lado do valor limite a partio pertence. Passo 2 - Criao do esquema de partio 13
3.9. Mecanismo de parties
Neste passo cria-se um esquema de partio. Este esquema dene como as parties sero sicamente denidas na base de dados (se caro em legroups diferentes ou no). O comando para este passo CREATE PARTITION SCHEME, cuja sintaxe : CREATE PARTITION SCHEME partition_scheme_name AS PARTITION partition_function_name [ ALL ] TO ( le_group_name | [ PRIMARY ] [ , ...n ] ) [;] Os parmetros deste comando so: partition_scheme_name - identicador SQL vlido partition_function_name - nome da funo de partio qual associar este esquema de partio. le_group_name - lista dos legroups aos quais este esquema dever ser associado, ou PRIMARY para associar todas as parties ao legroup primrio (o legroup por omisso do SQL Server). A palavra reservada ALL especica que todas as parties devero ir para esse legroup. Passo 3 - Criao da tabela/ndice Neste ltimo passo, criada a tabela ou ndice que usa o esquema de partio criado. Uma tabela criada com o comando CREATE TABLE, enquanto uma partio criada com o comando CREATE INDEX. A sintaxe de CREATE TABLE : CREATE TABLE ... [ ON partition_scheme_name ( partition_column_name ) | legroup | "default" ] [ TEXTIMAGE_ON legroup | "default" ] [;] A diferena principal entre a criao de uma tabela particionada e uma tabela no-particionada a adio de partition_scheme_name (partition_column_name). Isto permite-nos especicar qual a coluna em que a partio ocorrer. A sintaxe de CREATE INDEX : CREATE ... INDEX ... [ ON partition_scheme_name ( column_name ) | legroup_name | default ] [;] Tal como para criar uma tabela, a diferena principal entre a criao de um ndice tradicional e a criao de um ndice particionado a adio de ON partition_scheme_name ( column_name ). 14
3.9. Mecanismo de parties
O SQL Server 2005 disponibiliza ainda comandos para alterar, arquivar e eliminar parties. Existe tambm uma DMV para recolher informao sobre as parties, designada sys.dm_db_partition_stats.
15
4
Indexao e Hashing
O SQL Server 2005 processa o acesso a dados de duas formas distintas. A primeira atravs de um table scan onde todas as pginas, comeando no inicio da tabela, so varridas extraindo assim a informao denida na query. A segunda atravs de ndices. Os ndices so estruturas que foram desenhadas para aumentar a velocidade de acesso ao repositrio de dados de um SGBD. Se simplicarmos a utilidade destes ndices percebemos que funcionam como o ndice de um livro - ao usarmos ndices podemos encontrar rapidamente dados especcos sem termos que ler todo o contedo de uma tabela. Os ndices no so estruturas obrigatrias, afectam a performance das queries mas no afectam a sua funcionalidade. No entanto, esta diferena de performance pode ter um impacto muito grande no sistema. Esta performance aumentada reduzindo o trabalho de pesquisa s queries. Sem ndices, necessrio 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, so gerados milhares de I/O, estas operaes tm um custo elevado. Com o uso de ndices so necessrias menos leituras e consequentemente a performance aumenta e a utilizao de recursos diminui. Nesta seco explica-se como funcionam e como podem ajudar a melhorar a performance de um sistema.
4.1 Estrutura B-tree

A estrutura de indexao implementada por rvores B+. Uma rvore constituda por uma raiz (root), ramos (branch nodes) e folhas(leaf nodes). A rvore comea com a primeira pgina do ndice (n raiz). Esta raiz contem a gama das chaves de pesquisa e os ponteiros para 17
4. I NDEXAO E H ASHING
4.1. Estrutura B-tree
outras pginas do ndice. Os ns entre o n raiz e os ns folha tambm contm as chaves e os ponteiros para ns inferiores e eventualmente ns folha. Os ns folha tm apontadores para os dados na tabela ou guardam eles prprios os dados, dependendo do tipo de ndice escolhido (iremos falar sobre os tipos de ndice posteriormente). possivel navegar atravs dos ramos da rvore at que seja alcanado um n folha.
Figure 4.1: Exemplo da estrututa B-tree Como podemos ver na gura 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 contm entradas consideradas menores que a entrada actual. O n direita do n actual contm uma sub-rvore em que todos os ns so considerados maiores que qualquer n da sub-rvore do n actual. Desta forma garante-se a ordenao da rvore. Mantendo a rvore equilibrada e ordenada, permite-se um acesso aos ns folha em poucas iteraes. Para manter este equilibro necessrio assegurar que cada n ramo mantenha um nmero de sub-rvores que varie entre n e n/2, onde n representa o nmero de nveis da rvore. A ordenao depende da forma como criado o ndice. Como o ndice j est ordenado, s vezes o sistema no 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 ns da rvore do ndice tm tendncia a encher. Quando h uma insero sobre um n cheio necessrio parti-lo em duas partes - este processo denomina-se page split e implica reorganizar a estrutura para atingir um novo estado de equilbrio, este processo tem um custo (overhead) indesejvel. No entanto possivel congurar o parmetro ll factor que indica qual o espao livre que deve ser deixado quando um n criado. Iremos falar deste e de outros parmetros mais frente. No SQL Server as rvores B+ so 18
4.1. Estrutura B-tree
utilizadas para a indexao e para a organizao de cheiros. Exemplo1 prtico sobre ndices Para tirarmos vantagem do uso dos ndices necessrio inclui-los na clausula WHERE. Se um ndice for criado com as chaves lastname e rstname, os dados so ordenados primeiro por ltimo nome e depois pelo primeiro (gura 4.2).
Figure 4.2: ndice com duas chaves 1) O ndice acedido com grande ecincia no seguinte caso: SELECT PhoneNumber FROM myTable WHERE lastname = smith AND rstname = john; 2) O ndice ainda til no prximo exemplo: SELECT PhoneNumber FROM myTable WHERE lastname = smith; 3) Neste exemplo o indce no e utilizado sendo feito um table scan: SELECT PhoneNumber FROM table WHERE rstname = john; Neste exemplo podemos que o benicio do uso do ndice depende da forma como as chaves so usadas.
1 Exemplo
adaptado de [10]
19
4.2. Tipos de ndices
4.2
Tipos de ndices
O SQL Server implementa ndices de duas classes distintas -clustered index e non-clustered index. 4.2.1 ndices clustered
Um ndice clustered guarda os dados ordenados da tabela em sintonia com a estrutura da rvore. O acesso aos dados das tabelas indexadas por um ndice clustered, tem obrigatoriamente que ser feito atravs do ndice, pois os dados so guardados no prprio ndice. Como os dados da tabela esto guardados segundo a ordem do ndice, foi necessrio implementar um mecanismo que permite fazer uma pesquisa global tabela (Full Table Scan). Para que um ndice seja lido em sequncia num full table scan, os ns folha do ndice esto ligados uns aos outros atravs de apontadores - cada n tem um apontador para o n anterior e para o n seguinte formando assim uma lista ligada.
Figure 4.3: ndice clustered Uma tabela pode ter apenas um ndice clustered. A ordenao dos dados sicamente a mesma do ndice. Uma tabela que tenha um ndice clustered denomina-se clustered table. A 20
seleco das colunas para o ndice clustered muito importante e deve ter em conta a forma como normalmente feito o acesso aos dados. Num tipo de ndice devem ser consideradas as seguintes colunas:
Aquelas que so normalmente alvo de um acesso sequencial.
Aquelas que contm um nmero elevado de valores distintos
Aquelas que so normalmente alvo de queries que usam operadores como BETWEEN, >, >=, <, <= ou dentro da clusula WHERE.
Aquelas que so frequentemente usadas por queries que fazem joins ou agrupam os resultados. 4.2.2 ndices non-clustered
Os ndices non clustered no alteram a ordenao dos dados da tabela. Esta indepndencia dos dados permite que sejam criados vrios ndices deste tipo sobre a mesma tabela - o SQL Server 2005 suporta at 249 indices non clustered sobre a mesma tabela. As folhas da rvore de um indice non clustered guardam um apontador para os dados da tabela e no os prprios dados como acontece num ndice clustered. Embora os dados no estejam guardados nas folhas, sempre que feita uma alterao na tabela preciso reorganizar o ndice. O facto do ndice no conter os dados da tabela signica que o processamento da query necessita de um passo adicional para encontrar os dados. Uma tabela que tenha um ndice non clustered denomina-se heap - os dados no tm uma ordem lgica e so gravados nas pginas que tm espao disponvel. A gura gura 4.4 mostra um diagrama simples de um indice non clustered denido sobre a coluna rstname. 21
Figure 4.4: ndice non clustered
A utilizao de ndices non clustered deve ser considerada nos seguintes casos: Queries que no retornam muitos resultados. Colunas que so normalmente usadas na clausula WHERE e que retornam resultados exactos. Colunas com alta densidade(bastante valores repetidos). essencial ter uma noo clara sobre como feito o acesso aos dados para serem criados ndices non clustered. O SQL Server tem ferramentas como o SQL Server Proler e o Database Engine Tuning Advisor que ajudam a avaliar o acesso aos dados e a determinar quais as colunas candidatas. possivel denir um ndice non clustered sobre um ndice clustered. Neste caso, a pesquisa por uma chave do ndice non clustered resultar numa chave de pesquisa a ser utilizada no ndice clustered. Este processo conhecido por bookmark lookup. 22
4.3. Implementao de ndices
4.3
Implementao de ndices
A funcionalidade dos ndices non clustered pode ser estendida se forem adicionados atributos que no so usados como chave de pesquisa. Assim possivel guardar atributos extra no n folha da rvore do ndice, aumentando a rapidez na disponibilizao dos dados. O funcionamento similar ao de um ndice clustered, no entanto, nem todos os dados so guardados e por isso mantm-se a independncia fsica da tabela. Podem ser denidos vrios ndices com colunas includas sobre a mesma tabela e o efeito de bookmark lookup evitado. 4.3.1 ndices com colunas includas
A funcionalidade dos ndices non clustered pode ser estendida se forem adicionados atributos que no so usados como chave de pesquisa. Assim possivel guardar atributos extra no n folha da rvore do ndice, aumentando a rapidez na disponibilizao dos dados. O funcionamento similar ao de um ndice clustered, no entanto, nem todos os dados so guardados e por isso mantm-se a independncia fsica da tabela. Podem ser denidos vrios ndices com colunas includas sobre a mesma tabela e o efeito de bookmark lookup evitado. 4.3.2 Indexao de views
No SQL Server 2005 as views2 permitem aumentar a performance do sistema. possivel criar um ndice clustered sobre uma view para aumentar a performance no acesso a dados de queries mais complexas - um ndice clustered sobre uma view denomina-se indexed view. Quando um ndice clustered criado sobre uma view, esta torna-se materializada, pois o ndice mantm os dados da tabela em questo. Este mtodo pode ser bastante vantajoso em views que incluam junes entre vrias tabelas e outros tipos de operaes cujo custo de avaliao possa ser elevado. Tambm podem ser denidos ndices non clustered sobre views. Essa opo pode aumentar a performance das queries. Os ndices non clustered nas views oferecem mais opes ao optimizador de queries. Por exemplo, se uma query incluir colunas que no estejam cobertas pelo ndice clustered, o optimizador pode escolher um ou mais ndices secundrios para o plano de execuo da query e evitar fazer um full scan do indexed view. 4.3.3 Indexao full-text
Os ndices mais usados no SQL Server so os indices clustered e non clustered que so organizadados em estruturas B-tree. Estes ndices podem ser criados sobre a maior parte das colunas numa tabela ou view, no entanto, no podem ser criados sobre colunas com objectos do tipo LOB. Quando necessrio fazer uma query sobre este tipo de colunas pode usar-se a
2 http://technet.microsoft.com/en-us/library/cc917715.aspx
23
4.4. Criao de ndices
indexao do tipo full-text3 para evitar um full table scan. O ndice construdo, mantido e utilizado pelo Full-Text Engine for SQL Server (MSFTESQL). Este motor permite pesquisas baseadas em texto que aceitam wildcards4 , palavras chave e padres de reconhecimento. Este mecanismo largamente utilizado em motores de busca na WEB. Estes ndices so guardados no exterior da base de dados, o que permite que assuma qualquer tipo de estrutura, no entanto mantido pelo sistema de gesto da base de dados. Tem como requisitos a utilizao de uma chave que identique univocamente cada um dos registos da tabela alvo e um dos atributos a ser utilizado tem de ser do tipo String e ter de ser nico. A manuteno deste tipo de ndice assncrona, uma insero, remoo ou edio da tabela s ser reectida no ndice por aco manual ou agendada. um ndice muito especco que deve ser utilizado para situaes em que a pesquisa por texto importante. 4.3.4 Indexao XML Os dados XML so guardados em campos com um tipo especco para este tipo de dados, normalmente denominados por BLOBs. A pesquisa neste tipo de colunas feita a partir do motor XQuery5 e os ndices sobre elas utilizam o comando exists para pesquisa de chaves. Os ndices XML podem ser primrios ou secundrios. Um ndice primrio do tipo clustered e implementado com uma rvore B+. Para cada n existente no BLOB existe um registo no ndice. Os ndices secundrios so criados sobre os atributos PATH, VALUE e PROPERTY do BLOB de dados XML.
4.4
Criao de ndices
A criao de ndices pode ser feita atravs do Explorer do SQL Server 2005, no entanto, descrevemos como feita a criao atravz do comando T-SQL CREATE INDEX.
Figure 4.5: Sintaxe do comando CREATE INDEX
3 http://www.simple-talk.com/sql/learn-sql-server/understanding-full-text-indexing-in-sql-server/ 4 http://www.linfo.org/wildcard.html 5 http://www.w3schools.com/xquery/
24
4.4.1
Argumentos do comando CREATE INDEX Cria um ndice exclusivo em uma tabela ou exibio. Um ndice exclusivo aquele no qual duas linhas no podem ter o mesmo valor de chave de ndice. Se um ndice no for UNIQUE , podero existir vrios valores para a mesma chave de pesquisa. Dene-se um ndice como clustered ou non-clustered. Por omisso non-clustered. Apenas permitido denir um ndice clustered por tabela. o nome do ndice. Os nomes de ndice devem ser exclusivos uma tabela ou view, mas no precisam ser exclusivos no banco de dados. Especica o nome da tabela ou view a ser indexada. a coluna, ou colunas, em que o ndice se baseia. Especica dois ou mais nomes de coluna para criar um ndice composto. As colunas devem ser denidas por ordem de prioridade de classicao, entre parnteses, depois do table_or_view_name. Determina se a ordem de classicao crescente ou decrescente. Por omisso ASC. Especica as colunas no chave que sero adicionadas ao nvel folha do ndice non clustered. Especica as opes a serem a usadas ao criar o ndice.
UNIQUE
CLUSTERED | NON-CLUSTERED
index_name
object column_name
ASC | DESC INCLUDE (column [ ,... n]) relational_index_option
4.4.2
Opes do comando CREATE INDEX
Abaixo apresentada a lista das opes mais relevantes para o comando CREATE INDEX. PAD_INDEX = ON | OFF ON - A percentagem de espao livre especicada pelo llfactor aplicada s pginas de nvel intermedirio do ndice. 25
OFF - As pginas de nvel intermedirio so preenchidas quase at ao mximo da sua capacidade. FILLFACTOR = llfactor Especica a percentagem a preencher pelo Mecanismo de Banco de Dados deve preencher no nvel folha de cada pgina do ndice durante a criao ou recriao do mesmo. SORT_IN_TEMPDB = ON | OFF Especica se os resultados da classicao temporrios devem ser armazenados no tempdb. Por omisso OFF. Esta opo pode aumentar a velocidade de criao do ndice mas necessita de mais espao de disco. STATISTICS_NORECOMPUTE = ON | OFF Especica se as estatsticas de distribuio (usadas pelo optimizador da query) so recomputadas. Quando selecionada a opo ON as estatisticas no so recalculadas automaticamente. O padro OFF. DROP_EXISTING = ON | OFF Especica se o ndice nomeado clustered ou non clustered pr-existente descartado e recriado. Se for seleccionada a opo ON o ndice existente descartado e recriado. O nome de ndice especicado deve ser igual ao ndice existente actualmente; no entanto, a denio de ndice pode ser modicada. Por exemplo, pode ser especicadas colunas, ordens de classicao, esquemas de partio ou opes de ndice diferentes. O Padro OFF - ser exibido um erro caso o nome de ndice especicado j exista. ONLINE = ON | OFF Especica se as tabelas subjacentes e os ndices associados esto disponveis para consultas e modicao de dados durante a operao de ndice. O padro OFF. ALLOW_ROW_LOCKS = ON | OFF Especica se permitido bloquear tuplos durante o acesso ao ndice. O padro ON. ALLOW_PAGE_LOCKS = ON | OFF Especica se permitido bloquear pginas durante o acesso ao ndice. MAXDOP = max_degree_of_parallelism Substitui a opo de congurao grau mximo de paralelismo enquanto durar a operao de ndexao. Usa-se MAXDOP para limitar o nmero de processadores usados numa execuo de plano paralelo. O mximo de 64 processadores. O max_degree_of_parallelism pode ser: =1 - suprime a gerao do plano de paralelismo. 26
4.5. Indexao e Hashing - Oracle 10g vs MS SQL 2005
>1 - Restringe o nmero mximo de processadores usados numa operao de ndice ao nmero especicado. =0 (por omisso) - usa o nmero real de processadores, ou menos, dependendo da carga do trabalho de processamento.
4.5
Indexao e Hashing - Oracle 10g vs MS SQL 2005
O sistema Oracle disponibiliza um ndice extra em relao ao Microsoft SQL Server 2005, esse o grande trunfo do Oracle quando comparados os dois sistemas, o tipo de ndice denominase Bitmap. Os Bitmaps so excelentes escolhas para colunas com pouca selectividade devido ao menor custo de armazenamento. Adicionalmente o Oracle fornece rvores B+ de leitura invertida que so bastante teis e ecientes nas inseres sequenciais. Conclumos que no que no contexto da indexao, o sistema Oracle fornece mais mecanismos do que o Sql Server 2005, fornecendo inclusivamente uma alternativa utilizao de rvores B+, o que aumenta o leque de possibilidades para melhorar a ecincia das consultas.
27
5
Processamento e Optimizao de Queries
Uma base de dados relacional consiste em vrias partes, no entanto o seu ncleo constitudo por dois elementos essenciais, o motor de armazenamento e o processador de consultas. Neste captulo vamos perceber como funciona o segundo elemento referido. No SQL Server 2005 o utilizador especica o resultado que pretende obter e o processador de consultas determina como o obter. O processamento de consultas divide-se em duas fases principais, primeiro a optimizao e posteriormente a execuo. A optimizao de queries o processo que o SQL Server 2005 faz atravz da anlise individual de cada query. O SQL Server faz uma anlise individual da query para determinar qual a melhor forma de a executar o objectivo determinar o plano de execuo da query que seja executado em menos tempo. O optimizador faz uma anlise da query baseada na informao sobre os objectos envolvidos (por exemplo, nmero de pginas de uma tabela, tipos de ndice deunidos, estatsticas dos ndices) e gera um plano de execuo. importante perceber o funcionamento do optimizador de queries para aplicar tcnicas que facilitam o trabalho deste componente do SQL Server. Durante a anlise do plano de execuo o processador de consultas selecciona: A ordem da avaliao das restries descritas na clusula WHERE. A consulta analisada para determinar os critrios da consulta que devero ser optimizados, como so exemplo as conjunes e dijunes de expresses booleanas. Os ndices a ser utilizados. So escolhidos aps estimao dos tplos e avaliao dos custos dos ndices disponveis em relao a um full scan das tabelas ou a consulta num ndice clustered. O custo de um ndice clustered tipicamente menor comparado com o 29
5. P ROCESSAMENTO E O PTIMIZAO DE Queries
5.1. Algoritmos para Junes
custo de um ndice non clustered que por sua vez menor de que o custo de um full table scan. A ordem de execuo das operaes de juno. Que algoritmos so escolhidos para assegurar a melhor ecincia, baseada no custo das operaes derivado das estatsticas armazenadas. O optimizador de consultas considerado o crebro de uma base de dados relacional, permite que ela opere de forma inteligente e eciente. Uma base de dados relacional com um mecanismo sosticado de optimizao, tem mais probabilidade de conseguir executar uma consulta de forma mais rpida do que numa base de dados com um mecanismo simples de optimizao. Quanto mais complexas forem as consultas, maiores as diferenas de performance.
5.1 Algoritmos para Junes

O SQL Server 2005 faz a pesquisa de dados atravs de ndices clustered, non clustered, pesquisa total no ndice e full table scan. Seguidamente apresentamos os algortmos usados para processar junes. 5.1.1 Nested Loop
Nesta abordagem, existe uma diviso entre os dois operandos da operao de juno em tabela interior e tabela exterior. Para cada linha da tabela interior, percorrida a tabela exterior e feita a comparao segundo as condies de juno denidas na query. As linhas que satisfaam as condies so seleccionadas. Existem trs tipos de nested loops: Naive Nested-loop - Iterao completa do ndice ou da tabela. Index Nested-loop - Acesso aos dados atravs da tcnica de bookmark lookup, utilizando um ndice. Temporary index nested-loop join - Utilizao de um ndice criado pelo optimizador para funcionamento apenas nesta consulta durante o seu tempo de optimizao.
30
Figure 5.1: Plano com um nested loop
5.1.2
Merge
O algoritmo merge join mais eciente que o nested loop join quando usado para volumes de dados maiores. Num merge join as duas tabelas so ordenadas. Para cada linha da tabela exterior, considerase o grupo contguo de linhas na tabela interior, cujo atributo da relao de juno coincide. Cada linha nas condies supracitadas, que respeite as condies da consulta, ser adicionada ao conjunto resultado. Esta tcnica pode ter um custo elevado devido s operaes de ordenao necessria, no entanto, se os atributos de juno pertenceram chave de um ndice, ou se, por natureza, os tplos de pelo menos uma das tabelas estiver ordenado pelo atributo de juno, ento o utilizador tende a escolh-la. Se excluirmos as operaes de ordenao a complexidade do algoritmo baixa.
31
Figure 5.2: Plano com um merge join
5.1.3
Hash
O algoritmo mais complicado o hash join. Este algorimto uma boa opo quando queremos usar volumes de dados maiores em que os inputs no estejam ordenados. Tambm um algoritmo til quando no h indices sobre as tabelas para aumentar a performance do join. Neste caso uma tabela de disperso pode ser criada se o tamanho de uma tabela for signicativamente mais pequeno do que o da outra. O hash join executado em duas fases - construo e prova. Durante a construo so gerados dois inputs, o input de prova e o input de construo. A cada linha, existente no input de construo, ser aplicado um algoritmo de disperso sobre atributo a ser ligado. A tabela mais pequena funcionar como input de construo, consequentemente a tabela maior funcionar como input de prova. A tabela de disperso ser composta por listas ligadas que sero chamadas por pacotes de disperso. Durante a execuo, o input de prova percorrido 32
e por cada linha computado o valor de disperso com o objectivo de encontrar correspondncias com algum dos pacotes de disperso computados anteriormente.
Figure 5.3: Plano com um hash join
5.1.4 Grace Hash Trata-se de uma implementao do algoritmo hash que tem em conta a possibilidade dos dados no poderem ser carregados inteiramente em memria. S os pacotes de prova e os inputs de construo, que esto a ser analisados, cam carregados em memria a cada instncia. 5.1.5 Join Remoto Uma juno remota invocada quando uma das tabelas participantes remota. Quando tal acontece, a operao de juno feita recorrendo aos algoritmos anteriormente especicados e 33
5.2. Escolha de ndices e avaliao de sub consultas
corre no local onde est denida a tabela do lado direito da operao. Esta juno seleccionada quando a tabela do lado esquerdo da operao de tamanho reduzido em comparao com a outra.
5.2
Escolha de ndices e avaliao de sub consultas
Quando existe mais do que um ndice sobre a mesma tabela podem ser usadas duas tcnicas: interseco de ndices e unio de ndices. Interseco de ndices - consiste na escolha de um conjunto formado pela aquisio dos subconjuntos de cada ndice da forma mais eciente. Unio de ndices - consiste na utilizao de um ndice em especco para cada coluna especicada na clusula WHERE que o utilize. Uma terceira forma de combinao de vrios ndices consiste na fuso num s ndice que seja cobertor de vrias colunas. No SQL Server 2005 quando uma sub consulta indicada no processamento de uma consulta, esta pode ser materializada para que o acesso cclico s mesmas seja reduzido e feito de forma mais eciente.
5.3
Optimizao de queries
Existem depois tipos principais de optimizadores em bases de dados relacionais: optimizadores baseados em sintax e optimizadores baseados em custo. 5.3.1 optimizadores baseados em sintaxe Os optimizadores baseados em sintaxe criam um plano procedimental para obteno de uma resposta a uma consulta SQL, no entanto o plano escolhido depende da sintaxe presente na query e da ordem em que as cusulas aparecem. Um optimizador baseado em sintaxe, utiliza o mesmo plano sempre que a consulta for invocada, independentemente das alteraes que ocorrem na base de dados. 5.3.2 optimizadores baseados em custo
Este tipo de optimizadores no dependem da sintaxe da consulta e so normalmente mais ecientes, pois acompanham as modicaes da base de dados. Iremos descrever este tipo de optimizadores nos tpicos seguintes. 5.3.3 fases de optimizao
A optimizao de consultas do Microsoft Sql Server 2005 envolve trs fases: 34
5.4. Paralelismo
Fase 0 : O optimizador baseia-se num conjunto limitado de regras para gerao de planos de execuo para consultas com pelo menos quatro tabelas. Nesta fase so considerados apenas alguns algoritmos para processamento de junes e um nmero reduzido de ordens das mesmas tido em conta. Aps esta fase, caso seja encontrado algum plano de execuo cujo custo seja inferior a um treshold previamente denido, a optimizao termina. Fase 1: So avaliadas mais algumas ordens de execuo de junes e so aplicadas as regras de gerao de planos de execuo. Caso seja encontrado algum plano de execuo cujo custo seja inferior a um treshold previamente denido ou for encontrado algum plano com um custo inferior a qualquer dos planos encontrados na fase 0, a optimizao termina. Fase 2: Caso o valor para o custo continue a ser superior ao treshold anteriormente referido, a optimizao continuar, aplicando desta vez mtodos que podero ser menos ecientes em termos de complexidade temporal, como so exemplo a recombinao de vrios ndices, materializao de ndices e de views. Esta fase tem um limite mximo de tempo de execuo e devolve o melhor plano encontrado at ento.
5.4
Paralelismo
O SQL Server fornece consultas paralelas para optimizar a execuo de consultas e operaes de ndice para computadores que tm mais de um microprocessador (CPU). O SQL Server pode executar uma consulta ou uma operao de ndice em paralelo usando vrios threads do sistema operacional, a operao pode ser executada de forma rpida e eciente. O resultado desta diviso conhecido por nivelao de paralelismo. Esta nivelao processada cada vez que a consulta invocada. Os critrios escolhidos pelo optimizador quando determina o nvel de paralelismo so os seguintes: Nmero de processadores Nmero de utilizadores activos concorrentes Quantidade de memria disponvel Tipo de consulta Avaliao da necessidade de utilizao do paralelismo considerando o nmero de tplos a processar
5.5
Estatisticas
Os algoritmos de optimizao e de escolha de planos de execuo baseiam-se em estatsticas dos dados e dos recursos do sistema (tipicamente transaces I/O). 35
5.5. Estatisticas
O SQL Server armazena as seguintes mtricas e informao: Nmero de linhas numa tabela ou num ndice. Nmero de pginas de memria ocupadas pela tabela ou ndice. A altura em que as estatsticas foram feitas. Nmero de linhas usadas para produzir o histograma e a densidade da informao. Comprimento mdio da chave. Histogramas de coluna nica, incluindo os degraus. Uma string indicando se a coluna contm dados em forma caracteres Um histograma um conjunto que contm at 200 valores de uma determinada coluna - pelo menos uma amostra dos dados, esto ordenados. A sequncia ordenada dividida no mximo em 199 intervalos, de forma a que a informao mais signicantiva seja capturada. Normalmente estes intervalos no tm a mesma dimenso. Os seguintes valores, ou a informao necessria para os obter, esto guardados em cada degrau do histograma. RANGE_HI_KEY RANGE_ROWS Indica a fronteira superior de um degrau de um histograma. Especica quantas linhas esto includas na gama de um degrau. Este valor inferior ao RANGE_HI_KEY do seu degrau mas maior que o valor do degrau anterior. Valor que indica quantas linhas so iguais ao valor de RANGE_HI_KEY Nmero mdio de linhas por valores distintos dentro da gama de degraus. Especica quantas chaves distintas esto dentro da gama.
EQ_ROWS AVG_RANGE_ROWS DISTINCT_RANGE_ROWS
No Microsoft SQL Server 2005, os histogramas apenas so construdos para a primeira coluna do conjunto de chaves do objecto a ser estimado. 36
5.6. Pistas em consultas
5.6
Pistas em consultas
Os mecanismos de armazenamento temporrio e de optimizao funcionam para grande parte das consultas, no entanto, ocasionalmente necessrio forar um plano de execuo a funcionar de uma forma particular para se conseguir resultados personalizados. As pistas so directivas que inuenciam o comportamento do optimizador sem alterar a semntica da consulta ou dos resultados. Esta funcionalidade dever ser utilizada com precauo e sob constante monitorizao, pois fora o optimizador a tomar em considerao certos mecanismos em preterimento de outros. Como o optimizador de queries do SQL Server selecciona o melhor plano de execuo para uma consulta, recomendvel que os developers e administradores experientes do SGBD s usem estas pistas apenas em ltimo recurso. Existem trs tipos de pistas que podem ser utilizadas no Microsoft SQL Server 2005, atravs da utilizao da clusula OPTION: Join - Denidas para forar o uso de algoritmos de juno. Query - Denidas para forar o comportamento das clusulas INSERT, SELECT, UPDATE e DELETE. Table - Denidas para forar o comportamento das formas de consulta sobre a tabela. Neste capitulo iremos descrever cada um deles. 5.6.1 Pistas do tipo Join As pistas deste tipo foram o optimizador a usar uma estratgia de juno entre duas tabelas. LOOP | HASH | MERGE - Especica que a juno na consulta deve usar loop, hash ou mesclagem. O uso de LOOP | HASH | MERGE JOIN fora uma juno especca entre duas tabelas. LOOP no pode ser especicado com RIGHT ou FULL como um tipo de juno. REMOTE - Especica que a operao de juno executada no site da tabela direita. Isso til quando a tabela esquerda uma tabela local e a tabela direita uma tabela remota. REMOTE dever ser usado somente quando a tabela esquerda tiver menos linhas do que a tabela direita. Se a tabela direita for local, a juno ser executada localmente. Se ambas as tabelas forem remotas, mas de fontes de dados diferentes, REMOTE far com que a juno seja executada no site da tabela direita. Se ambas as tabelas forem tabelas remotas da mesma fonte de dados, REMOTE no ser requerido. Uma pista deste tipo no poder ser usada quando um dos valores que so comparados no predicado de juno for lanado em um agrupamento diferente usando a clusula COLLATE. Esta pista s pode ser usada somente para operaes de INNER JOIN. 37
5.6.2
Pistas do tipo Tabela
As pistas do tipos tabela substituem o comportamento padro do optimizador de consulta durante a instruo DML (linguagem de manipulao de dados) ao especicar um mtodo de bloqueio, um ou mais ndices, uma operao de processamento de consulta, como uma vericao de tabela ou busca de ndice, ou outras opes. Abaixo so apresentadas algumas pistas deste tipo1 . NOEXPAND - As indexed views no so expandidas. INDEX(index_val [,...n]) - Indica os ndices que devem ser utilizados. FASTFIRSTROW - Equivalente a OPTION (FAST 1). NO WAIT - Devolve um erro no instante em que um LOCK for encontrado. ROWLOCK - Indica que devem ser denifos LOCKS nas linhas em vez de serem denidos na tabela ou ao nvel das pginas. PAGLOCK - Indica que devem ser denidos LOCKS ao nvel das pginas. TABLOCK - Indica que devem ser denidos LOCKS ao nivel da tabela. NOLOCK - Equivalemte a READUNCOMMITED. HOLDLOCK - Equivalente a Serializable. UPDLOCK - Deine a utilizao de LOCKS de edio desde o nicio da transao at ao nal da mesma. XLOCK - Utilizao de LOCKS exclusivos durante a transao. READPAST - As linhas que estejam bloqueadas por um LOCK no so lidas. READUNCOMMITED - Permite dirty reads. READCOMMITED - As regras de leitura por LOCKS so respeitadas. READCOMMITEDLOCK - Funciona da mesma forma que o READCOMMITED. REPEATABLEREAD - Funciona da mesma forma que o READCOMMITED. SERIALIZABLE - Mantm um LOCK denido at ao m de uma transao.
1A
descrio mais completa pode ser consultada em http://technet.microsoft.com/pt-br/library/ms187373.aspx
38
KEEPIDENTITY - Os valores de identidade nos cheiros de dados devem ser utilizados como identicadores das colunas. KEEPDEFAULTS - Indica a utilizao dos valores por defeito de uma determinada coluna quando os atributos encontram-se a null. IGNORE_CONSTRAINTS - Especica que qualquer restrio da tabela ignorada pela operao de importao. Por padro, INSERT verica as restries CHECK e FOREIGN KEY. Quando a opo IGNORE_CONSTRAINTS for especicada para uma operao de importao em massa, INSERT dever ignorar essas restries numa tabela de destino. No possvel desabilitar restries UNIQUE, PRIMARY KEY ou NOT NULL. IGNORE_TRIGGERS - Especica que qualquer trigger denido na tabela ser ignorado pela operao de importao. 5.6.3 Pistas do tipo Query As dicas do tipo query especicam que as dicas indicadas devem ser usadas ao longo da query. As dicas de consulta afectam todos os operadores na instruo. Abaixo so apresentadas algumas pistas deste tipo2 HASH GROUP ou ORDER GROUP - As agregaes denas nas clusulas GROUPBY, DISTINCT ou COMPUTE devem ser feitas utilizando disperso ou ordenao. CONCAT UNION ou HASH UNION ou MERGE UNION - Especica que todas as operaes da clusula UNION devem ser executadas com o algoritmo de concatenao, de disperso ou de fuso. LOOP JOIN ou HASH JOIN ou MERGE JOIN - Fora o funcionamento descrito para as pistas de Juno. FAST number_rows - Indica a prioridade na devoluo dos primeiros number_rows tplos. Aps a devoluo dos mesmos a consulta contnua a ser executada normalmente. FORCE ORDER - Indica que a ordem das tabelas deve ser mantida durante a optimizao da consulta. MAXDOP number_of_processors - Dene o nvel de paralismo. OPTIMIZE FOR (variable_name = literal_constant[,..n] - Permite invocao explcita da optimizao dos parmetros descritos, ignorando os valores presentes em cache.
2A
descrio mais completa pode ser consultada em http://msdn.microsoft.com/pt-br/library/ms181714.aspx
39
RECOMPILE - Fora a recompilao do plano de execuo da consulta cada vez que a mesma for executada. Aps a compilao o plano revogado. ROBUST PLAN - Fora o optimizador de consulta a tentar criar um plano que trabalhe com o tamanho mximo de tplos. Os tplos podem ser to grandes que, s vezes, o operador particular no consegue process-las. Se isso ocorrer, o Mecanismo de Banco de Dados produzir um erro durante a execuo da consulta. KEEP PLAN - Permite reduzir o nmero de vezes que o plano de execuo de uma consulta recompilado. KEEP FIXED PLAN - Proibe o optimizador de recompilar o plano de execuo devido a alteraes estatsticas. EXPAND VIEWS - Desactiva a utilizao de indexed views no plano de execuo. USE PLAN Nxml_plan - Fora a utilizao do plano de execuo descrito em XML.
40
6
Gesto de transaces e controlo de concorrncia
O modo como as transaces so geridas fundamental para qualquer SGBD. As transaces so a unidade bsica de trabalho do Microsoft SQL Server, consistindo num conjunto de operaes (sobre a base de dados) que devero ser completadas como um todo ou, no caso de falha, devero ser abortadas e rolled back, de modo a que nenhuma se realize. De modo a garantir a integridade dos dados, o SQL Server garante que as suas transaces satisfazem quatro caractersticas conhecidas como propriedades ACID: Atomicidade. Todas as operaes da transaco so reectidas na base de dados ou nenhuma . O mecanismo de gesto de transaces do SQL Server consegue determinar se uma transaco foi, ou no, completada com sucesso, desfazendo as modicaes dos dados, se necessrio. Consistncia. Aps o trmino de uma transaco (admitindo que no existem outras transaces a ser executadas concorrentemente), todos os dados e estruturas internas devero car num estado consistente e reectir, correctamente, a transaco que acabou de ser executada, quer esta tenha sido realizada com sucesso ou falhado, partindo do pressuposto que a base de dados j se encontrava num estado consistente aquando da ocorrncia da transaco. O SQL Server garante esta propriedade, permitindo, ainda, vrios nveis de consistncia. Consistncia. Aps o trmino de uma transaco (admitindo que no existem outras 41
6. G ESTO DE TRANSACES E CONTROLO DE CONCORRNCIA
6.1. Tipos de transaces
transaces a ser executadas concorrentemente), todos os dados e estruturas internas devero car num estado consistente e reectir, correctamente, a transaco que acabou de ser executada, quer esta tenha sido realizada com sucesso ou falhado, partindo do pressuposto que a base de dados j se encontrava num estado consistente aquando da ocorrncia da transaco. O SQL Server garante esta propriedade, permitindo, ainda, vrios nveis de consistncia. Durabilidade. Assim que uma transaco realiza commit, os seus efeitos reectemse de forma permanente na base de dados, mesmo que ocorram falhas de sistema. O transaction log do SQL Server garante esta propriedade, uma vez que, em caso de falha, o SQL Server usa o transaction log para refazer as transaces committed (que tenham sido afectadas pela falha) e fazer o roll back das transaces uncommitted. No entanto, cabe ao gestor da base de dados a tarefa de salvaguardar os cheiros que compem o transaction log (fazendo backups, por exemplo), uma vez que sem eles, poder no ser possvel recuperar a base de dados.
6.1
Tipos de transaces
O SQL Server suporta quatro tipos (modos) de transaces. 6.1.1 Autocommit
No modo autocommit, o modo por omisso do SQL Server, cada comando T-SQL (select, insert, update, etc.) , automaticamente, committed quando termina ou rolled back quando falha, ou seja, cada comando visto como uma transaco completa. Eis um exemplo: incio da transaco (implcito) UPDATE contas SET saldo = saldo + 200 WHERE iban = "PT50000201231234567890154" m da transaco (rollback ou commit - implcito) Se ocorrer algum erro durante a execuo deste comando, este rolled back, caso contrrio, a aco completada, sendo gravados os seus efeitos. 6.1.2 Transaces explcitas
Numa transaco explcita necessrio denir explicitamente o incio e m da mesma. Este tipo de transaces til quando se quer que vrias aces sejam todas completadas ou que nenhuma se realize, de modo a no se acabar com dados inconsistentes na base de dados. Em T-SQL so usados os seguintes comandos: BEGIN TRANSACTION. Este comando marca o incio de uma transaco. Pode ser usada a palavra abreviada TRAN em vez de TRANSACTION. 42
COMMIT TRANSACTION ou COMMIT WORK. Estes comandos assinalam a concluso, com sucesso, da transaco, podendo ser feito commit das modicaes realizadas. COMMIT. A diferena entre TRANSACTION e WORK o facto de se poder referir a uma transaco pelo seu nome (denido pelo utilizador) com COMMIT TRANSACTION, no sendo isso possvel com COMMIT WORK. ROLLBACK TRANSACTION ou ROLLBACK WORK. Estes comandos assinalam a falha de uma transaco, devendo os seus efeitos ser rolled back. Exemplo de uma operao que benecia deste tipo de transaco: BEGIN TRANSACTION transferencia_bancaria; UPDATE contas SET saldo = saldo - 200 WHERE iban = "PT50000201231234567890154"; UPDATE contas SET saldo = saldo + 200 WHERE iban = "ES0700120345030000067890"; COMMIT TRANSACTION transferencia_bancaria; Assim, se houver uma falha aps a realizao do primeiro UPDATE, toda a transaco ser rolled back, mantendo-se a consistncia da base de dados. Nested Transactions O SQL Server permite que transaces (denominadas "interiores") ocorram dentro de outras transaces (denominadas "exteriores"), chamando-se estas transaces nested transactions (transaces aninhadas). Isto ocorre quando, por exemplo, um procedimento inicia uma transaco na qual chamado outro procedimento que tambm inicia uma transaco. Pode-se determinar se ainda existem transaces a decorrer e quo aninhada uma transaco se encontra, consultando a varivel built-in @@TRANCOUNT. Quando no existem transaces activas no sistema, @@TRANCOUNT possui o valor 0. Cada comando BEGIN TRANSACTION incrementa o valor da varivel em 1 e cada COMMIT diminui o seu valor nessa mesma quantidade. Se @@TRANCOUNT tiver valor 1 quando um comando COMMIT encontrado, ento feito commit transaco. No entanto, se o seu valor for superior a 1, @@TRANCOUNT , apenas, subtrado de uma unidade ( assumida a existncia de uma transaco exterior). Assim, quando se faz commit das transaces interiores, o SQL Server, na realidade, no efectua quaisquer alteraes at que a transaco exterior seja committed; apenas subtrada uma unidade ao valor de @@TRANCOUNT. Por esta razo, imperativo que cada transaco interior faa COMMIT, de modo a que @@TRANCOUNT seja devidamente actualizado e o seu valor seja 1 quando a transaco exterior zer COMMIT. Se a transaco exterior ou uma das interiores falharem, ento nenhuma transaco ser committed, ocorrendo o roll back de todas elas. S feito o commit de todas as transaces, se 43
o commit da transaco exterior for bem sucedido. Executar o comando ROLLBACK, no interessando o quo aninhada uma transaco se encontra, faz com que a transaco exterior e todas as interiores sejam rolled back (ou seja, coloca o valor de @@TRANCOUNT a 0). Se a uma transaco interior for dado um nome, no possvel fazer ROLLBACK para esse nome. sempre necessrio fazer ROLLBACK para a transaco exterior ou, alternativamente, para um savepoint (explicados na sub-seco seguinte). O exemplo seguinte apresenta uma nested transaction:
Figure 6.1: nested transaction Savepoints Os savepoints permitem que se faa o roll back de apenas uma parte das transaces. Todas as modicaes at esse savepoint so mantidas, mas os comandos seguintes, at ao ROLLBACK, so rolled back. A sintaxe, para especicar um savepoint, a seguinte: SAVE TRAN[SACTION] savepoint_name Para se fazer o roll back para o savepoint, usa-se o commando ROLLBACK TRANSACTION com o nome do savepoint: ROLLBACK TRAN[SACTION] savepoint_name Os savepoints so teis em situaes em que pouco provvel que ocorram erros. Exemplo: BEGIN TRANSACTION UPDATE contas SAVE TRANSACTION inicio_apagar_clientes DELETE clients IF @@error = -1 ROLLBACK TRANSACTION inicio_apagar_clientes 44
COMMIT TRANSACTION Assumindo que o erro infrequente, pode ser mais eciente fazer o roll back para o savepoint do que testar a validade do DELETE (se este custo for muito elevado). 6.1.3 Transaces implcitas No modo de transaces implcitas, o SQL Server inicia, automaticamente, uma transaco quando encontra determinados comandos SQL (a no ser que uma transaco j esteja em progresso). Para terminar a transaco implicitamente iniciada, necessrio realizar um COMMIT TRANSACTION ou ROLLBACK TRANSACTION. Por omisso, o modo de transaces implcitas, encontra-se desactivado. Para activar ou desactivar este modo, pode-se usar o seguinte comando T-SQL: SET IMPLICIT_TRANSACTIONS ON | OFF Aps activada esta opo, os comandos que iniciam, implicitamente, uma transaco so: ALTER TABLE, CREATE, DELETE, DROP, FETCH, GRANT, INSERT, OPEN, REVOKE, SELECT, TRUNCATE TABLE e UPDATE. Isto til para correr scripts que precisem de alterar dados dentro de transaces. Pode-se ligar o modo de transaces implcitas no incio do script e desactiv-lo no m do mesmo. 6.1.4 Batch-scoped No modo de transaces batch-scoped, as queries, executadas via MARS (ver a seguir), so executadas num ambiente dedicado. Apenas quando a execuo de todos os trabalhos terminada, que as alteraes ocorridas no ambiente dedicado so copiadas para o ambiente usual da base de dados. Multiple Active Result Sets (MARS) MARS uma arquitectura, baseada em multiplexing, que permite s aplicaes, que acedem base de dados, executar mltiplas operaes SQL numa mesma conexo (mas no paralelamente). As vrias operaes so executadas de forma intercalada, embora a execuo das mesmas possa ser interrompida em pontos bem denidos. Na realidade, a maior parte dos comandos SQL so executados de forma atmica (i.e. tm que ser completados antes de a execuo poder ser mudada para outro pedido MARS). Apenas alguns comandos podem ser interrompidos durante a sua execuo (e.g. SELECT, FETCH, READTEXT, RECEIVE e BULK INSERT). Por exemplo, imaginemos que efectuamos um SELECT, que nos devolver dois milhes de tuplos. A meio desta "devoluo", feito um INSERT via MARS. Uma vez que o comando SELECT pode ser interrompido, este pra e o INSERT realizado. Como o INSERT no pode multiplexado, o INSERT ter que decorrer at ser terminado. Apenas quando isto acontecer que o SELECT ser retomado. Sem a arquitectura MARS, o INSERT apenas poderia ser realizado aps o trmino da operao SELECT. De notar que, caso o INSERT demore muito tempo a ser realizado, o gestor de deadlocks do SQL Server far com que a operao SELECT 45
6.2. Locks
falhe (esta no car eternamente bloqueada).
6.2
Locks
Os protocolos usados pelo SQL Server para garantir o isolamento das transaces so baseados em locks. Estes objectos permitem que mltiplos utilizadores acedam, simultaneamente e de modo sincronizado, a um mesmo conjunto de dados. A gesto dos locks feita internamente pelo gestor de locks do SQL Server. Estes so adquiridos e libertados, de acordo com as aces dos utilizadores, sem que seja necessrio program-los explicitamente (embora seja possvel "inuenciar" o gestor de locks). A view sys.dm_tran_locks contm o registo de todos os locks existente no sistema, bem como outras informaes pertinentes (recurso sobre o qual o lock est aplicado, modo do lock, etc.). Nesta seco examinaremos algumas propriedades do sistema de locking disponibilizado por este SGBD. 6.2.1 Nveis de granularidade
O SQL Server est optimizado para determinar qual o tipo de lock a obter sobre um recurso - por exemplo, se for feita a insero, remoo ou actualizao de um nico tuplo, obtido um row level lock; page level lock para pesquisas parciais numa tabela; e table level lock para pesquisas em toda a tabela. A gura 6.2 mostra, em maior pormenor, os nveis de granularidade dos locks do SQL Server.
Figure 6.2: Granularidade dos Locks medida que o nvel de granularidade do lock se vai tornando mais grosseiro, a concorrncia aos dados na base de dados diminui. Fazer lock a uma tabela completa impede o seu acesso 46
6.2. Locks
por parte de outros utilizadores, embora diminua o overhead criado pela gesto de locks, uma vez que o nmero de locks em uso diminui. Em contrapartida, com um nvel de granularidade no - tal como row level - a concorrncia aumenta, com outros utilizadores a terem permisso de acesso a diferentes tuplos, na mesma tabela, ao mesmo tempo. Mas, neste caso, tambm aumenta o overhead relacionado com a gesto de locks. , no entanto, responsabilidade do SQL Server determinar, automaticamente, qual o nvel de granularidade apropriado para cada tarefa (embora se possa indicar, explicitamente, qual o lock que se prefere usar, atravs do uso de hints). 6.2.2 Modos de lock
O modo do lock especica como um recurso sobe o qual o lock est aplicado, pode ser acedido por utilizadores/transaces concorrentes. Cada lock referido na seco anterior adquirido num dos seguintes modos: Shared Este modo adquirido automaticamente, quando se procede leitura de dados (e.g. comando SELECT). Shared locks permitem a consulta do mesmo recurso, por vrias transaces concorrentes, mas no permitem que este seja alterado. Normalmente, neste modo, os locks so libertados assim que os dados acabam de ser lidos, a no ser que o nvel de isolamento ou hints alterem este comportamento. Exclusive Exclusive locks so usados em operaes onde h alteraes de dados, devido utilizao dos comandos INSERT, DELETE ou UPDATE. Quando um exclusive lock aplicado a um recurso, nenhuma outra transaco pode l-lo ou modic-lo (na verdade possvel ler o recurso, sem bloquear o exclusive lock, usando hints ou nveis de isolao). Update Este modo usado quando o SQL Server executa uma operao de modicao de dados mas, primeiro, necessita de pesquisar a tabela para encontrar os recursos que iro ser modicados. Se a transaco realmente zer uma alterao (devido ao facto de terem sido encontrados tuplos que satisfazem a condio de pesquisa, por exemplo) o lock passa para o modo exclusive; caso contrrio, passa para o modo shared. Este modo importante para evitar deadlocks (situao abordada mais frente). Intent Intent locks so usados para qualicar os 3 modos j apresentados. Ou seja, pode-se ter intent shared locks, intent exclusive locks e intent update locks (a lista completa encontra-se 47
6.2. Locks
em baixo). O objectivo do intent lock proteger os locks de granularidade mais na, tais como row e page level, de locks exclusive de granularidade mais grosseira, de modo a que no sejam bloqueados de vir a ser utilizados por outras transaces. Por exemplo, um intent lock de granularidade table level adquirido por uma transaco, indica ao SQL Server a inteno dessa transaco em adquirir um recurso dessa mesma tabela (e.g. uma pgina ou tuplo da mesma). Se este intent lock for adquirido antes de outros locks de menor granularidade, prevenir-se- uma segunda transaco de adquirir um exclusive lock nessa tabela, o que poderia, potencialmente, bloquear a primeira transaco. Existem seis categorias de intent locks: Intent shared. Indica a inteno da transaco em ler recursos hierarquicamente inferiores, colocando shared locks nesses recursos. Intent exclusive. Indica a inteno da transaco em modicar recursos hierarquicamente inferiores, colocando exclusive locks nesses recursos. Shared com intent exclusive. Indicam a inteno da transaco em ler todos os recursos hierarquicamente inferiores e em modicar alguns desses recursos, usando intent exclusive locks nesses recursos individuais. Intent update. Indica a inteno da transaco em colocar update locks nos recursos hierarquicamente inferiores. Update com intent exclusive. Indicam a inteno da transaco em adquirir, e manter, simultaneamente, um shared e um intent update locks, sobre um mesmo recurso, numa transaco. Shared com intent update. Indicam a inteno da transaco em adquirir, e manter, simultaneamente, um update e um intent exclusive locks, sobre um mesmo recurso, numa transaco. Schema Existem duas categorias, neste modo: Schema stability. Neste modo, o lock bloqueado se uma query que v usar a mesma tabela ainda se encontre a ser compilada. (os outros locks no cam bloqueados perante esta situao). Schema modication. Neste modo, o lock bloqueado se a transaco for usar uma tabela cuja estrutura se encontre a ser alterada. 48
6.2. Locks
Bulk Update Este modo permite que mltiplas threads faam bulk copies de dados, concorrentemente, para a mesma tabela, impedindo outros processos que no estejam a realizar bulk copies de aceder tabela. Para entrar neste modo necessrio que a hint TABLOCK seja activada ou, opcionalmente, que se active este modo usando o procedimento sp_tableoption. Key-Range O modo key-range bloqueia os tuplos dos ndices, de modo a satisfazer os requisitos do nvel de isolamento serializable (descrito na subseco seguinte). Deste modo, com o bloqueio dos tuplos das chaves de pesquisa acedidas durante a transaco, garante-se que estas no sero apagadas ou alteradas, pelo que, durante toda a transaco ser possvel ler os mesmos dados. 6.2.3 Nveis de isolamento
Os nveis de isolamento permitem controlar o nvel de consistncia que se obtm ao manipular os dados, atravs do controlo do comportamento do gestor de locks do SQL Server para as operaes de leitura. De modo a alterar o nvel de isolamento, pode-se usar o comando SET TRANSACTION ISOLATION LEVEL com uma das seguintes opes: READ UNCOMMITTED. Nvel mais fraco de isolamento. Uma transaco pode ler as modicaes feitas por outras transaces, mesmo antes de estas serem committed, pelo que possvel ocorrerem dirty reads (corresponde s hints NOLOCK e READUNCOMMITTED). READ COMMITTED. Nvel por omisso do SQL Server. Alteraes feitas no interior de uma transaco usam exclusive locks, no podendo as modicaes ser vistas por outros processos, at que a transaco termine. As leituras so feitas com shared locks mas, aps o trmino da leitura, no h garantia que os recursos lidos sejam alterados por outros processos, pelo que podem ocorrer non-repeatable reads e phantom reads. REPEATABLE READ. Neste nvel, medida que os dados vo sendo lidos, locks vo sendo colocados (e mantidos) nos dados, durante toda a transaco. Assim, previnese que outras transaces modiquem os dados, no ocorrendo non-repeatable reads. No entanto, no se previne a adio de novos tuplos or "tuplos fantasmas", pois o lock apenas est aplicado sobre dados existentes. SERIALIZABLE. Nvel mais elevado de isolamento: as transaces encontram-se completamente isoladas umas das outras. Neste nvel igual correr as transaces em srie ou concorrentemente, uma vez que so aplicados locks sobre vrias chaves e estes so mantidos durante toda a durao da transaco. 49
6.3. Transaces de longa durao
SNAPSHOT. Isolamento Snapshot especica que os dados lidos por um comando devero apenas ver modicaes que j tenham sido committed antes do incio da transaco, ou seja, os comandos SQL "vem" snapshots dos dados committed, tal como existiam no incio da transaco. A opo ALLOW_SNAPSHOT_ISOLATION dever estar a ON. READ_COMMITTED_SNAPSHOT. Este nvel de isolamento semelhante ao nvel Snapshot, excepto que, ao invs de usar um snapshot do incio da transaco, usado um snapshot do incio de cada comando SQL. 6.2.4 Locking Hints Locking hints so keywords que podem ser usadas com os comandos SELECT, INSERT, UPDATE e DELETE, de modo a direccionarem o SQL a usar um tipo de locks preferido, numa determinada tabela (ou view), podendo se sobrepor a um nvel de isolamento. Os locking hints que existem no SQL Server 2005 so: HOLDLOCK, NOLOCK, PAGLOCK, READCOMMITTED, READCOMMITTEDLOCK, READPAST, READUNCOMMITTED, REPEATABLEREAD, ROWLOCK, SERIALIZABLE, TABLOCK, TABLOCKX, UPDLOCK e XLOCK. 6.2.5 Deadlocks Sem interveno, dois processos envolvidos num deadlock cariam, indenidamente, espera um do outro. No entanto, o SQL Server detecta, automaticamente, situaes de deadlock e resolve-as terminando o processo que considera menos dispendioso de fazer roll back, estimando a partir da quantidade de trabalho que j foi realizado pelo processo (este tambm recebe um erro 1205 que pode ser tratado pelo processo). Por defeito, o gestor de locks, de 5 em 5 segundos procura por situaes plausveis de ser deadlocks, variando este intervalo consoante a frequncia com que deadlocks aparecem. Como o nmero de deadlocks, em geral, pequeno, este sistema diminui a carga do sistema, na deteco de deadlocks. O utilizador tambm pode denir qual o processo a ser terminado, denindo os valores LOW, NORMAL (por omisso) ou HIGH para a opo DEADLOCK_PRIORITY.
6.3
Transaces de longa durao
Tal como j foi referido, os metadados referentes s transaces so guardados no transaction log. No entanto, se uma transaco for de muito longa durao, poder "entupir" o log, o que coloca a recuperabilidade da base de dados em risco. Uma soluo passa por fazer backup do log e truncar a parte da qual j se fez o backup. O SQL Server disponibiliza um comando que permite consultar e obter informao sobre a 50
6.3. Transaces de longa durao
transaco activa mais antiga no sistema: DBCC OPENTRAN. Este comando devolve o identicador do processo que iniciou a transaco, o identicador do utilizador, o nome da transaco, entre outras informaes. Deste modo possvel identicar qual a transaco que, potencialmente, poder causar problemas no futuro e termin-la, caso seja necessrio.
51
7
Suporte para bases de dados distribudas
O SQL Server tem um grande suporte para base de dados distribudas homogneas, disponibilizando funcionalidades como replicao, mirroring, log shipping, transaces distribudas e at suporte para replicao heterognea com sistemas de base de dados como o Microsoft Access, Oracle e IBM.
7.1 Replicao
Figure 7.1: Replicao 53
7. S UPORTE PARA BASES DE DADOS DISTRIBUDAS
7.1. Replicao
7.1.1
Funcionamento
O SQL Server utiliza um modelo de "Produtor - Distribuidor - Consumidor" para efectuar as replicaes 7.1. Para tal existem trs tipos de servidores, o Publisher, que ter o papel de produtor, o Subscriber, o consumidor, e o Distributor, que poder ser o mesmo servidor que o Publisher, e tem como funcionalidade guardar o histrico e metadata das replicaes. Antes de se criar as ligaes para a replicao necessrio denir no Publisher articles e posteriormente agrupa-los em publications. Articles so dados que podem ir desde tabelas inteiras, determinadas colunas ou tuplos, views, procedimentos ou at funes denidas pelo utilizador. Como foi indicado anteriormente, estes articles vo ser agrupados em publications, sendo estas o que ser, posteriormente, partilhado pelo Distributor. O Subscriber depois necessita de criar subscriptions, que iro manter informao sobre que publications ir replicar informao, onde ir receber e quando. O pedido de sincronizao entre os dois servidores pode ser feito pelo Subscriber, push subscrition, pelo Publisher, pull subscrition, ou pode ainda suportar as duas. 7.1.2 Tipos
Existem trs tipos de replicao no SQL Server: Merge: As alteraes que vo ocorrendo so guardadas pelo prprio servidor e quando o Subscriber conecta-se ao Publisher essas alteraes so partilhadas e aplicadas em ambos os servidores. Neste caso os servidores conseguem trabalhar de forma autnoma e pode car ofine. Recomendado para ambientes Servidor-Cliente. Snapshot: Neste tipo de replicao os servidores no registam as alteraes realizadas entre as sincronizaes. Quando h uma sincronizao o Publisher cria um snapshot de todas as publications subscritas e envia-o para o Subscriber. Transactional: Neste caso o SQL Server, no Publisher, monitoriza as todas as alteraes relevantes para os Subscribers e propaga-as quando ocorrem, quase em tempo real. O normal nesse tipo de replicao que as alteraes realizadas no Subscriber so tratadas como read-only para o Publisher, no entanto h opes que deixam alterar essa propriedade. Recomendado para ambientes Servidor-Servidor. Em todos os tipos enviado um snapshot global do Publisher para os Subscribers quando realizada a primeira sincronizao. 7.1.3 Agentes
Para que o processo de replicao se possa realizar( 7.1), o SQL Server dispes de pequenos programa, denominados agentes, que realizam tarefas como guardar o histrico das replicaes e copiar os dados entre os Publishers e os Subscribers. Os mais importantes so o Snapshot Agent, Log Reader Agent, Distribution Agent, Merge Agent e o Queue Reader Agent. 54
7.2. Mirroring
7.2
Mirroring
Figure 7.2: Mirroring
Mirroring uma soluo que o SQL Server disponibiliza que tem como intuito garantir aa disponibilidade de uma base de dados. Para tal, por cada base de dados, iro existir dois servidores (7.2). Um deles ir funcionar como principal, prestando servios aos clientes, e o outro ser uma cpia de segurana da base de dados. Quando o servidor principal falha, as aplicaes dos clientes conseguem recuperar rapidamente, necessitando apenas de conectar se ao outro servidor. Existem dois tipos de estado para o servidor secundrio:
"hot standby server": quando o servidor est sincronizado, onde no ocorrem perca de dados caso o servidor principal falhar.
"warm standby server": quando este no se encontra sincronizado e poder levar a perca de dados.
7.3
Log Shipping
55
7.4. Transaces Distribudas
Figure 7.3: log shiping Nesta soluo, tambm com o intuito de manter uma alta disponibilidade do sistema, o servidor principal ir realizar automaticamente cpias de segurana dos registos de transaces da sua base de dados. Estas cpias de segurana iro ser posteriormente copiadas para outros servidores e aplicadas nas bases de dados secundrias. Opcionalmente poder existir um terceiro tipo de servidor, o monitor, que mantm o estado e histrico de todos os servidores e se houver alguma falha lanam um alerta (7.3)). Ao contrrio da soluo anterior, nesta as aplicaes, no caso de falha do servidor, no tentam conectar-se automaticamente a um servidor secundrio. Para que o sistema volte a funcionar os servidores secundrios tem de ser disponibilizados online manualmente.
7.4
Transaces Distribudas
O SQL Sever tambm permite a realizao de transaces distribudas. Para que estas transaces possam ocorrer necessrio que o gestor de transaces de cada servidor tenha suporte para o Microsoft Distributed Transaction Coordinator ou Open Group XA. Para garantir a atomicidade das transaces utilizado o protocolo 2-phase commit.
7.5
Acesso a outras Bases de Dados
Como j referido, o SQL Server permite replicao de base de dados heterognea, no entanto replicao por merge no possvel. O sistema de base de dados com maior suporte o Oracle, neste possvel denir Publishers e Subscribers. 56
7.6. Federao
Para os restantes sistema s h suporte para Subscribers. Para que a funcionalidade de Publisher funcione num servidor Oracle necessrio que se crie um utilizador com privilgios de administrador de sistema; garantir privilgios de SELECT, de todas as tabelas que iro ser publicadas, ao utilizador previamente criado; instalar a aplicao de cliente do Oracle e o OLE DB provider no servidor onde se encontra o Distributor e nalmente congurar a base de dados Oracle como Publisher no Distributor. Para o caso Subscribers qualquer sistema de base de dados com suporte para OBDC ou OLE DB consegue subscrever, no entanto tem de usar push subscriptions.
7.6
Federao
O SQL Server permite estabelecer base de dados federadas. Este tipo de base de dados consiste na fragmentao dos dados, neste caso por particionamento vertical, e dispers-los por diversos servidores. Todo esse processo transparente para os clientes. Esta aco ira levar a uma reduo carga de processamento por servidor e a aumento de rendimento do sistema em geral.
57
8
Outras caractersticas do sistema estudado
O Microsoft SQL Server 2005 tem suporte nativo para XML, nos fornecido o tipo de dados XML e com este podemos guardar documentos XML, ou s partes deste. Durante a realizao da query SELECT podemos indicar se desejamos que o resultado esteja no formato XML e ainda h suporte para um conjunto de funes da XQuery, usadas para realizar queries sobre dados XML. Tambm disponibilizam Native XML Web Services utilizando tecnologias como http, SOAP e Web Services Denition Language. Atravs de mensagens SOAP enviadas via HTTP podemos pedir que um servidor de SQL Server corra um script T-SQL ou mesmo correr procedimentos.
59
Bibliography
[1] MSDN, aspx. http://msdn.microsoft.com/en-us/sqlserver/default.
[2] Kalen Delaney. Inside Microsoft SQL Server 2005: The Storage Engine. Microsoft Pres, 2006. [3] Kalen Delaney. Inside Microsoft SQL Server 2005: Query Tuning and Optimization. Microsoft Pres, 2007. [4] Ken England and Gavinl Powell. Microsoft SQL Server 2005 Performance Optimization and Tuning Handbook. Digital, 2007. [5] Darril Gibson. MCITP SQL Server 2005 Database Developer All-in-One Exam Guide (Exams 70-431, 70-441 & 70-442). McGraw-Hill, Inc., New York, NY, USA, 2008. [6] David Gornshtein and Boris Tamarkin. Features, strengths and weaknesses comparison between MS SQL 2005 (Yukon) and Oracle 10g databases. WisdomForce Technologies, Inc, 2004. http://www.wisdomforce.com. [7] Ross Mistry, Chris Amaris, and Alec Minty. Microsoftsql server 2005 management and administration. Sams, Indianapolis, IN, USA, 2007. [8] Ray Rankins, Paul Bertucci, Chris Gallelli, and Alex T. Silverstein. Microsoft(R) SQL Server 2005 Unleashed. Sams, Indianapolis, IN, USA, 2006. [9] Jeffrey R. Shapiro. Microsoft SQL Server 2005: The Complete Reference. McGrawHill,Osborne, 2007. [10] Edward Whalen, Marcilina Garcia, Burzin Patel, Stacia Misner, and Victor Isakov. Microsoft SQL Server 2005 administrators companion. Microsoft Press, Redmond, WA, USA, 2006. 61

Ms SQL Server

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ms SQL Server

Uploaded by

Copyright:

Available Formats

Sistemas de Bases de Dados

Faculdade de Cincias e Tecnologia

Anlise de um Sistema de Gesto de Bases de Dados:

Microsoft SQL Server 2005

Trabalho realizado por:

5.4 5.5 5.6

1.1 Introduo histrica

1.2. Notas sobre instalao do sistema

Notas sobre instalao do sistema

2.3. Tipos de Dados

2.3. Tipos de Dados

3. A RMAZENAMENTO E FILE STRUCTURE

3.2. Acesso s pginas em memria

Acesso s pginas em memria

Gesto de pginas na cache de dados

3. A RMAZENAMENTO E FILE STRUCTURE

3.4. Arquitectura NUMA

3. A RMAZENAMENTO E FILE STRUCTURE

3.6. Sistema de cheiros

3.7 Pginas e Extents

3. A RMAZENAMENTO E FILE STRUCTURE

3.8. Organizao dos cheiros

Organizao dos cheiros

3.9 Mecanismo de parties

3. A RMAZENAMENTO E FILE STRUCTURE

3.9. Mecanismo de parties

3. A RMAZENAMENTO E FILE STRUCTURE

3.9. Mecanismo de parties

4.1 Estrutura B-tree

4.1. Estrutura B-tree

4.1. Estrutura B-tree

4.2. Tipos de ndices

4.2. Tipos de ndices

Aquelas que so normalmente alvo de um acesso sequencial.

Aquelas que contm um nmero elevado de valores distintos

4.2. Tipos de ndices

Figure 4.4: ndice non clustered

4.3. Implementao de ndices

4.4. Criao de ndices

Figure 4.5: Sintaxe do comando CREATE INDEX

3 http://www.simple-talk.com/sql/learn-sql-server/understanding-full-text-indexing-in-sql-server/ 4 http://www.linfo.org/wildcard.html 5 http://www.w3schools.com/xquery/

4.4. Criao de ndices

ASC | DESC INCLUDE (column [ ,... n]) relational_index_option

Opes do comando CREATE INDEX

4.4. Criao de ndices

4.5. Indexao e Hashing - Oracle 10g vs MS SQL 2005

Indexao e Hashing - Oracle 10g vs MS SQL 2005

5. P ROCESSAMENTO E O PTIMIZAO DE Queries

5.1. Algoritmos para Junes

5.1 Algoritmos para Junes

5. P ROCESSAMENTO E O PTIMIZAO DE Queries

5.1. Algoritmos para Junes

Figure 5.1: Plano com um nested loop

5. P ROCESSAMENTO E O PTIMIZAO DE Queries

5.1. Algoritmos para Junes

Figure 5.2: Plano com um merge join

5. P ROCESSAMENTO E O PTIMIZAO DE Queries

5.1. Algoritmos para Junes

Figure 5.3: Plano com um hash join

5. P ROCESSAMENTO E O PTIMIZAO DE Queries

5.2. Escolha de ndices e avaliao de sub consultas

Escolha de ndices e avaliao de sub consultas

A optimizao de consultas do Microsoft Sql Server 2005 envolve trs fases: 34

5. P ROCESSAMENTO E O PTIMIZAO DE Queries