1. Introdução Uma breve síntese histórica do SQL Server Instalação do SQL Server Cobertura do SQL...

Transcrição

1

2 Índice 1. Introdução Uma breve síntese histórica do SQL Server Instalação do SQL Server Cobertura do SQL Data definition language (DDL) Data manipulation language (DML) Data control language (DCL) Outras diferenças Tipos Outros tipos: Armazenamento e file structure Sistema de ficheiros Ficheiros Snapshots da base de dados Páginas e extensões Gestão das extensões Gestão do espaço livre Gestão do espaço por objectos Partições Memória e Buffer management Arquitectura da memória Espaços de endereçamento do processo Gestão da memória dinâmica Gestão do Buffer Operações de leitura Operações de escrita Indexação e hashing Tipos de índices Índice Clustered... 38

3 4.1.2 Índice Nonclustered Índice Unique Index with included columns Indexed views Índice de Full-text Indexação Spatial Índice Filtered Índices XML Sintaxe de criação de índices Organização de tabela e índice Organização da tabela Partições Tabelas de Índice Particionadas Índices Uniques particionados Tabelas, heaps e índices Clustereds Processamento e optimização de perguntas Custos Selecção Query Hints Table Hints Algoritmos de junção Hash Join Merge Join Nested Loop Join Remote Join Ordenação Optimização de consultas Execution Plan Caching Reutilização de Execution Plans Indexed Views Pipelining... 71

4 5.8 Visualização de Planos de execução Gestão de transacções e controlo de concorrência Controlo de transacções Explicit Transactions Autocommit Transactions Implicit Transactions Batch-scoped Transactions Savepoints Nesting Transactions Suporte para transacções de longa duração Mecanismos para garantia isolamento Protocolos com locks Gestão de Deadlocks Níveis de Granularidade Dynamic Locking Tipos de Locks Transact-SQL Locking Hints Níveis de Isolamento Consistência Mecanismos de Recuperação Suporte para bases de dados distribuídas Transacções distribuídas Replicação de dados Editores, distribuidores e assinantes Publicações e artigos Subscrições Tipos de replicação Modelos de Replicação Federação de bases de dados Outras características! Suporte para tecnologia XML... 98

5 8.2 Suporte de Triggers Segurança no SQL Server Criptografia Autenticação Auditoria de segurança Segurança de FILESTREAM Gestão com base em políticas Conclusão Bibliografia:

6 1. Introdução Este trabalho foi desenvolvido no âmbito da disciplina de Sistemas de Base de Dados, o qual consiste na análise aprofundada do Sistema de Gestão de Base de Dados SQL Server 2008, à luz da matéria ministrada na cadeira. Este documento está dividido em oito capítulos. O primeiro e o segundo são apresentados de forma resumida pois são apenas enquadram os restantes capítulos. O primeiro capítulo é composto por uma introdução ao trabalho, uma breve resenha histórica acerca do SQL Sever, e algumas pequenas considerações acerca da instalação do SQL Server. No segundo capítulo, faz-se uma breve apresentação da cobertura que o sistema se base de dados SQL Server faz do standard do SQL e apresenta-se algumas diferenças e acréscimos que o SQL Server faz do standard. O terceiro capítulo é dedicado ao armazenamento da informação e ao seu sistema de ficheiros, mecanismo de partições, organização e gestão de memória e dos buffers. No quarto capitulo, detalha-se os diversos índices utilizados pelo SQL Server para indexar a informação da Base de Dados como forma de optimizar as consultas. São ainda, apresentados as estruturas de dados em que esses índices estão organizados e os comandos necessários para a criação dos mesmos por parte dos utilizadores. O quinto capítulo, refere-se ao processamento e optimização de perguntas. Neste capítulo explica-se como são efectuadas as diversas operações básicas (Junção, Selecção, Ordenação), apresentam-se os diversos algoritmos implementados pelo sistema, bem como, o plano optimizador de planos de pesquisa. O sexto capítulo deste trabalho, é reservado à gestão de transacções e ao controlo de concorrência. Neste capítulo, são discutidos os vários protocolos implementados pelo sistema para garantir isolamento das diversas operações, a forma como os sistemas lida com os deadlocks do sistema de locks. São apresentados os diversos níveis de isolamento garantidos e os níveis de granularidade, para além dos mecanismos de rollback e recuperação de dados utilizados pelo sistema. O capítulo sétimo, descreve a organização e funcionamento de bases de dados em bases de dados distribuídas. Detalha-se o funcionamento das transacções distribuídas e da organização dos participantes na replicação, o seu funcionamento e aborda-se o esquema de federação de base de dados. O oitavo e último capítulo, apresenta algumas propriedades e ferramentas do SQL Server, não abordadas nos capítulos anteriores. As matérias abordadas são nomeadamente: a possibilidade de armazenamento de informação de XML nativo, os diversos tipos de triggers implementados e uma breve visão da segurança existente no SQL Server 2008.

7 1.1 Uma breve síntese histórica do SQL Server Não se pode falar na história do SQL Server 2008, sem se falar do sistema Sybase SQL Server. A estratégia da Microsoft para entrar nos sistemas de base de dados, passou por uma parceria com a Sybase, em que o código do Sybase SQL server foi a base para o desenvolvimento do MS SQL Server. A entrada da Microsoft neste mercado não foi fácil dado que teve lutar com o império da Oracle e IBM. Entretanto, em 1989, surgiu uma aliança entre Microsoft, Sybase e a Ashton-Tate para criar e comercializarem um novo produto designado por SQL Server 1.0 para a plataforma OS/2. Durante os anos 90 a Microsoft iniciou o desenvolvimento de uma versão para a plataforma NT. Enquanto o SQL Server estava a ser desenvolvido a Microsoft decidiu que ele deveria ser uma camada encapsulada sobre o sistema operacional NT. Em 1992, o Windows NT 3.1 e o SQL Server 4.2 para NT foram lançados. A filosofia da Microsoft em combinar base de dados de alta performance com uma interface fácil de usar mostrou-se um sucesso. Microsoft rapidamente tornou-se um dos mais populares vendedores de Sistemas de Base de Dados relacionais. Depois de alguns desentendimentos, em 1994, a Microsoft e a Sybase formalmente terminaram sua parceria. Em 1995 a Microsoft lançou a versão 6.0 do SQL Server. O seu desenvolvimento requereu uma das maiores reescritas da tecnologia SQL Server até então requeridas. A versão 6.0 aumentou substancialmente a performance oferecendo mecanismos internos de replicação e administração centralizada. Em 1996 a Microsoft lançou a versão 6.5 do SQL Server. Essa versão trouxe melhoras significativas para a tecnologia e disponibilizou diversas novas funcionalidades. No ano seguinte a Microsoft lançou a versão Enterprise do SQL 6.5. Em 1998 a Microsoft lançou a versão 7 do SQL Server, no qual e pelo que se conhece da históriad este produto, foi completamente rescrito, fazendo uma cisão com o código base que vinha desde o Sybase. Em 2000 a Microsoft lançou o SQL Server O SQL Server 2000 é o lançamento mais importante do SQL Server até o momento. Essa versão foi construída sobre o framework do SQL Server 7.0. De acordo com a equipa de desenvolvimento do SQL Server essas mudanças foram desenvolvidas para tornar essa tecnologia actual 10 anos seguintes. Em 2003, o SQL Server 2000 foi lançado numa variante para a arquitectura IA-64. Em 2005, é lançado o SQL Server 2005 (com a designação Yukon) com grande integração na plataforma.net. Com, este produto a Microsoft dá mais um passo em direcção às grandes plataformas corporativas. Passados dois anos, a Microsoft divulga na feira mundial de Business Intelligence o lançamento do SQL Server 2008 previsto para A versão actual do SQL Server, SQL Server 2008 (nome de código Katmai) foi lançada em 6 de Agosto de 2008.

8 O principal slogan da Microsoft para comercializar o SQL Server 2008, é "ir um pouco além do relacional". O SQL Server 2008 tem como objectivo tornar os dados de gestão auto-tuning, auto-organizados e manter o desenvolvimento do SQL Server Always On Technologies, para fornecer quase zero downtime. O SQL Server 2008 inclui suporte para dados estruturados e semi-estruturados, incluindo os formatos de mídia digital de imagens, áudio, vídeo e outros dados multimédia. 1.2 Instalação do SQL Server Para uma melhor análise da informação obtida de diversas fontes, foram instaladas para execução dos testes as seguintes versões do SQL Server 2008: SQL Server 2008 Express SQL Server Management Studio Relativamente à instalação do SQL Server 2008, embora se tenha revelado muito fácil (nas versões acima referidas), existem no entanto, diversas recomendações e indicações para cada uma das muitas versões em que o produto está disponível, que pôde facilmente ser consultados através do seguinte link:

9 2. Cobertura do SQL Neste capítulo iremos abordar a cobertura que o SQL Server faz do standard do SQL, as suas diferenças e algumas operações que vão mais além do que é requerido pelo standard SQL. 2.1 Data definition language (DDL) OPERAÇÔES CREATE O SQL:2008 permite agora criar tabelas a partir de cláusula LIKE: CREATE TABLE t2 ( LIKE t1 ) O T-SQL não permite mas pode utilizar-se : SELECT... INTO... FROM... Ex: SELECT * INTO t2 FROM t1 WHERE 1<>1 Onde t1 pode ser uma vista ou tabela. Copia todos os valores não nulos. DROP Implementa tudo. ALTER Implementa tudo. Referential integrity Implementa tudo 2.2 Data manipulation language (DML) OPERAÇÔES SELECT INTO INSERT UPDATE DELETE Implementa tudo. Implementa tudo. Implementa tudo. Implementa tudo. 2.3 Data control language (DCL) OPERAÇÔES GRANT REVOKE Implementa tudo. Implementa tudo.

10 2.4 Outras diferenças Junções Join type/feature Natural joins (only tested: NATURAL LEFT JOIN) USING-clause FULL joins 1 (tested: SELECT...FULL JOIN...ON...=...) Explicit CROSS JOIN (cartesian product) T-SQL Vistas Standard As vistas fazem parte do standard e podem ser actualizadas MSSQL SQL:2008 permite vistas de junções de mais tabelas e permite actualizações desde que as actualizações não permitam dados ambíguos. SQL-92 mais restritiva pois só permite que a vista só se refira a uma tabela. Conforme SQL-92. Ordenações de resultados resultantes do SELECT Standard O SQL:2008 define que os resultados resultantes do SELECT não são ordenados mas que podem ser ordenados quando utilizados os cursores: DECLARE cursorname CURSOR FOR SELECT... FROM... WHERE... ORDER BY column_name1,column_name2,... Podendo-se adicionar a clausula ORDER BY. O SQL:2008 não indica qual a ordenação entre os valores nulos e não nulos, excepto que dois nulos são considerados iguais. T-SQL No T-SQL permite utiliza o ORDER BY com o mesmo e outros contextos mas os valores nulos são considerados mais baixos que os valores não nulos.

11 Limite de número de linhas: Standard O SQL standard fornece 3 formas de usar limites: Usando FETCH FIRST:(desde o SQL:2008) SELECT... FROM... WHERE... ORDER BY... FETCH FIRST n ROWS ONLY Usando uma ROW_NUMBER():(desde o SQL:2003) SELECT * FROM ( SELECT ROW_NUMBER() OVER (ORDER BY key ASC) AS rownumber, columns FROM tablename ) AS foo WHERE rownumber <= n Utilizando cursor. DECLARE cursor-name CURSOR FOR... OPEN cursor-name FETCH... CLOSE cursor-name T-SQL Suporta o ROW_NUMBER()(desde o MSSQL 2005) e uma aproximação dos cursores. Não suporta o FETCH FIRST. Funções do SQL: CHARACTER_LENGTH SQL:2008 T-SQL CHARACTER_LENGTH(argument) CHARACTER_LENGTH(argument USING string-unit) string-unit may be UTF8, UTF16, UTF32. Returns NUMERIC. Returns NULL if the input is NULL. Alias: CHAR_LENGTH. The argument may be of type CHAR or VARCHAR. Não possui CHARACTER_LENGTH mas fornece a função LEN e DATALENGTH (esta válida para TEXT). Não faz leitura de espaços dos CHAR. Funções do SQL: SUBSTRING Standard T-SQL Define duas variantes da função: SUBSTRING(input FROM start-position [FOR length]) SUBSTRING(input SIMILAR pattern ESCAPE escape-char) Possui uma mas tem uma sintaxe diferente: SUBSTRING(input, start, length) Não possui expressões regulares

12 Funções do SQL: TRIM Standard T-SQL TRIM(where characters FROM string_to_be_trimmed) Trim de NULL retorna NULL. Não suporta. Fornece: LTRIM(string_to_be_trimmed) e RTRIM(string_to_be_trimmed) Funções do SQL: LOCAL TIMESTAMP Standard O tempo corrente pode ser obtido pela função LOCALTIMESTAMP usada da seguinte forma: SELECT LOCALTIMESTAMP... ou SELECT LOCALTIMESTAMP(precision)... Caso não suporte timezone deve fornecer as funções CURRENT_TIMESTAMP e CURRENT_TIMESTAMP(precision) que retornam valores do tipo TIMESTAMP WITH TIME ZONE. Caso não suporte zone não deve fornecer a função CURRENT_TIMESTAMP. T-SQL Não possui a função LOCALTIMESTAMP. Possui a função CURRENT_TIMESTAMP mas não retorna TIMESTAMP WITH TIME ZONE mas sim um valor do tipo DATETIME. Funções do SQL: Concatenation Standard Concatenar duas strings com o operador : string1 string2 Caso um dos operandos seja NULL o resultado é NULL. T-SQL Utiliza '+' em vez de ' '. Não faz o cast dos operadores para tipos compatíveis. Caso um operando seja NULL o resultado é NULL.

13 2.5 Tipos Tipos númericos decimais. Tipos de dados que armazenam informação para uso de calculo matemático. Poderão ser tipos inteiros e

14 Date e time Tipos de dados que armazenam informação relativa ao tempo ou data. Relativamente ao MSS2005 foram introduzidos 4 novos tipos: DATE, TIME, DATETIMEOFFSET, DATETIME2. O tipo TIMESTAMPS não possui nenhuma informação relativa ao tempo e data actual. Refere-se apenas a uma marca temporal obtida internamente para especificar o momento temporal que poderá ser utilizado para efectuar comparações.

15 Character string Tipos de dados que armazenam texto nas bases de dados do tipo Character e String. Binary Tipos de dados que armazenam qualquer tipo de dados representado em binário. O MSSQL2008 suporta o tipo image mas este será descontinuado em futuras versões. 2.6 Outros tipos: O MSSQL2008 oferece um novo conjunto de tipos de dados sendo alguns deles extensões às existentes. O tipo de dados XML foi melhorado e já é possível armazenar tipos de dados Binary Larg Objects (BLOBs) como ficheiros no

16 file system. Foram introduzidos novos tipos de dados como HIERARCHYID para manipular dados organizados de forma hierárquica, e um tipo de dados para representação geométrica e espacial. Foi também incluído um tipo de dados FILESTREAM que permite colocar blocos de dados no file system. HIERARCHYID Este tipo de dados permite armazenar dados que possuem uma estrutura hierárquica. Anteriormente era necessário criar o tipo manualmente conforme a necessidade do utilizador, denominados como user-definedtype(udt) e depois activar nas configurações da Common Language Runtime(CLR). Aproveitando o facto de ser um based-type da CLR, incorporaram o tipo HIERARCHYID nas SQLTypes library e retiraram a dependência de activação das configurações da CLR. Permite operações sobre estruturas hierárquicas como por exemplo: GetAncestor(), GetDescendant(), Read() e Write(). FILESTREAM O tipo de dados FILESTREAM faz a integração da informação da database engine com o sistema de ficheiros. Existiam duas soluções para processar e armazenar os dados do actual tipo BLOB. A primeira consiste em gravar os dados no tipo VARBINARY(MAX) o que dá um maior controlo à engine do MSSQL2008, de forma mais segura, garantindo a integridade sendo incluída em backups e restores. A outra forma é armazenar directamente no sistema de ficheiros reduzindo o esforço da engine do SQL Server e permitindo armazenar os dados em diferentes localizações. O FILESTREAM é um sistema híbrido destes dois processos permitindo que os dados sejam armazenados num sistema de ficheiros diferente da localização da database mas permitindo efectuar operações directas sobre os dados através de chamadas ao sistema de ficheiros pela library pela Win32 API. Garante as propriedades ACID, permite pesquisas, backups e restores, operações de consistência e replicação. A escolha neste tipo de dados dependerá do tamanho do ficheiro, da prioridade e rapidez de acesso ou do tipo de arquitectura. Dados espaciais Uma nova funcionalidade no MSSQL2008 é poder utilizar-se métricas como localização, distância e a noção de espaço, podendo-se obter a representação de posições e estruturas geométricas. Este tipo de parametrizações permite tratar dados resultantes de Cartografia, o Global Positioning System (GPS) e sistemas inovadores que integram detalhes do mundo físico. Existem dois tipos de dados que podem efectuar a representação espacial considerando plano 2D ou 3D sendo eles, o tipo de dados GEOMETRY e o GEOGRAPHY. Dentro do tipo GEOMETRY ainda existem um conjunto de subtipos:

17 Os tipos de dados GEOGRAPHY resultam da necessidade de representar informação geográfica nas bases de dados. Para uma maior precisão é foi necessário considerar a curvatura da Terra, para obtenção de distâncias entre dois pontos. Diferencia-se do anterior tipo de dados pois os anteriores são considerados em superfícies planas. Tipo de dados XML O MSSQL2005 introduziu o tipo XML como tipo de primeira classe, agora o MSSQL2008 vem melhorar as capacidades de validações de schema e do XQuery. No schema validation foram introduzidas novas funcionalidades nomeadamente nas lax validation, lists and unions e date e time data. No XQuery foram introduzidas novas funções, afectação de variáveis e enhanced relational data binding. User-Defined Table Types É possível que o MSSQL2008 não ofereça todos os tipos de dados necessários para todos os utilizadores, no entanto oferece a possibilidade de os criar. Para tal os utilizadores podem declarar os tipos que necessitam, um a um ou então pode inscrever os tipos que necessita na user-defined table dando liberdade de utilização de diferentes tipos que necessite adaptar à sua base de dados.

18 3. Armazenamento e file structure 3.1 Sistema de ficheiros O SQL Server mapeia as bases de dados em ficheiros do sistema operativo. Existindo 3 tipos de ficheiros: Ficheiros de dados primários: São ficheiros que possuem apontadores para outros ficheiros na base de dados. A sua extensão é.mdf. Ficheiros de dados secundários: São ficheiros que contem todos os dados. A extensão é.ndf. Ficheiros de log: São ficheiros que mantêm todas as informações de log usadas para registar as operações da base de dados e que poderão ser usados em auditorias ou na recuperação de falhas. Deverá existir um por cada base de dados e poderá mesmo haver mais do que um ficheiro de log. A sua extensão é.ldf. Existe uma base de dados principal que regista todas as informações do nível do sistema operativo para o sistema do SQL Server. Além de outras tarefas acometidas a esta base de dados principal, tem a responsabilidade de registar todas as bases de dados e ficheiros associados a elas e as suas localizações bem como os dados de inicialização. Cada ficheiro do SQL Server tem dois nomes: logical_file_name: nome utilizado para executar as instruções Transact-SQL. Deve estar de acordo com as regras de identificadores SQL Server e deve ser exclusivo. os_file_name: nome do ficheiro no sistema de ficheiros e inclui a path. Cada ficheiro é constituído por um conjunto de páginas, que falaremos mais adiante, numeradas de 0 a n. Como cada ficheiro tem um ID exclusivo, associando a cada número de página obtém-se IDs exclusivos para cada página. Poderá ver a representação na figura 3.1. A primeira página de cada ficheiro é uma página de cabeçalho que contém informações sobre os atributos do ficheiro. Várias outras páginas do início do ficheiro também têm informações de sistema, como mapas de afectação. Uma das páginas de sistema armazenada no ficheiro de dados Figura 3.1 Ficheiro de dados primário de 4 MB e um ficheiro de dados secundário de 1 MB.

19 primário e no primeiro arquivo de log é uma página de inicialização da base de dados que contém informações sobre os atributos. Por uma questão de eficiência de administração os ficheiros de dados podem ser parametrizáveis quanto ao seu tamanho e à forma como crescem. Com o mesmo fim, podem existir grupos de ficheiros primários e grupos de ficheiros definidos pelos utilizadores. Os primeiros destinam-se a agrupar ficheiros de dados primários e todas as páginas são afectadas a esse grupo. Os segundos são definidos pelo utilizador através das instruções CREATE DATABASE ou ALTER DATABASE associada à tag FILEGROUP. Cada ficheiro só poderá pertencer apenas a um grupo de ficheiros e os dados de maiores dimensões, índices e objectos, são associados a cada grupo e podem ser particionados em diferentes grupos. Acerca de partições falaremos mais adiante, mas neste caso ocorrem partições horizontais que podem ser distribuídas por vários grupos de ficheiros Os ficheiros de log são geridos separadamente dos ficheiros de dados. Eis um exemplo para criar uma instância do SQL Server com ficheiro primário, grupo de ficheiros definidos pelo utilizador e ficheiro de logs. USE master; GO -- Create the database with the default data -- filegroup and a log file. Specify the -- growth increment and the max size for the -- primary data file. CREATE DATABASE MyDB ON PRIMARY ( NAME='MyDB_Primary', FILENAME= 'c:\...\mydb_prm.mdf', SIZE=4MB, MAXSIZE=10MB, FILEGROWTH=1MB), FILEGROUP MyDB_FG1 ( NAME = 'MyDB_FG1_Dat1', FILENAME = 'c:\...\mydb_fg1_1.ndf', SIZE = 1MB, MAXSIZE=10MB, FILEGROWTH=1MB), ( NAME = 'MyDB_FG1_Dat2', FILENAME = 'c:\...\mydb_fg1_2.ndf', SIZE = 1MB, MAXSIZE=10MB, FILEGROWTH=1MB) LOG ON ( NAME='MyDB_log', FILENAME = 'c:\...\mydb.ldf', SIZE=1MB, MAXSIZE=10MB, FILEGROWTH=1MB); GO ALTER DATABASE MyDB MODIFY FILEGROUP MyDB_FG1 DEFAULT; GO

20 -- Create a table in the user-defined filegroup. USE MyDB; CREATE TABLE MyTable ( cola int PRIMARY KEY, colb char(8) ) ON MyDB_FG1; GO O resultado final será o da figura 3.2. Figura Disposição visual dos sistemas de ficheiros Ficheiros Snapshots da base de dados Estes ficheiros podem ser criados pelo sistema ou pelos utilizadores. Quando criados pelos utilizadores eles armazenam os dados em um ou mais ficheiros esparsos aproveitando-se dos recursos do sistema de ficheiros NTFS. Quando gerados pelo sistema, são resultado de primitivas do sistema SQL Server e permitem efectuar operações internas sem que afecte o tamanho do ficheiro ou dados estatísticos. As snapshots não são mais que cópias de ficheiros originais, somente de leitura e que mantém as mesmas propriedades dos ficheiros originais. Servem para geração de relatórios, para fazer operações e reverter em caso de erro, como meio secundário para não sobrecarregar o principal, para protecção de erros administrativos e dos utilizadores e Figura 3.3- File snapshots.

21 para salvaguarda de dados em actualizações massivas. O funcionamento é simples e funciona ao nível da página. Antes de uma página original ser alterada pela primeira vez, esta é copiada para um outro ficheiro esparso conforme se pode observar na figura. O tamanho do ficheiro vai aumentando conforme o número de páginas forem copiadas. As operações sobre a base de dados correrão no ficheiro original. Como se poderá imaginar, existirá efeitos sobre o desempenho da base de dados na utilização deste tipo de mecanismos pois no limite o tamanho do snapshot será igual ao tamanho do ficheiro original caso haja alterações sobre todos os dados e caso contrário o tamanho do snapshots não é um factor importante. Quando o disco começa a ficar cheio é feita uma gestão criteriosos dos snapshots e quando atinge o limite ocorrem erros de escrita sobre os ficheiros snapshots. É necessário então reconhecer os padrões das operações da base de dados e parametrizar o tempo de actualização bem como prever o espaço necessário para garantir o correcto funcionamento da base de dados. Figura Desempenho dos snapshots sobre a base de dados Páginas e extensões A unidade fundamental de armazenamento de dados no SQL Server é a página. O espaço em disco destinado a ficheiros de dados (.mdf ou.ndf) é dividido em páginas numeradas de forma contígua de 0 a n. Cada página tem o tamanho de 8Kb tendo num total de 128 páginas por cada megabyte. As operações de E/S de disco são executadas ao nível da página ou seja, o SQL Server lê ou grava páginas de dados completas. Cada página tem um cabeçalho de 96 bytes que é usado para armazenar informações de sistema, tal como o número da página, o tipo, a quantidade de espaço livre e o ID da unidade de afectação do objecto que possui a página. A figura 3.5 mostra os diferentes tipos de página. Tipo de página Conteúdo Dados Linhas de dados com todos os dados, excepto dados text, ntext, image, nvarchar (max), varchar (max), varbinary(max) e xml, quando o texto na linha é definido como ON. Índice Entradas de índice Texto/Imagem Tipos de dados de objecto grande: Dados text, ntext, image, nvarchar(max), varchar(max), varbinary(max) e xml. Colunas de comprimento variável quando a linha de dados excede 8 KB: varchar, nvarchar, varbinary e sql_variant.

22 Global Allocation Map, Shared Global Allocation Map Page Free Space Index Allocation Map Informações sobre afectações de extensões. Informações sobre afectações de página e espaço livre disponível em páginas. Informações sobre extensões usadas por uma tabela ou índice por unidade de afectação. Bulk Map Changed Informações sobre extensões modificadas pelas operações em massa desde a última instrução BACKUP LOG por unidade de alocação. Differential Informações sobre extensões modificadas desde a última instrução BACKUP Changed Map DATABASE por unidade de alocação. Figura Tipos de página Os dados estão imediatamente a seguir ao cabeçalho dispostos em série conforme se pode observar na figura 3.6. No final da página existe uma tabela de deslocamento de cada linha em ordem inversa, onde cada entrada corresponde à distancia em bytes do inicio da página. Figura Organização da página Caso uma tabela ultrapasse o limite de uma página e consequentemente a linha tenha mais que 8Kb de dados, o SQL Server de forma dinâmica move uma ou mais colunas de comprimento variável para páginas da unidade de alocação ROW_OVERFLOW_DATA, iniciando com a coluna de maior largura. Na página original, ficará um apontador de 24 bytes na unidade de alocação IN_ROW_DATA. Caso operações posteriores reduzam o tamanho o SQLServer deslocará os dados para a página original. As extensões são um conjunto de oito páginas fisicamente contíguas e são usadas para obter maior eficiência na gestão de páginas. Assim cada extensão corresponde a 64Kb num total de 16 extensões por megabyte. Para obter uma melhor eficiência na afectação do espaço aos dados, o SQL Server dispõe de dois tipos de extensões (fig. 3.6): Extensões uniformes que pertencem a um único objecto, onde todas as oito páginas na extensão podem ser usadas apenas por esse objecto. Extensões mistas partilhadas por vários objectos (no máximo 8). Cada uma das oito páginas da extensão pode pertencer a um objecto diferente.

23 Figura 3.7 Organização das extensões. Geralmente as tabelas são afectadas a extensões mistas e quando a sua capacidade atinge as 8 páginas são afectadas por extensões uniformes Gestão das extensões A gestão das extensões é feita através de dois tipos de mapas: Global Allocation Map (GAM): As páginas GAM registam quais extensões foram afectadas. Cada GAM cobre extensões ou quase 4 GB de dados. O GAM tem um bit para cada extensão e se o bit for 1, a extensão está livre e se o bit for 0 a extensão está afectada. Shared Global Allocation Map (SGAM): As páginas SGAM registam as extensões que estão a ser utilizadas como extensões mistas e também têm pelo menos uma página não usada. Cada SGAM cobre extensões ou quase 4 GB de dados. A SGAM tem um bit para cada extensão no intervalo que abrange e se o bit for 1, a extensão será usada como uma extensão mista e terá uma página livre. Se o bit for 0, a extensão não será usada como uma extensão mista, ou será uma extensão mista e todas as suas páginas estão preenchidas. actual: Cada extensão tem os padrões de bit a seguir configurados no GAM e no SGAM, com base em seu estado Uso actual da extensão Configuração de bit GAM Configuração de bit SGAM Livre, não está a ser usada 1 0 Extensão uniforme ou extensão mista completa 0 0 Extensão mista com páginas livres 0 1 Figura 3.7 Padrões dos bits no GAM e SGAM

24 Através deste mapeamento, quando é necessário afectar uma extensão uniforme basta pesquisar na tabela GAM por bits a 1 e transforma-los em 0 e nas extensões mistas utilizando as SGAM basta pesquisar por bits a 0 e afecta-los com o valor 1. Para as operações de desafectação basta fazer o inverso Gestão do espaço livre Como referido anteriormente e se pode observar na figura 3.6, cada página é preenchida por linhas e poderá acontecer que não fique totalmente preenchida. Assim, é necessário que exista um mecanismo que faça a gestão do espaço disponível em todas as páginas. Esse mecanismo chama-se a Page Free Space que regista o estado de afectação de cada página e a quantidade de espaço livre em cada página. Para tal dispõe de um byte que regista se a página está afectada e qual a sua percentagem de preenchimento. Após a afectação de extensões a objectos o SQL Server usa as páginas PFS para registar as que estão afectadas ou livres. Estas informações são importantes na pesquisa de páginas livres e na gestão de páginas heap e de texto/imagem. Cada arquivo/ficheiro dispõe de uma página de cabeçalho, seguida de uma página PFS (referentes a 8000 páginas), seguida de uma página GAM (com extensões) e uma página SGAM (também de extensões. Figura 3.8 Sequência de páginas de um arquivo Gestão do espaço por objectos A gestão das páginas por objectos é feita através de uma página IAM (Index Allocation Map) que mapeia as extensões num ficheiro da base de dados usada por uma unidade de afectação. Uma unidade de afectação pode ser de um dos seguintes tipos: IN_ROW_DATA: Mantém uma partição de um heap ou um índice. LOB_DATA: Mantém tipos de dados LOB (objectos grandes), como xml, varbinary (max) e varchar (max). ROW_OVERFLOW_DATA: Mantém dados de comprimento variável armazenados em colunas varchar, nvarchar, varbinary ou colunas sql_variant que excedem o limite de tamanho de linha de bytes.

25 Cada partição de um heap ou um índice contém pelo menos uma unidade de afectação do tipo IN_ROW_DATA. Também pode conter uma unidade de alocação do LOB_DATA ou ROW_OVERFLOW_DATA, dependendo do esquema do heap ou índice. Uma página IAM cobre um intervalo de 4 GB de um ficheiro e tem a mesma cobertura de uma página GAM ou SGAM. Se a unidade de afectação tiver extensões de mais de que um ficheiro, ou ficheiros com tamanho superior a 4 GB, existirão várias páginas IAM ligadas por apontadores. Portanto, cada unidade de afectação tem pelo menos uma página IAM para cada arquivo no qual tem extensões. Também poderá haver mais de uma página IAM num ficheiro, se o intervalo das extensões no ficheiro afectado à unidade de afectação exceder o intervalo que uma única página IAM pode registar. Figura 3.9 Gestão dos Index Alocation Map As páginas IAM são afectadas conforme o sistema necessita e estão localizadas aleatoriamente no ficheiro. A primitiva de sistema, sys.system_internals_allocation_units, aponta para a primeira página IAM de uma unidade de afectação estando as restantes ligadas por apontadores figura Figura 3.10 Ligação das páginas IAM Uma página IAM tem um cabeçalho que indica a extensão inicial do intervalo de extensões mapeado pela página IAM. A página IAM também tem um mapa bitmap onde cada bit representa uma extensão. O primeiro bit no mapa representa a primeira extensão no intervalo, o segundo bit representa a segunda extensão, e assim por diante. Se um bit for 0, a extensão que ele representa não será afectada à unidade de alocação que possui IAM. Se o bit for 1, a extensão que ele representa será afectada à unidade de afectação que possui página IAM.

26 Quando é necessário inserir uma linha nova e não houver espaço disponível na página actual, o sistema usará as páginas IAM e PFS para localizar uma página para afectação ou, para um heap ou uma página de Texto/Imagem. Cada página IAM e PFS abrange muitas páginas de dados, portanto, há poucas páginas IAM e PFS na base de dados, significando que as páginas IAM e PFS geralmente estão na memória do pool de buffers SQL Server tornando as suas pesquisas mais rápidas. Para índices, o ponto de inserção de uma linha nova é definido pela chave do índice e nesse caso, não ocorre o processo de pesquisa descrito anteriormente. O SQL Server só afectará uma extensão nova a uma unidade de afectação quando não conseguir encontrar uma página rapidamente em uma extensão existente com espaço suficiente para manter a linha que se quer inserir Partições As partições tem como finalidade facilitar o manuseamento e executar operações sobre tabelas ou índices de grande dimensão tornando-as mais rápidas e eficientes. Os dados das tabelas são particionados e afectadas em partições individuais e afectadas a grupos de ficheiros. Apesar desta distribuição, as tabelas que sofrem as partições são tratadas como uma única entidade lógica e gozam das mesmas propriedades das restantes tabelas suportando todos os recursos associados ao design, às operações, às restrições e demais propriedades da base de dados. A decisão entre implementar ou não as partições dependerá do tamanho das tabelas, do tipo de acessos, dos recursos de hardware e do seu desempenho nas várias operações que deve suportar. No SQL Server, todas as tabelas e todos os índices de uma base de dados são consideradas partições mesmo se forem compostos apenas por uma só partição. Basicamente, as partições formam a unidade básica de organização na arquitectura física de tabelas e índices. As partições podem ocorrer ao nível do hardware tirando proveito da arquitectura da máquina como por exemplo dos multi-processadores que tornam possíveis processar em paralelo várias operações de consultas simultâneas sobre uma mesma tabela e dos dispositivos RAID que permitem que os dados sejam distribuídos por vários discos permitindo que as operações possam ser feitas simultaneamente sobre diferentes unidades de disco. As partições podem ser feitas sem dividir tabelas colocando-as fisicamente em unidades individuais de disco e colocar as outras tabelas relacionadas em outras áreas dos discos de forma a melhorar o desempenho de operações como consultas que envolvam junções entre tabelas que vão sendo executadas simultaneamente. As partições horizontais dividem uma tabela em várias tabelas com o mesmo número de colunas mas com subconjuntos de linhas da tabela original. As partições horizontais devem ser bem implementadas de forma a minimizar o número de consultas às várias tabelas particionadas. As partições verticais dividem uma tabela em várias tabelas mas com subconjuntos de colunas. Existem dois tipos de partições verticais: Normalização é o processo padrão da base de dados para remover colunas redundantes de uma tabela e colocá-las em tabelas secundárias, vinculadas à tabela primária pela relação da chave primária e chave estrangeira.

27 Partições de linhas dividem a tabela original verticalmente em tabelas com menos colunas. Cada linha lógica numa tabela dividida coincide com a mesma linha lógica das outras tabelas conforme é identificado por uma coluna UNIQUE KEY idêntica, em todas as tabelas particionadas. As partições verticais devem ser utilizadas criteriosamente, porque a análise de dados de várias partições requer consultas que unam as tabelas. O particionamento vertical também pode comprometer o desempenho se as partições forem muito grandes. Antes de particionar uma tabela o utilizador deve criar dois objectos: Função de partição: define como as linhas de uma tabela são mapeadas para um conjunto de partições com base no valor de certas colunas. Deve-se ter em conta os valores para as colunas de partição e o intervalo de valores da coluna de partição para cada partição. Esse intervalo de valores determina o número de partições que essa tabela pode ter e no máximo terá Qualquer coluna cujos tipos de dados possam ser usados como chave de índice também pode ser especificada como coluna de partição, excepto o tipo de dados timestamp, tipos de dados CLR (Common Language Runtime) definidos pelo usuário do Microsoft.NET Framework e tipos de dados de alias. Esquema de partição: mapeia cada partição especificada pela função de partição para um grupo de ficheiros. O utilizador poderá colocar as partições em grupo de ficheiros separados para poder efectuar operações de backup de forma independente. As partições podem ser utilizadas para fazer a gestão de subconjuntos de dados de forma rápida e eficiente utilizando para tal instruções Transact-SQL alter table switch da seguinte forma: Adicionando uma tabela como partição a uma tabela particionada já existente. Alternando a partição de uma tabela particionada para outra. Removendo uma partição para formar uma tabela única. Esses cenários podem ser úteis quando se adicionar novos dados a uma tabela particionada e se remover regularmente dados antigos da mesma tabela particionada. Esta operação envolve grandes ou pequenas quantidades de dados em vários cenários. Se os novos dados que estão a ser adicionados tiverem de ser carregados, apagados ou transformados, eles poderão ser tratados como uma entidade separada para serem adicionados como uma partição. Independentemente do conjunto de dados ser grande ou pequena, a transferência é rápida e eficiente, pois, ao contrário da instrução INSERT INTO SELECT FROM, os dados não são fisicamente movidos mas apenas os metadados sobre onde eles estão armazenados mudam de uma partição para outra. Os dados antigos podem ser arquivados ou armazenados. Estas funcionalidades podem ser representadas no seguinte exemplo. Existe uma tabela TransactionHistory que fornece dados para arquivamento numa tabela TransactionHistoryArchive. Caso se pretenda que na segunda tabela se arquive os dados por meses, poder-se-á particionar a tabela TransactionHistory no seu campo TransactionDate e utilizar o campo de valores para um mês. A tabela TransactionsHistory mantém todo o histórico das

28 transacções enquanto na tabela TransactionHistoryArchive ficarão os dados antigos agrupados por meses. No inicio de cada mês os dados do ultimo mês da tabela TransactionHistory são transferidos automaticamente para a tabela TransactionHistoryArchive. As partições de uma base de dados podem ser visualizadas utilizando a seguinte instrução: select * from sys.partitions; Mostrará a seguinte tabela: Figura Informação das partições na tabela sys.partitions Contém uma linha para cada partição de todas as tabelas e índices da base de dados. Todas as tabelas e índices no SQL Server 2008 contêm pelo menos uma partição, estejam ou não divididos explicitamente. Fica na tabela abaixo o significado de cada coluna: Nome da coluna Tipo de Descrição dados partition_id Bigint ID do parâmetro. É exclusivo na base de dados. object_id int ID do objecto ao qual pertence a partição. Toda tabela ou exibição é composta por pelo menos uma partição. index_id int Identificação do objecto ao qual pertence a partição. partition_number int Número de partição com base em um 1 no índice ou heap de propriedade. Para tabelas e índices não particionados, o valor desta coluna é 1. hobt_id bigint ID do heap de dados ou da árvore B que contêm as linhas para essa partição. rows bigint Número aproximado de linhas nesta partição. data_compression int Indica o estado de compactação de cada partição: 0 = NONE 1 = ROW 2 = PAGE data_compression_desc nvarchar(60) Indica o estado de compactação de cada partição. Os valores possíveis são NONE, ROW e PAGE. Figura Informações das colunas

29 3.2 Memória e Buffer management Arquitectura da memória Apesar de não ser necessário definir o tamanho de memória para afectar ao processo do SQL Server este pode ser parametrizado e usado em determinados ambientes mas de forma geral o SQL Server 2008 adquire e liberta memoria dinamicamente. O SQL Server oferece suporte ao AWE (Address Windowing Extensions) permitindo o uso de memória física de mais de 4 GB (gigabytes) em versões de 32 bits até 64 GB de memória física. Considerando que as operações de leitura e escrita no disco são as que consomem mais recursos e tempo, o SQL Server tenta minimizar os custos desses processos tendo uma pool de buffers na memória para manter a leitura de páginas da base de dados. O SQL Server tenta assim obter, um equilíbrio entre evitar que a pool de buffers fique tão grande que o sistema fique com pouca memória e minimizar as operações de leitura e escrita sobre os ficheiros da base de dados maximizando o tamanho do pool de buffers. Segue uma tabela com os dados parametrizáveis: 32 bits 64 bits Memória convencional Todas as edições do SQL Server: até o limite de espaço de endereço virtual do processo: 2 GB 3 GB com parâmetro de inicialização /3gb 1 4 GB em WOW64 2 Todas as edições do SQL Server: até o limite de espaço de endereço virtual do processo: 7 terabytes na arquitectura IA64 8 terabytes na arquitectura x64 Observação: No Windows Server 2003, a limitação é de 512 GB; e no Windows Server 2003 Service Pack 1, a limitação é de 1 terabyte. Quando o Windows oferece suporte a memória adicional, o SQL Server pode alcançar os limites listados. Mecanismo AWE (Permite ao SQL Server ir além do limite de espaço de endereço virtual do processo na plataforma de 32 bits.) Páginas bloqueadas no privilégio do sistema operativo da memória (Permite bloqueio de memória física, evitando a paginação do sistema operativo da memória bloqueada.) 4 Edições Standard, Enterprise e Developer do SQL Server: o pool de buffers é capaz de aceder até 64 GB de memória. Edições Standard, Enterprise e Developer do SQL Server: necessárias para o processo SQL Server usar o mecanismo AWE. A memória afectada pelo mecanismo AWE não pode passar pelo page out. A concessão desse privilégio sem a activação de AWE não tem nenhum efeito no servidor. Não aplicável 3 Edições Enterprise e Developer do SQL Server: recomendadas, para evitar a paginação do sistema operativo. Pode fornecer um benefício de desempenho dependendo da carga de trabalho. A quantidade de memória acessível é semelhante a da memória convencional. 1 /3gb é um parâmetro de inicialização do sistema operativo. 2 WOW64 (Windows on Windows 64) é um modo em que o SQL Server de 32 bits é executado em um sistema operativo de 64 bits. 3 A sp_configure opção awe enabled, está presente no SQL Server de 64 bits, mas é ignorada. Está sujeita a remoção em versões posteriores ou service packs do SQL Server de 64 bits. 4 Se as páginas bloqueadas no privilégio de memória forem concedidas (em 32 bits para suporte AWE ou em 64 bits próprios), também é recomendável a definição da memória máxima do servidor.

30 3.2.2 Espaços de endereçamento do processo Figura 3.13 Espaço de endereçamento. As aplicações de 32 bits têm um espaço de endereçamento de processo de 4Gb (mapeando no máximo 4 Gb de memória). Os sistemas operativos fornecem acesso a 2Gb de espaço de endereçamento vulgarmente conhecido como espaço de endereço virtual e os restantes 2 Gb estão reservados para o sistema operativo. Em alguns sistemas operativos consegue-se atribuir 3Gb ao endereçamento do processo e 1 Gb para o sistema operativo (ver figura 3.13). O AWE (Address Windowing Extensions) amplia as capacidades das aplicações de 32 bits permitindo o acesso à quantidade máxima de memória física que o sistema operativo suportar. O AWE consegue isso mapeando um subconjunto até 64 GB no espaço de endereço do utilizado. O mapeamento entre o buffer da aplicação e a memória mapeada por AWE é tratado pela manipulação das tabelas de memória virtual do Windows. Para activar o suporte a 3 GB do espaço de processo do modo utilizador, é necessário adicionar o parâmetro /3gb ao ficheiro boot.ini e reiniciar a máquina, permitindo que o parâmetro /3gb fique activado. A definição desse parâmetro permite aos threads da aplicação do utilizador endereçar 3 GB de espaço de endereço de processo; e reserva 1 GB de espaço de endereço de processo para o sistema operativo Gestão da memória dinâmica Como foi dito anteriormente o SQL Server adquire dinamicamente espaço de memória necessária para o seu correcto funcionamento e para tal utiliza as APIs de notificação de memória do Microsoft Windows. O espaço de endereço virtual do SQL Server é dividido em duas regiões distintas: espaço ocupado pela pool de buffers e o espaço restante. Se o mecanismo de AWE estiver activado, a pool de buffers poderá estar no espaço de memória mapeada pela AWE, fornecendo espaço adicional para páginas da base de dados. A pool de buffers serve como fonte de afectação de memória primária do SQL Server. Os componentes externos que fazem parte do processo do SQL Server, como objectos COM, e que não reconhecem os recursos de gestão de memória do SQL Server usam a memória fora do espaço de endereço virtual ocupado pelo pool de buffers. Quando o SQL Server é iniciado, ele determina o tamanho do espaço de endereço virtual da pool de buffers baseado em vários parâmetros, como quantidade de memória física no sistema, número de threads de servidor e vários parâmetros de inicialização. O SQL Server reserva a quantidade de memória do seu espaço de endereço virtual de processo da pool de buffers, mas adquire apenas a quantidade exigida da memória física para a carga actual.

31 A instância vai adquirindo memória conforme necessita para atender às operações solicitadas e quando atinge o limite máximo o Windows notifica-o com um aviso. Caso esteja a ocupar espaço de memória em excesso também liberta. Os limites máximos e mínimos são opções de configuração parametrizáveis, min server memory e max server memory que estabelecem limites máximos e mínimos à quantidade de memória usada pela pool de buffers. As opções min server memory e max server memory são especificadas em megabytes Gestão do Buffer A gestão do buffer consiste em dois mecanismos: o gestor do buffer para aceder e actualizar páginas da base de dados; a cache do buffer (também chamado de pool de buffers) para reduzir as leituras e escritas do sistema de ficheiros em disco. A cache do buffer é o conjunto de páginas/buffers de 8Kb. A gestão do buffer consiste em gerir as operações de leitura sobre a cache e a escrita em disco das páginas modificadas. As páginas da cache mantém-se activas até ser necessário mais espaço. Como foi dito anteriormente o espaço necessário é estimado tendo em consideração alguns factores do momento e capacidades do sistema sendo reservado mas não utilizado na sua totalidade. O intervalo entre a inicialização do SQL Server e o momento em que o cache do buffer obtém seu destino de memória é chamado de ramp-up. Nesse momento, as solicitações de leitura preenchem os buffers conforme necessário. Cada operação de leitura de uma página preenche apenas uma página de buffer. Isso significa que o ramp-up depende do número e do tipo de solicitações do cliente. Para tornar o processo mais rápido em especial em máquinas com muita memória, cada requisição de leitura é transformada em leitura de um conjunto de 8 páginas seguidas. O gestor do buffer terá que cooperar com outros componentes, nomeadamente: Gestor de recurso para controlar o uso de memória global e em plataformas de 32 bits, controlar o uso de espaço de endereço. Gestor da base de dados e SQLOS (SQL Server Operating System) para operações de I/O; Gestor de logs para log write-ahead. O gestor de buffer dá igualmente suporte aos seguintes recursos: O gestor do buffer tira vantagens da arquitectura NUMA (nom-uniform memory acess). São distribuídas páginas de cache do buffer em nós NUMA de hardware, que permitem a um thread aceder uma página de buffer afectada no nó NUMA local em vez de usar memória externa. O gestor de buffer oferece suporte à Hot Add Memory, que permite aos utilizadores adicionar memória física sem reiniciar o servidor.

32 O gestor do buffer oferece suporte à afectação de memória dinâmica em plataformas de 32 bits quando AWE está desactivada. A afectação de memória dinâmica permite ao SQL Server adquirir e libertar eficazmente memória na cache do buffer para oferecer suporte à carga de trabalho actual. O gestor do buffer oferece suporte a páginas grandes em plataformas de 64 bits. O gestor do buffer fornece diagnósticos adicionais que são expostos por meio de relatórios de gestão dinâmica. O gestor do buffer apenas faz leituras e escritas na base de dados sendo as restantes operações da base de dado feitas por componentes específicos da base de dados ou do sistema de ficheiros. As que resultam do gestor do buffer possuem as seguintes características: Todas as operações de escrita e leitura são executadas de forma assíncrona, o que permite ao thread de chamada continuar o processamento enquanto a operação de escrita ou leitura decorre em segundo plano. Todas as operações de escrita e leitura são emitidas nas threads de chamada, a menos que a opção affinity I/O esteja activada. Esta opção associa as leituras e escritas de disco do SQL Server a um subconjunto específico de CPUs. Em ambientes avançados OLTP (transacção online) do SQL Server, essa extensão pode aumentar o desempenho das threads do SQL Server que emitem essas operações. Várias operações de leitura e escrita são realizadas de forma conjunta ou dispersa podendo utilizar ou não áreas de memória não contigua. Desta forma o gestor de buffer pode gerir de forma isolada a gestão de memória sem necessitar de solicitar leituras e escritas físicas. O gestor do buffer fornece informações sobre qualquer solicitação de leitura ou escrita pendente durante pelo menos 15 segundos permitindo identificar possíveis problemas quer do lado do servidor quer do lado do sistema de ficheiros. É gerada uma mensagem de erro 833 que cria um output para o sistema de logs com a seguinte mensagem SQL Server has encountered %d occurrence(s) of I/O requests taking longer than %d seconds to complete on file [%ls] in database [%ls] (%d). The OS file handle is 0x%p. The offset of the latest long I/O is: %#016I64. Este tipo de mensagens indicam que uma operação de leitura ou escrita está bloqueada permanentemente e nunca será concluída ou que não foi concluída ainda. Este tipo de informação pode indicar que existe uma grande carga de trabalho, discos ou sistema de ficheiros que não são adequados ou algum problema num componente que esteja empenhado nessa operação. A integridade dos dados em cada página pode ser garantida através de dois mecanismos: torn page protection e checsum protection. Tanto o primeiro como o segundo além de garantir a integridade dos dados garantem integridade dos vários componentes envolvidos nessas operações, como por exemplo: componentes e hardware, controladores, drivers, cabos e mesmo o sistema operativo. A protecção é adicionada à página um pouco antes da gravação no disco e verificada depois da leitura do disco. A torn page protection, é um método de identificação de páginas corrompidas devido a falhas de energia. Utiliza uma assinatura de 2 bits que é colocada no final de cada sector de 512 bytes na página (depois de ter copiado os dois bits originais no cabeçalho da página). A assinatura vai alternando entre 01 e 10 binário em toda a sequência de gravação, de modo que seja sempre possível identificar quando apenas uma parte dos sectores realizou essa operação no disco: se um bit estiver com estado inválido quando a página for lida posteriormente, a página foi escrita incorrectamente e uma página corrompida é detectada. Este tipo de mecanismo usa poucos recursos mas não detecta todos os erros causados por falhas de hardware de disco. O mecanismo de checksum protection, verifica a integridade dos dados de uma forma mais consistente. O checksum é feito para cada página e escrita no cabeçalho da página. Sempre que o checksum de uma página não coincida gera um

33 erro 824. Este tipo de mecanismo pode identificar mais erros que os anteriores tendo em conta que pode ser aplicada ao final de cada byte, no entanto torna-se uma operação muito pesada para ser utilizado. Este tipo de mecanismo é utilizado como padrão e pode ser definido no momento da criação da base de dados ou alterada através da instrução alter database. A forma como está definida pode ser visualizada consultando a coluna de page_verify_option na tabela sys.databases ou nas propriedades IsTornPageDetectionEnabled da função databadepropertyex Operações de leitura As operações de leitura no SQL Server podem incluir leituras físicas e lógicas. As leituras lógicas ocorrem quando é solicitado à cache do buffer uma página. Caso a cache não disponha dessa página então faz uma leitura física e copia a página de disco para a cache do buffer. As requisições de leitura são controladas por um mecanismo relacional e optimizadas por um mecanismo de armazenamento. O mecanismo relacional determina o método de acesso (table scan, índex scan, ou keyed read) e conforme o método e os mecanismos de gestão do buffer determina-se o padrão geral de leituras a serem executadas. Read-Ahead O SQL Server oferece suporte a um mecanismo de optimização de desempenho designado read-ahead. Este mecanismo funciona por antecipação obtendo os dados e as páginas de índice necessárias para cumprir com um plano de execução de consulta e colocando as páginas em cache do buffer antes de elas serem realmente usadas pela consulta. Este procedimento simultâneo aproveita ao máximo a utilização do CPU e as operações de leitura e escrita. Este mecanismo permite ler até 64 páginas contíguas (512KB) de um arquivo. A leitura é executada como uma única leitura e escreve na mesma dimensão nos buffers da cache. Se alguma página do intervalo já estiver presente na cache do buffer, a página correspondente da leitura será descartada quando ela for concluída. O intervalo de páginas também pode ser cortado em qualquer ponto se as páginas correspondentes já estiverem presentes no cache. Ainda dentro deste mecanismo existem duas especificações: Leitura de páginas de dados: As pesquisas na forma de table scans são muito eficientes na leitura de páginas de dados. Utilizando as páginas IAM (Index Allocation Map) para listar as extensões em uso, o SQL Server pode criar listas ordenadas de endereços físicos que tem que ser lidos e desta forma optimizar as leituras para que sejam sequenciais em disco. Leitura de páginas de índice: Este tipo de mecanismo lê páginas de índice em série ordenado pela chave. Conforme se pode observar na imagem abaixo a página dispõe do conjunto de índices e as suas respectivas localizações. Aproveitando as informações que estão na página de índice é possível ordenar vários read-aheads consecutivos para páginas que contenham as chaves. As páginas que forem intermédias não são lidas mas as adjacentes são lidas em conjunto com as páginas que contem as chaves.

34 O mecanismo de armazenamento usa prefetching para acelerar as full table scans. Como cada tabela de índices contem apontadores para as linhas de dados então também é possível agendar leituras assíncronas para os dados antes de concluir a leitura da página de índices. Advanced Scannning No SQL Server Enterprise, a funcionalidade das pesquisas avançadas podem partilhar por várias threads as full scan tables. Se duas pesquisas decorrerem sobre a mesma tabela, a segunda aproveita os dados da primeira a partir do momento em que foi activada. Algumas particularidades podem ocorrer como a segunda ocorrer momentos depois da primeira e ser necessário ler os valores anteriores a esse momento. Para tal correrá um processo para efectuar a recuperação dos dados. Este processo é conhecido como merry-go-round scanning e demonstra porque os resultados de uma consulta não é ordenado sem a cláusula order by. Eis um exemplo: supondo que exista uma tabela com páginas o utilizador A executa uma instrução Transact-SQL que exige uma full table scan. No momento e que estivesse a processar a página nr , o utilizador B executa outra instrução Transact-SQL que pesquisará a mesma tabela. O SQL Server agenda em conjunto essas operações passando a leitura para ambos os processos. Depois o utilizador B teria que ler as páginas. Sem este tipo de mecanismo, cada utilizador teria de competir pelo espaço do buffer e isso causaria a contenção do braço do disco. As mesmas páginas seriam lidas uma vez para cada utilizador, em vez de serem lidas uma vez e partilhadas por vários utilizadores, reduzindo a velocidade do desempenho e ocupando recursos Operações de escrita As operações de escrita podem ser lógicas e físicas. A operação escrita lógica ocorre quando os dados são modificados numa página na cache do buffer e a operação física ocorre quando a página é escrita em disco. Quando

35 uma página é modificada na cache do buffer, esta não é escrita imediatamente no disco sendo marcada como alterada, podendo ter mais de uma gravação lógica feita antes de ser escrita fisicamente no disco. Em cada operação de escrita lógica, é introduzido um registo nos logs de transacções e antes de passar a página para disco grava-se previamente em disco os logs. O SQL Server usa uma técnica conhecida como log write-ahead que evita a escrita de uma página alterada antes do registo de log associado ser gravado no disco. Este procedimento permitirá recuperar de possíveis falhas que possam ocorrer antes e durante a escrita da página em disco. A ilustração a seguir mostra o processo de gravação de uma página de dados modificada. Quando o gestor do buffer grava uma página, procura páginas adjacentes que tenham sido alteradas para que numa operação de escrita consiga fazer para um número alargado de páginas. Por uma questão de eficiência do processo as páginas seleccionadas deverão ter IDs consecutivos e devem pertencer ao mesmo grupo de ficheiros de forma a minimizar o número de deslocamentos da cabeça do disco, mas as páginas em memória não precisam de ser contíguas. A pesquisa ocorre para a frente e para trás até acontecer um dos seguintes eventos: Uma página não modificada é encontrada. São encontradas 32 páginas. Uma página modificada é encontrada mas o LSN (número de sequência de log) ainda não foi libertado pelo sistema de log como tendo sido escrito em disco. É encontrada uma página que não pode ser bloqueada. Após um destes eventos o conjunto de páginas pode ser gravado no disco com uma única operação gather-write. Ainda antes da página ser escrita, é colocada a informação nos headers para posterior verificação da integridade e são marcadas como EX (exclusivamente) para a operação de escrita e leitura de forma a que outro processo não alterem o seu conteúdo. As operações de escrita podem ocorrer de 3 formas diferentes: Lazy write: processo que maximiza o número de buffers disponíveis em memória removendo páginas que não sejam frequentemente utilizadas. As páginas modificadas são escritas em primeiro lugar em disco.

36 Eager writing: processo que escreve em disco operações que não necessitam de estar registadas em logs e que permite fazer várias operações de escrita em paralelo de novas páginas. Checkpoint: processo que verifica a cache do buffer periodicamente para encontrar páginas que tenham sido alteradas para escrever em disco e vai marcando checkpoints para sinalizar as páginas que já foram escritas. Este modo de operação de escrita pode ser solicitado pelo utilizador usando a instrução checkpoint. Qualquer uma das operações atrás descritas é assíncrona fazendo a verificação de sucesso posteriormente permitindo desta forma maximizar a utilização dos recursos do CPU e de leitura e escrita de dados.

37 4. Indexação e hashing 4.1 Tipos de índices O SQL Server 2008 suporta diversos tipos de índices na indexação da informação guardada nas suas tabelas. A figura seguinte lista os tipos de índices disponíveis no SQL Server. Tipo de Índice Clustered Descrição O índice Clustered classifica e armazena as linhas de dados da tabela ou view numa ordem com base na chave do índice Clustered. O índice Clustered é implementado como uma estrutura de índice da árvore B (arvore B+ com uma ligeira alteração) que oferece suporte à recuperação rápida de linhas com base em seus valores da chave de índice Clustered. Nonclustered Um índice Nonclustered pode ser definido numa tabela ou view com um índice Clustered ou num heap. Cada linha do índice Nonclustered contém o valor da chave não clusterizada e um localizador de linha. Esse localizador aponta para a linha de dados no índice Clustered ou heap que possui o valor da chave. As linhas do índice são armazenadas na ordem dos valores da chave de índice, mas não há garantias de que as linhas de dados estejam numa determinada ordem, a menos que um índice Clustered seja criado na tabela. Unique Um índice Unique garante que a chave de índice não contenha valores duplicados; portanto, cada linha numa tabela ou view é, de alguma forma, única. Ambos os índices Clustereds e Nonclustereds podem ser Uniques. Index with included columns Um índice Nonclustered que é estendido para incluir colunas não-chave além das colunas da chave. Indexed views Um índice numa view materializa (executa) a view e o conjunto de resultados é armazenado permanentemente num índice Clustered único da mesma forma que uma tabela com um índice Clustered é armazenada. Índices Nonclustereds na view podem ser adicionados depois que o índice Clustered é criado. Full-text Um tipo especial de índice funcional com base em token que é criado e mantido pelo Sistema de Full-text da Microsoft para o SQL Server. Ele fornece suporte eficiente para pesquisas sofisticadas de palavras em dados de cadeias de caracteres.

38 Spatial Um índice Spatial fornece a possibilidade de realizar determinadas operações de forma mais eficiente em objectos espaciais (dados espaciais) numa coluna do tipo de dados geometria. O índice Spatial reduz o número de objectos nos quais operações espaciais relativamente dispendiosas precisam ser aplicadas. Filtered Um índice Nonclustered aperfeiçoado, especialmente indicado para abranger consultas que seleccionam de um subconjunto bem definido de dados. Usa um predicado de filtro para indexar uma parte das linhas da tabela. Um índice Filtered bem projectado pode melhorar o desempenho das consultas e reduzir os custos de manutenção e armazenamento do índice em comparação com os índices de tabela completa. XML Uma representação fragmentada e persistente de BLOBS (objectos grandes binários) XML na coluna de tipo de dados xml. Figura 4.1 Tipos de Índice Índice Clustered Visão Geral Salvo raras excepções, toda a tabela deveria ter um índice Clustered definido na coluna ou colunas, o qual proporciona o seguinte: pode ser usado para consultas frequentemente usadas e pode ser usado em consultas de intervalo. Oferece um alto grau de singularidade. Quando é criada uma restrição PRIMARY KEY, um índice Unique na coluna, ou colunas, é criado de forma automática. Normalmente, esse índice é Clustered. Porém, pode-se especificar um índice não-clustered ao criar a restrição. Se o índice Clustered não for criado com a propriedade UNIQUE, o Sistema de Base de Dados acrescentará uma coluna uniqueifier de 4 bytes de forma automática à tabela. Quando necessário, o Sistema de Base de Dados acrescenta um valor uniqueifier de forma automática a uma linha para tornar cada chave exclusiva. Essa coluna e seus valores são usados internamente e não podem ser vistos ou avaliados por utilizadores. Exemplo da criação de um index Clustered: CREATE CLUSTERED INDEX index_name ON tabela (coluna) Estruturas utilizadas No SQL Server, os índices são organizados como árvores B (estas arvores são em tudo idênticas às arvores B+ com a alteração de que em todos os níveis sem excepção os elementos estão ligados à esquerda e á direita). Cada página numa árvore B de índice é chamada de nó do índice. O nó superior da árvore B é designado de nó raiz. O nível inferior dos nós no índice é designado de nó folha. Quaisquer níveis de índice entre os nós raiz e folha são

39 colectivamente conhecidos como níveis intermédios. Num índice Clustered, os nós folha contêm as páginas de dados da tabela subjacente. Os nós de nível intermédio e raiz contêm páginas de índice com linhas de índice. Cada linha de índice contém um valor de chave e um ponteiro para uma página de nível de intermédio na árvore B ou uma linha de dados no nível folha do índice. As páginas de cada nível do índice continuam numa lista duplamente ligada. Normalmente, um índice Clustered tem um único particionamento. Quando um índice Clustered tem particionamentos múltiplos, cada particionamento tem uma estrutura de árvore B que contém os dados para aquele particionamento específico. Dependendo dos tipos de dados no índice Clustered, cada estrutura de índice Clustered terá uma ou mais unidades de alocação para armazenar e gerir os dados de um particionamento específico. No mínimo, cada índice Clustered terá uma unidade de alocação IN_ROW_DATA por particionamento. O índice Clustered também terá uma unidade de alocação LOB_DATA por particionamento se contiver colunas LOB (objectos grandes). Também terá uma unidade de alocação ROW_OVERFLOW_DATA por particionamento se tiver colunas de comprimento variável excedendo o limite de tamanho de linha de bytes. As páginas dos dados e as linhas são classificadas pelo valor da chave de índice Clustered. Todas as inserções são feitas no ponto em que o valor de chave da linha inserida se ajusta à sequência de classificação entre as linhas existentes. Para um índice Clustered, a coluna root_page em sys.system_internals_allocation_units aponta para a parte superior do índice Clustered de um particionamento específico. O SQL Server move para baixo o índice para encontrar a linha correspondente a uma chave de índice Clustered. Para encontrar um intervalo de chaves, o SQL Server deslocase pelo índice até encontrar o valor de chave inicial no intervalo e, depois, examina as páginas de dados usando os ponteiros anteriores ou posteriores. Para encontrar a primeira página na cadeia de páginas de dados, o SQL Server segue os ponteiros mais à esquerda do nó raiz do índice. A figura seguinte mostra a estrutura de um índice Clustered (arvore B+) num único particionamento. Figura 4.2 Estrutura do Índice Clustered (arvore B+)

40 4.1.2 Índice Nonclustered Visão Geral Ao contrário do índice Clustered, vários índices Nonclustereds podem ser criados numa tabela ou view indexada. Em geral, os índices Nonclustereds devem ser criados para melhorar o desempenho de consultas utilizadas com frequência que não são cobertas pelo índice Clustered. Um índice Nonclustered contém os valores de chave do índice e os localizadores de linha que apontam para o local de armazenamento dos dados da tabela. Cada entrada do índice aponta para a página e a linha exactas na tabela ou índice Clustered, em que os dados correspondentes podem ser localizados. Depois que o optimizador de consulta encontrar todas as entradas no índice, poderá ir directamente para a página e a linha exactas e recuperar os dados pretendidos. No caso da tabela em questão tiver um índice Clustered, a coluna(s) definidas no índice Clustered serão anexadas de forma automática ao final de cada índice Nonclustered da tabela. Isso permite efectuar uma consulta sem especificar as colunas de índice Clustered na definição do índice Nonclustered. Por exemplo, se uma tabela tiver um índice Clustered na coluna X, um índice Nonclustered nas colunas Y e Z, terá colunas de valor de chave, as colunas Y, Z e X. Opções de índice Exemplo da criação de um index Nonclustered: CREATE NONCLUSTERED INDEX Phone_index ON basedados.cliente(phone) GO CREATE NONCLUSTERED INDEX _index ON basedados.cliente( ) GO Figura 4.3 Índices Nonclustered numa tabela de dados

41 Estruturas utilizadas Curiosamente, os índices Nonclustereds têm a mesma estrutura de árvore B que os índices Clustereds, salvo das seguintes diferenças : As linhas de dados da tabela subjacente não são classificadas nem armazenadas em ordem com base nas suas chaves não clusterizadas. A camada de folha de um índice Nonclustered é constituída de páginas de índice, em vez de páginas de dados. Os índices Nonclustereds podem ser definidos numa tabela ou uma view com um índice Clustered ou heap. Cada linha no índice Nonclustered contém o valor de chave Nonclustered e um localizador de linha. Esse localizador aponta para a linha de dados no índice Clustered ou no heap que possui o valor de chave. Os localizadores de linha, em linhas de índice Nonclustered, são um ponteiro para uma linha ou uma chave de índice Clustered para uma linha, como se descreve a seguir. No caso da tabela ser um heap, ou seja, se não tiver um índice Clustered, o localizador de linha será um ponteiro para a linha. O ponteiro contém é formado por: o ID (identificador), o número da página e o número da linha na página do arquivo(rowid). O ponteiro é conhecido como RID (Identificação de Linha). Figura 4.4 Exemplo de uma organização interna de uma página de dados de uma heap Se a tabela tiver um índice Clustered, ou o índice estiver numa view indexada, o localizador de linha será a própria chave de índice Clustered dessa própria linha. Se o índice Clustered não for um índice Unique, o SQL Server tornará quaisquer chaves duplicadas em exclusivas ao adicionar um valor gerado internamente, designado indicador de exclusividade. Esse valor de quatro bytes transparente aos utilizadores. O mesmo é adicionado somente quando há necessidade de tornar a chave clusterizada exclusiva para uso em índices Nonclustereds. A linha de dados em questão é recuperada pelo SQL Server, pesquisando o índice Clustered que usa a chave de índice Clustered guardada na linha de folha do índice Nonclustered. Normalmente, um índice Nonclustered tem uma única partição. Quando um índice Nonclustered tem várias partições, cada partição tem uma estrutura de árvore B que contém linhas de índice para aquela partição específica. Mediante os tipos de dados contidos no índice Nonclustered, cada estrutura de índice Nonclustered terá uma ou mais unidades de alocação para armazenar e gerir os dados de uma partição específica.

42 Por defeito, cada índice Nonclustered terá obrigatoriamente, uma unidade de alocação IN_ROW_DATA por partição que armazena as páginas de árvore B do índice. Se o índice Nonclustered contiver colunas LOB (objectos grandes), também terá uma unidade de alocação LOB_DATA por partição. Para além disso, terá uma unidade de alocação ROW_OVERFLOW_DATA por partição se contiver colunas de comprimento variável que ultrapassem o limite de tamanho de linha de bytes. A figura a seguir mostra a estrutura de um índice Nonclustered numa única partição. Figura 4.5 Estrutura índice NonClustered Índice Unique Visão Geral Um índice Unique garante que a chave de índice não contém nenhum valor duplicado, logo, cada linha na tabela é sempre única. Com índices Uniques de multi-colunas, o índice garante que cada combinação de valores na chave de índice é Unique (UNIQUE). Sempre que é criada uma restrição PRIMARY KEY ou UNIQUE, o SQL Server de forma automática gera um índice UNIQUE nas colunas especificadas. Não existe diferença entre criar uma restrição UNIQUE e criar um índice

43 Unique independente de uma restrição. A validação de dados é efectuada da mesma maneira e o optimizador de consultas não diferencia entre um índice Unique criado por uma restrição ou manualmente. Algumas considerações Um índice Unique, uma restrição UNIQUE ou uma restrição PRIMARY KEY não poderão ser criados, se existirem valores de chave duplicados nos dados. Se os dados forem Uniques e se quiser impor exclusividade, criar um índice Unique em vez de um índice não Unique, na mesma combinação de colunas, fornecerá informações adicionais para optimizador de consultas que poderá produzir planos de execução mais eficientes. Um índice não-clustered Unique pode conter colunas não-chave incluídas Index with included columns Visão Geral Este índice é uma extensão aos índices Nonclustereds, conseguida pelo adicionamento de colunas incluídas, aos índices Nonclustereds. Estas colunas são designadas de colunas não-chave, ao nível folha do índice. E, enquanto as colunas de chave são armazenadas em todos os níveis do índice Nonclustered, as colunas não-chave são armazenadas somente no nível folha. O ponto deste índice é a de que ao incluir colunas não-chave, podem-se criar índices não-clustereds que abrangem mais consultas. Isto porque as colunas não-chave têm os seguintes benefícios: As colunas podem ser tipos de dados não permitidos como colunas de chave de índice. As colunas não são considerados pelo Sistema de Base de Dados ao calcular o número de colunas de chave de índice ou o tamanho da chave de índice. Em casos específicos, um índice com colunas não-chave incluídas pode melhorar o desempenho de consulta significativamente quando todas as colunas na consulta forem incluídas no índice como colunas chave ou não-chave. Os ganhos de desempenho são alcançados pois o optimizador de consulta pode encontrar todos os valores de coluna dentro do índice, logo, a tabela ou dados de índice Clustered não são acedidos, resultando daí poucas operações de I/O de disco. Contornar os limites de tamanho Pode-se incluir colunas não-chave num índice Nonclustered para evitar exceder as limitações do tamanho actual do índice, de um máximo de 16 colunas chave, e um máximo de tamanho chave de índice de 900 bytes. Visto

44 que, o Sistema de Base de Dados não considera as colunas não-chave ao calcular o número de colunas chave de índice, ou o tamanho da chave do índice. Exemplo da declaração um índice de colunas incluídas: CREATE INDEX IX_Document_Title ON table(col1, Col2) INCLUDE (col_não-chave); As colunas não-chave estão definidas na cláusula INCLUDE da instrução CREATE INDEX. As colunas não-chave só podem ser definidas em índices não-clustereds em tabelas, ou em Indexed views. Algumas considerações As colunas chave de índice, excepto as não-chave, estão restringidas ao tamanho de índice de no máximo 16 colunas chave, e um tamanho total de chave de índice de no máximo 900 bytes. Obrigatoriamente uma coluna chave tem de ser definida. O número de máximo de colunas não-chave é de 1023 colunas. Esse é o número máximo de colunas de tabela menos 1. Enquanto que o tamanho total de todas as colunas não-chave está limitado somente pelo tamanho especificado das colunas na cláusula INCLUDE Indexed views Visão Geral As views são também conhecidas como tabelas virtuais, porque o conjunto de resultados retornado pela view tem o mesmo formato geral de uma tabela com colunas e linhas. Isso é importante, pois assim as views podem ser referenciadas da mesma forma que as tabelas nas instruções SQL. No entanto, o conjunto de resultados de uma view por defeito não é armazenado permanentemente no base de dados. Sempre que uma consulta referencia uma view por defeito, o SQL Server substitui a definição da view dentro da consulta internamente até que uma consulta modificada, que referencie apenas tabelas base, seja formada. No final o SQL Server executa, então, a consulta resultante de forma normal. Sempre que se efectuam modificações, estas são feitas aos dados nas tabelas que servem de base, essas alterações de dados são reflectidas depois nos dados armazenados na view indexada. O requisito de que o índice Clustered da view seja Unique melhora a eficiência com a qual o SQL Server pode encontrar as linhas, afectadas por qualquer alteração de dados, no índice. O SQL Server escolherá usar uma view indexada no seu plano de consulta apenas se o optimizador de consulta determinar que isso ajude.

45 4.1.6 Índice de Full-text Visão Geral A criação e manutenção de um índice de Full-text envolve preencher o respectivo índice através de um processo designado de população. O SQL Server permite os seguintes tipos de população: população completa, população manual ou automática com base em controle de alterações e população incremental com base em carimbo de data e hora. População completa Durante a execução de uma população completa, são criadas entradas de índice para todas as linhas de uma tabela ou view indexada. Uma população completa de um índice de Full-text cria entradas de índice para todas as linhas da tabela base ou da view indexada. Normalmente, o SQL Server preenche totalmente um novo índice de Full-text assim que ele é criado. No entanto, uma população completa pode consumir recursos consideráveis. Para criar um índice de Full-text sem preenche-lo imediatamente, deve-se especificar a cláusula CHANGE_TRACKING OFF, NO POPULATION na instrução Transact-SQL CREATE FULLTEXT INDEX. O SQL Server não preencherá o novo índice de Full-text até que se execute uma instrução Transact-SQL ALTER FULLTEXT INDEX usando a cláusula START FULL POPULATION ou START INCREMENTAL POPULATION. População com base em controle de alterações Pode-se usar o controle de alterações para manter um índice de Full-text após a população completa inicial. Esta opção, tem uma pequena sobrecarga associada ao controle de alterações dado que SQL Server é obrigado a manter uma tabela que controla as alterações feitas na tabela base desde a última população. Nas situações em que é usado o controle de alterações, o SQL Server mantém um registo das linhas da tabela base ou view indexada que foram modificadas por actualizações, exclusões ou inserções. Por exemplo, pode-se usar populações incrementais, para tabelas que contêm uma coluna timestamp. Quando o controle de alterações é habilitado durante a criação do índice, o SQL Server preenche completamente o novo índice de Full-text, logo após sua criação. Consequentemente, as alterações são controladas e propagadas para o índice de Full-text. Existem dois tipos de controle de alterações: automático (opção CHANGE_TRACKING AUTO) e manual (opção CHANGE_TRACKING MANUAL). O controle de alterações automático é o comportamento por defeito. O tipo de controle de alterações determina como o índice de Full-text é preenchido, como se indica:

46 População automática É o tipo assumido por defeito, ou se especificar CHANGE_TRACKING AUTO, o Sistema de Full-text usa população automática no índice de Full-text. Depois que a população completa a fase inicial é concluída, as alterações são controladas à medida que os dados são modificados na tabela base, todas as alterações efectuadas são propagadas de forma automática. O índice de Full-text é actualizado em segundo plano, embora que, por vezes, as alterações propagadas podem não ser reflectidas imediatamente no índice. Para configurar o controle de alterações com população automática CREATE FULLTEXT INDEX WITH CHANGE_TRACKING AUTO ALTER FULLTEXT INDEX SET CHANGE_TRACKING AUTO Para começar a controlar alterações com população manual CREATE FULLTEXT INDEX WITH CHANGE_TRACKING MANUAL ALTER FULLTEXT INDEX SET CHANGE_TRACKING MANUAL Para configurar o controle de alterações sem nenhum controle de alterações CREATE FULLTEXT INDEX WITH CHANGE_TRACKING OFF ALTER FULLTEXT INDEX SET CHANGE_TRACKING OFF População incremental baseada numa estampilha temporal Uma população incremental é um Sistema alternativo para preencher um índice de Full-text manualmente. Pode-se executar uma população incremental para um índice de Full-text que tem CHANGE_TRACKING definido como MANUAL ou OFF. Se a primeira população num índice de Full-text for uma população incremental, serão indexadas todas as linhas, tornando-a equivalente a uma população completa. O requisito para população incremental é que a tabela indexada deve ter uma coluna do tipo de dados timestamp. Se uma coluna timestamp não existir, a população incremental não poderá ser executada. Uma solicitação para população incremental numa tabela sem uma coluna timestamp resulta numa operação de população completa. Além disso, se nenhum metadado que afecta o índice de Full-text da tabela foi alterado desde a última população, as solicitações de população incremental serão implementadas como populações completas. Isso inclui alterações de metadados geradas pela alteração de qualquer coluna, índice ou definições de índice de Full-text. O SQL Server usa a coluna timestamp para identificar linhas que foram alteradas desde a última população. A população incremental então actualiza o índice de Full-text com linhas adicionadas, excluídas ou modificadas após a última população ou enquanto a última população estava em andamento. Se uma tabela tiver um volume alto de inserções, usar a população incremental poderá ser mais eficiente do que usar a população manual. Ao término de uma população, o Sistema de Full-text regista um novo valor de timestamp. Esse valor é o maior valor de timestamp que o SQL encontrou. Esse valor será usado quando uma população incremental subsequente for iniciada.

47 Para executar uma população incremental, execute uma instrução ALTER FULLTEXT INDEX usando a cláusula START INCREMENTAL POPULATION Indexação Spatial Visão Geral O SQL Server 2008 oferece suporte a dados espaciais. Isso inclui suporte para tipo de dados espaciais planimétricos, geometry, que oferece suporte a dados de geometria, pontos, linhas e polígonos, dentro de um sistema de coordenadas euclidianas. O tipo de dados de geografia representa objectos geográficos numa área na superfície da terra, como uma extensão de terra. A utilização de um índice Spatial numa coluna de geografia permite mapear os dados geográficos para um espaço bidimensional, não euclidiano. Um índice Spatial é definido numa coluna de tabela que contém dados espaciais (uma coluna Spatial). Cada índice Spatial faz referência a um espaço finito. Decompondo espaço indexado numa hierarquia de matriz No SQL Server 2008, índices espaciais são criados usando estruturas do tipo árvores B, o que significa que os índices devem representar os dados espaciais bidimensionais na ordem linear de árvores B. Portanto, antes de ler dados num índice Spatial, o SQL Server 2008 implementa uma decomposição uniforme hierárquica do espaço, através de um processo de criação de índice que decompõe o espaço numa hierarquia de matriz de quatro níveis: nível 1 (o nível superior), nível 2, nível 3e nível 4. De uma forma semelhante, cada nível sucessivo decompõe ainda mais o nível acima dele, de forma que cada célula de nível superior contém uma matriz completa no próximo nível. Num determinado nível, todas as matrizes têm o mesmo número de células ao longo dos dois eixos (por exemplo, 4x4 ou 8x8) e as células são todas de um único tamanho. de 4x4. A figura a seguir mostra a decomposição da célula superior direita em cada nível da hierarquia de uma matriz Figura 4.6 Matriz Densidade da matriz

48 O número de células ao longo dos eixos de uma matriz determina sua densidade: quanto maior o número, mais densa a matriz. Por exemplo, uma matriz de 8x8 (que produz 64 células) é mais densa do que uma matriz de 4x4 (que produz 16 células). A densidade da matriz é definida numa base por nível. A instrução CREATE SPATIAL INDEX Transact-SQL oferece suporte a uma cláusula GRIDS que permite especificar diferentes densidades de matriz em diferentes níveis. A densidade da matriz num determinado nível é especificada usando uma das seguintes palavras-chave: Palavra-chave Configuração da matriz Número de células BAIXA 4X4 16 MÉDIA 8X8 64 ALTA 16X Figura 4.7 Densidade da matriz Pode-se controlar o processo de decomposição especificando densidades da matriz. Por defeito, é ser MÉDIA em todos os níveis. Tessellation Após a decomposição de um espaço indexado numa hierarquia de matriz, o índice Spatial lê os dados da coluna Spatial, linha a linha. Depois de ler os dados de um objecto Spatial (ou instância), o índice Spatial executa um processo de Tessellation para aquele objecto. O processo de Tessellation ajusta o objecto na hierarquia da matriz associando o objecto a um conjunto de células da matriz marcadas por ele. Iniciando no nível 1 da hierarquia de matriz, o processo de Tessellation continua com amplitude primeiro em todo o nível. Potencialmente, o processo pode continuar por todos os quatro níveis, um nível de cada vez. O resultado do processo de Tessellation é um conjunto de células marcadas que são registadas no índice Spatial do objecto. Consultando essas células registadas, o índice Spatial pode encontrar o objecto no espaço em relação a outros objectos na coluna Spatial que também são armazenados no índice. Regras do Tessellation: Para limitar o número de células marcadas registadas para um objecto, o processo de Tessellation aplica várias regras de Tessellation. Essas regras determinam a profundidade do processo de Tessellation e quais das células marcadas são registadas no índice Spatial do objecto. Essas regras são as seguintes: A regra de cobertura: Se o objecto cobrir uma célula completamente, a célula será considerada coberta pelo objecto. Uma célula coberta é contada e não é incluída no Tessellation. Essa regra aplicase a todos os níveis da hierarquia de matriz. A regra de cobertura simplifica o processo de Tessellation e reduz a quantidade de dados que um índice Spatial regista. A regra de células por objecto : Esta regra impõe o limite de células por objecto, que determina o número máximo de células que podem ser contadas para cada objecto, excepto no nível 1. Em níveis

49 inferiores, a regra de células por objecto controla a quantidade de informações que podem ser registadas sobre o objecto. A regra de célula mais profunda: A regra de célula mais profunda gera a melhor aproximação de um objecto registando apenas as células mais inferiores que foram incluídas no Tessellation do objecto. Células pai não contribuem com a contagem de células por objecto e não são registadas no índice. Estas regras de Tessellation são aplicadas recursivamente em cada nível de matriz. A seguir descreve-se as regras de Tessellation em mais detalhes. Regra de cobertura Se o objecto cobrir uma célula completamente, a célula será considerada coberta pelo objecto. Nesta exemplo a célula está completamente coberta pelo desenho do polígono. Figura 4.8 Cobertura de uma célula Uma célula coberta é contada e registada no índice, passando a ser excluída do Tessellation. Regra de células por objecto A extensão do Tessellation de cada objecto depende principalmente do limite células por objecto do índice Spatial. Esse limite define o número máximo de células que o Tessellation pode contar por objecto. No entanto, a regra de células por objecto não é imposta para o nível 1, portanto esse limite pode ser excedido. Se a contagem de nível 1 atingir ou exceder o limite de células por objecto, nenhum Tessellation adicional ocorrerá nos níveis inferiores. Desde que a contagem seja menor do que o limite de células por objecto, o processo de Tessellation continua. Começando com a célula marcada de número inferior, o processo testa cada célula para avaliar se deve contá-la ou incluí-la no Tessellation. Se a inclusão de uma célula no Tessellation exceder o limite de células por objecto, a célula será contada e não será incluída no Tessellation. Caso contrário, a célula será incluída no Tessellation e as células de nível inferior que são marcadas pelo objecto serão contadas. O processo de Tessellation continua dessa maneira, em modo de amplitude, em todo o nível. Esse processo é repetido recursivamente para as matrizes de nível inferior das células incluídas no Tessellation até que o limite seja atingido ou não existam mais células para contar. Normalmente, o limite de células por objecto é de 16, o que fornece uma troca satisfatória entre espaço e precisão para a maior parte dos índices espaciais. No entanto a instrução CREATE SPATIAL INDEX Transact-SQL oferece

50 suporte a uma cláusula CELLS_PER_OBJECT=n que permite especificar um limite de células por objecto entre 1 e 8192, inclusive. Regra de célula mais profunda A regra de célula mais profunda explora o fato de que cada célula de nível inferior pertence à célula acima dela: uma célula de nível 4 pertence a uma célula de nível 3, uma célula de nível 3 pertence a uma célula de nível 2 e uma célula de nível 2 pertence a uma célula de nível 1. Por exemplo, um objecto que pertence à célula também pertence às células 1.1.1, 1.1 e 1. O conhecimento dessas relações de hierarquia de células é criado no processador de consulta. Portanto apenas as células de nível mais profundo precisam ser registadas no índice minimizando as informações que o índice precisa armazenar. Na figura seguinte, o polígono relativamente pequeno é incluído no Tessellation. O índice usa o limite de células por objecto por defeito de 16 que não é atingido para esse objecto pequeno. Portanto o Tessellation continua para baixo até o nível 4. O polígono reside nas seguintes células de nível 1 até nível 3: 4, 4.4 e e e , e Figura 4.9 Polígono indexado num índice Spatial Esquemas de Tessellation O comportamento de um índice Spatial depende parcialmente de seu esquema de Tessellation. O esquema de Tessellation é específico ao tipo de dados. No SQL Server 2008, índices espaciais oferecem suporte a dois esquemas de Tessellation: O Tessellation de matriz geométrica, que é o esquema do tipo de dados geometry. O Tessellation de matriz geográfica que aplica-se a colunas do tipo de dados de geografia.

51 4.1.8 Índice Filtered Visão geral Um índice Filtered não é mais que um índice Nonclustered optimizado, criado especialmente para efectuar consultas que realizam selecções a partir de um subconjunto bem-definido de dados. Estes índices usam um predicado de filtro para indexar uma parte das linhas da tabela. É de notar que um índice Filtered bem conseguido pode melhorar o desempenho das consultas e reduzir os custos de manutenção e armazenamento do índice em relação aos índices que utilizam a tabela completa. Os índices Filtereds podem oferecer as seguintes vantagens com relação aos índices de tabela completa: Melhor desempenho de consultas e qualidade de plano : Um índice Filtered bem projectado melhora o desempenho das consultas e a qualidade do plano de execução visto que é o seu tamanho é menor do que um índice Nonclustered de tabela completa e possui estatísticas filtradas. As estatísticas filtradas, por sua vez, são mais precisas do que as estatísticas de tabela completa, visto que contemplam apenas as linhas do índice Filtered. Redução dos custos de manutenção do índice : Nos índices Filtereds a manutenção do respectivo índice é realizada apenas quando as instruções DML (linguagem de manipulação de dados) alteram os dados do índice. Um índice Filtered reduz os custos de manutenção em comparação com o índice Nonclustered de tabela completa porque é menor e a manutenção é feita somente quando seus dados são afectados. Redução dos custos de armazenamento do índice :Podemos reduzir o espaço ocupado em disco por um índice não clusterizado, através da sua substituição por um índice Filtered, quando um índice de tabela completa não é necessário. Colunas de chave Uma prática recomendada, pelos responsáveis do SQL Server, é incluir um pequeno número de colunas de chave ou incluídas, numa definição de índice Filtered e incorporar apenas as colunas necessárias para o optimizador de consulta escolher o índice Filtered para o plano de execução da consulta. É de notar que a coluna na expressão do índice Filtered não necessitará de ser uma coluna de chave ou incluída na definição do índice Filtered se a expressão do índice Filtered for equivalente ao predicado da consulta e a consulta não retorná-la com os resultados da consulta. A coluna na expressão do índice Filtered deverá ser uma coluna de chave ou incluída na definição do índice Filtered se o predicado da consulta usá-la numa comparação que não for equivalente à expressão do índice Filtered A coluna na expressão do índice Filtered deverá ser uma coluna de chave ou incluída na definição do índice Filtered se fizer parte do conjunto de resultados da consulta.

52 A chave primária da tabela não precisa ser uma coluna de chave ou incluída na definição do índice Filtered. A chave primária é incluída de forma automática em todos os índices Nonclustereds, incluindo índices Filtereds. Suporte ao recurso de índice Filtered Em geral, o Sistema de Base de Dados e as ferramentas oferecem o mesmo suporte para índices Filtereds e índices de tabela completa Nonclustereds, considerando os índices Filtereds como um tipo especial de índices Nonclustereds Índices XML Os índices XML podem ser criados em colunas de tipo de dados xml. Eles indexam todas as marcas, valores e caminhos através das instâncias XML na coluna. As consultas em colunas XML são comuns na sua elevada carga de trabalho. O custo da manutenção de índices XML durante a modificação de dados é um factor a ter em conta. Os valores dos índices para dados do tipo XML são relativamente grandes e as partes recuperadas são relativamente pequenas. As vantagens deste tipo de índices está em que a sua construção evita a análise de todos os dados em tempo de execução, e beneficia de pesquisas de índice para processamento eficiente de consultas. Índices XML encaixam-se nas seguintes categorias: Índice XML primário Índice XML secundário O primeiro índice na coluna de tipo xml deve ser o índice XML primário. Usando o índice de XML primário, os seguintes tipos de índices secundários têm suporte: PATH, VALUE e PROPERTY. Dependendo do tipo de consulta, esses índices secundários podem ajudar a melhorar o desempenho de consultas. Os índices são muito importantes visto que as instâncias XML são armazenadas em colunas de tipo xml como BLOBs (objectos binários grandes). Essas instâncias XML podem ser grandes, visto que a representação binária armazenada de instâncias de tipo de dados xml pode ter até 2 GB, logo snum índice, esses objectos binários grandes serão fragmentados em tempo de execução para avaliar uma consulta, e essa operação pode ser demorada.

53 4.2 Sintaxe de criação de índices Índices UNIQUE, CLUSTERED e NONCLUSTERED CREATE [ UNIQUE ] [ CLUSTERED NONCLUSTERED ] INDEX index_name ON <object> ( column [ ASC DESC ] [,...n ] ) [ INCLUDE ( column_name [,...n ] ) ] [ WHERE <filter_predicate> ] [ WITH ( <relational_index_option> [,...n ] ) ] [ ON { partition_scheme_name ( column_name ) filegroup_name default } ] [ FILESTREAM_ON { filestream_filegroup_name partition_scheme_name "NULL" } ] [ ; ] <object> ::= { [ database_name. [ schema_name ]. schema_name. ] table_or_view_name } <relational_index_option> ::= { PAD_INDEX = { ON OFF } FILLFACTOR = fillfactor SORT_IN_TEMPDB = { ON OFF } IGNORE_DUP_KEY = { ON OFF } STATISTICS_NORECOMPUTE = { ON OFF } DROP_EXISTING = { ON OFF } ONLINE = { ON OFF } ALLOW_ROW_LOCKS = { ON OFF } ALLOW_PAGE_LOCKS = { ON OFF } MAXDOP = max_degree_of_parallelism DATA_COMPRESSION = { NONE ROW PAGE} [ ON PARTITIONS ( { <partition_number_expression> <range> } [,...n ] ) ] } <filter_predicate> ::= <conjunct> [ AND <conjunct> ] <conjunct> ::= <disjunct> <comparison> <disjunct> ::= column_name IN (constant, ) <comparison> ::= column_name <comparison_op> constant <comparison_op> ::= { IS IS NOT = <>!= > >=!> < <=!< } <range> ::= <partition_number_expression> TO <partition_number_expression> Figura 4.10 Sintaxe dos índices: Unique, Clustered e NonClustered. Índice Spatial CREATE SPATIAL INDEX index_name

54 ON <object> ( spatial_column_name ) { [ USING <geometry_grid_tessellation> ] WITH ( <bounding_box> [ [,] <tesselation_parameters> [,...n ] ] [ [,] <spatial_index_option> [,...n ] ] ) [ USING <geography_grid_tessellation> ] [ WITH ( [ <tesselation_parameters> [,...n ] ] [ [,] <spatial_index_option> [,...n ] ] ) ] } [ ON { filegroup_name "default" } ] ; <object> ::= [ database_name. [ schema_name ]. schema_name. ] table_name <geometry_grid_tessellation> ::= { GEOMETRY_GRID } <bounding_box> ::= BOUNDING_BOX = ( { xmin, ymin, xmax, ymax <named_bb_coordinate>, <named_bb_coordinate>, <named_bb_coordinate>, <named_bb_coordinate> } ) <named_bb_coordinate> ::= { XMIN = xmin YMIN = ymin XMAX = xmax YMAX=ymax } <tesselation_parameters> ::= { GRIDS = ( { <grid_density> [,...n ] <density>, <density>, <density>, <density> } ) CELLS_PER_OBJECT = n } <grid_density> ::= { LEVEL_1 = <density> LEVEL_2 = <density> LEVEL_3 = <density> LEVEL_4 = <density> } <density> ::= { LOW MEDIUM HIGH } <geography_grid_tessellation> ::= { GEOGRAPHY_GRID } <spatial_index_option> ::= { PAD_INDEX = { ON OFF } FILLFACTOR = fillfactor SORT_IN_TEMPDB = { ON OFF } IGNORE_DUP_KEY = OFF STATISTICS_NORECOMPUTE = { ON OFF } DROP_EXISTING = { ON OFF }

55 ONLINE = OFF ALLOW_ROW_LOCKS = { ON OFF } ALLOW_PAGE_LOCKS = { ON OFF } MAXDOP = max_degree_of_parallelism } Figura 4.11 Sintax do índice Spatial Índice XML CREATE [ PRIMARY ] XML INDEX index_name ON <object> ( xml_column_name ) [ USING XML INDEX xml_index_name [ FOR { VALUE PATH PROPERTY } ] ] [ WITH ( <xml_index_option> [,...n ] ) ] [ ; ] <object> ::= { [ database_name. [ schema_name ]. schema_name. ] table_name } <xml_index_option> ::= { PAD_INDEX = { ON OFF } FILLFACTOR = fillfactor SORT_IN_TEMPDB = { ON OFF } IGNORE_DUP_KEY = OFF STATISTICS_NORECOMPUTE = { ON OFF } DROP_EXISTING = { ON OFF } ONLINE = OFF ALLOW_ROW_LOCKS = { ON OFF } ALLOW_PAGE_LOCKS = { ON OFF } MAXDOP = max_degree_of_parallelism } Figura 4.12 Sintax do índice XML

56 4.3 Organização de tabela e índice As tabelas e os índices no SQLServer2008 são armazenados como uma colecção de páginas de 8 KB Organização da tabela A figura a seguir mostra a organização de uma tabela no SQL Server. Como se pode ver, uma tabela está contida numa ou mais partições e cada partição contém linhas de dados num heap ou uma estrutura de índice Clustered. As páginas de heap ou índice Clustered são geridas numa ou mais unidades de alocação, dependendo dos tipos de coluna nas linhas de dados. Figura 4.13 Organização das tabelas no SQL Server Partições As páginas de tabela e índice são contidas numa ou mais partições. Uma partição é uma unidade definida pelo utilizador da organização de dados. Normalmente, uma tabela ou um índice tem apenas uma partição que contém todas as páginas de tabela ou índice. A partição reside num único grupo de arquivos. Sempre que uma tabela ou índice usa mais que uma partição, os dados são particionados horizontalmente de forma que os grupos de linhas sejam mapeados em partições individuais, com base numa coluna especificada. As partições podem ser colocadas num ou mais grupos de arquivos na base de dados. A tabela ou o índice é tratado como uma única entidade lógica quando são executadas consultas ou actualizações nos dados Tabelas de Índice Particionadas Conceitos de tabela e índice particionados O particionamento facilita o gestão de grandes tabelas ou índices, permitindo o acesso e o gestão de subconjuntos de dados de forma rápida e eficaz, ao mesmo tempo em que mantém a integridade geral da colecção de dados. As operações de manutenção realizadas nos subconjuntos de dados também são executadas com mais eficiência porque visam apenas aos dados necessários, em vez de toda a tabela.

57 Os dados de tabelas e índices particionados são divididos em unidades que podem ser difundidas por mais de um grupo de arquivos num banco de dados. Os dados são particionados horizontalmente, de forma que os grupos de linhas são mapeados em partições individuais. A tabela (ou índice) é tratada como uma única entidade lógica quando são executadas consultas ou actualizações nos dados. Todas as partições de um único índice ou de uma única tabela devem residir no mesmo banco de dados. As tabelas e os índices particionados suportam todas as propriedades e recursos associados ao design e à geração de consultas de tabelas e índices por defeito, inclusive restrições, padrões, valores de identidade e carimbo de data/hora e triggers. A decisão entre implementar ou não o particionamento depende basicamente do tamanho actual ou futuro da tabela, de como ela será usada e como será seu desempenho com relação às consultas dos utilizadores e às operações de manutenção. Arquitectura de particionamento No SQL Server, todas as tabelas e todos os índices de uma base de dados são considerados particionados, mesmo se forem compostos apenas por uma partição. Basicamente, as partições formam a unidade básica de organização na arquitectura física de tabelas e índices. Ou seja, a arquitectura lógica e física de tabelas e índices é composta por vários espelhos de partição de tabelas e índices com uma partição Índices Uniques particionados Visão geral Apesar de índices particionados poderem ser implementados independentemente de suas tabelas, normalmente, é adequado projectar uma tabela particionada e criar um índice na tabela. Quando se quiser criar um índice na tabela, o SQL Server particionará de forma automática o índice usando o mesmo esquema de partição e coluna particionada como tabela. Como resultado, o índice é particionado essencialmente da mesma maneira que a tabela. Isto deixa o índice alinhado com a tabela. O SQL Server não alinhará o índice com a tabela se for especificado um esquema de partição diferente ou um grupo de arquivos separado para colocar o índice no momento da criação. O alinhamento de um índice com uma tabela particionada é especialmente importante quando se poder antecipar que a mesma será expandida com partições adicionais ou que ela estará envolvida em frequentes trocas de partição. Quando uma tabela e seus índices estão em alinhamento, o SQL Server pode trocar as partições rápida e eficientemente enquanto, mantém a estrutura de partição em ambos, tabela e seus índices. Particionar índices Uniques Ao particionar um índice Unique (Clustered ou Nonclustered), a coluna de particionamento deve ser escolhida entre aquelas usadas na chave de índice exclusiva.

58 Se não for possível incluir a coluna particionada na chave exclusiva, dever-se-á usar um trigger DML em vez de impor exclusividade. Particionando índices Clustereds Quando se efectua um particionamento de um índice Clustered, a chave que serve para clusterizar deve conter também a coluna de particionamento. Quando se particiona um índice Clustered não Unique e a coluna de particionamento não estiver explicitamente especificada na chave de clustering, de forma automática, o SQL Server adiciona a coluna de particionamento, normalmente, à lista de chaves de índices Clustereds. Se o índice Clustered for Unique, dever-se-á especificar explicitamente que a chave de índice Clustered contém a coluna de particionamento. Particionando índices Nonclustereds Quando se efectua um particionamento de um índice Nonclustered Unique, a chave de índice deve conter a coluna de particionamento. Ao particionar um índice Nonclustered e não Unique, o SQL Server adiciona a coluna de particionamento, normalmente, como a coluna do índice não-chave (incluída) para garantir que o índice estará alinhado com a tabela base. No entanto, o SQL Server não adiciona a coluna de particionamento ao índice se este já estiver presente no índice. Limitações de memória e índices particionados Visto que cada tabela de classificação exige uma quantia mínima de memória para construir, a falta de memória podem afectar o desempenho ou habilidade do SQL Server para construir um índice particionado. Especialmente, quando o índice não está alinhado com sua tabela base ou não está alinhado com o índice Clustered, se a tabela já tiver um índice Clustered aplicado a ela. No caso do SQL Server executar uma classificação para construir índices particionados, o sistema construirá primeiro uma tabela de classificação para cada partição, depois, então construirá as tabelas de classificação no respectivo grupo de arquivos de cada partição ou no tempdb, se for especificada, a opção de índice SORT_IN_TEMPDB. Quando se cria um índice particionado que está alinhado com a tabela base, uma tabela de classificação por vez será criada, usando menos memória. No entanto, quando for criado um índice particionado não-alinhado, as tabelas de classificação serão criadas ao mesmo tempo. É de notar que quanto maior for o numero de o número de partições, mais memória será necessária. Visto que o tamanho mínimo para cada tabela de classificação, para cada partição é de 40 páginas com 8 quilobites por página.

59 4.4 Tabelas, heaps e índices Clustereds As tabelas suportadas pelo SQL Server, usam um dos dois métodos para organizar suas páginas de dados numa partição, são elas: Tabelas clusterizadas: As tabelas clusterizadas são que contêm um índice Clustered, e as suas linhas de dados são armazenadas por ordem com base na chave desse índice Clustered. O índice Clustered é implementado recorrendo às estrutura de índice da árvore B que como já foi referenciado, oferece uma recuperação rápida de linhas, com base em seus valores de chave de índice Clustered. As páginas de cada nível do índice, incluindo as páginas de dados no nível folha, são ligadas a uma lista duplamente ligada. No entanto, a navegação de um nível para outro é executada usando valores de chave. Heaps: Heaps são tabelas em que não têm índice Clustered, ou seja, as suas linhas de dados não são armazenadas por nenhuma ordem específica, logo também não há nenhuma ordem específica para a sequência das páginas de dados. As páginas de dados não estão ligadas a uma lista ligada. Figura 4.14 Exemplo de Heap e tabelas com índice Clustered É de realçar que as Indexed views têm a mesma estrutura de armazenamento que as tabelas clusterizadas. E quando um heap ou uma tabela clusterizada tem várias partições, cada partição tem uma estrutura de árvore B ou heap que contém o grupo de linhas para aquela partição específica. Estruturas de heap Nas situações em que uma heap tem particionamentos múltiplos, cada particionamento tem uma estrutura de heap que contém os dados para aquele específico. Dependendo dos tipos de dados na heap, cada estrutura de heap terá uma ou mais unidades de alocação para armazenar e gerir os dados de um particionamento específico. No mínimo, cada heap terá uma unidade de alocação IN_ROW_DATA por particionamento. O heap também terá uma unidade de alocação LOB_DATA por particionamento, caso tenha colunas LOB (objectos grandes). Também terá uma unidade de alocação ROW_OVERFLOW_DATA por particionamento, se tiver colunas de comprimento variável excedendo o limite de tamanho de linha de bytes.

60 As operações sobre as tabelas de um heap podem ser executados examinando as páginas IAM para encontrar as extensões que estão mantendo páginas do heap. Como o IAM representa extensões na mesma ordem que elas existem nos arquivos de dados, isso significa que essas operações sobre a heap progridem sequencialmente por cada arquivo. O uso das páginas IAM para definir a sequência de acessos também significa que as linhas do heap não são retornadas pela ordem em que foram inseridas. dados. A figura a seguir mostra como o Sistema de Base de Dados do SQL Server usa páginas IAM para recuperar linhas de Figura 3.15 Recuperação de dados pelo IAM

61 5. Processamento e optimização de perguntas O Microsoft SQL Server 2008, para optimizar consultas, baseia-se em custos. O optimizador de consultas utiliza estatísticas para estimar a selectividade das expressões, e, assim, o tamanho dos resultados intermédios e finais das consultas. As estatísticas de qualidade permitem que o optimizador avalie, com precisão, o custo dos planos de execução de diferentes consultas, e, em seguida, escolher um plano de alta qualidade. Todas as informações sobre as estatísticas de um objecto são armazenadas na tabela sysindexes. Além disso, as informações sobre as estatísticas podem ser encontradas em sys.stats e sys.indexes. 5.1 Custos O custo do processamento de uma consulta é determinado pelo acesso ao disco. Geralmente, há diversas estratégias possíveis para processar uma determinada consulta, principalmente se ela for complexa. A diferença entre uma estratégia boa e uma ruim, em termos do número de acessos de disco exigidos, é, frequentemente, significativa e pode ser de grande magnitude. Portanto, é muito importante a selecção de uma boa estratégia, ainda que, essa selecção seja demorada. 5.2 Selecção O SQL Server possibilita ao utilizador hints, para poder especificar sugestões para a resolução da consulta. Na imagem seguinte, está especificada a sintaxe para poder utilizar os hints de consultas. <query_hint> ::= { { HASH ORDER } GROUP { CONCAT HASH MERGE } UNION { LOOP MERGE HASH } JOIN FAST number_rows FORCE ORDER MAXDOP number_of_processors OPTIMIZE FOR { UNKNOWN = literal_constant } [,...n ] ) OPTIMIZE FOR UNKNOWN PARAMETERIZATION { SIMPLE FORCED } RECOMPILE ROBUST PLAN KEEP PLAN KEEPFIXED PLAN EXPAND VIEWS MAXRECURSION number USE PLAN N'xml_plan' TABLE HINT ( exposed_object_name [, <table_hint> [ [, ]...n ] ] ) <table_hint> ::= [ NOEXPAND ] { INDEX ( index_value [,...n ] ) INDEX = ( index_value ) FASTFIRSTROW FORCESEEK HOLDLOCK NOLOCK NOWAIT PAGLOCK READCOMMITTED

62 READCOMMITTEDLOCK READPAST READUNCOMMITTED REPEATABLEREAD ROWLOCK SERIALIZABLE TABLOCK TABLOCKX UPDLOCK XLOCK } Figura 5.1 Sintaxe de hints do SQL Server Query Hints { HASH ORDER } GROUP Especifica as agregações das cláusulas GROUP BY, DISTINCT, ou COMPUTE. { MERGE HASH CONCAT } UNION Especifica a forma de processar as operações de UNION. { LOOP MERGE HASH } JOIN Define qual o algoritmo a utilizar em junções. Este tópico é especificado mais a frente. FAST number_rows Especifica que os number_rows sejam processados com maior rapidez. FORCE ORDER É utilizado em operações de junção, para preservar a ordem estabelecida na consulta. MAXDOP number Redefine o grau máximo de paralelismo configurado. USE AdventureWorks ; GO SELECT ProductID, OrderQty, SUM(LineTotal) AS Total FROM Sales.SalesOrderDetail WHERE UnitPrice < $5.00 GROUP BY ProductID, OrderQty ORDER BY ProductID, OrderQty OPTION (MAXDOP 2); GO Figura 5.2 Usando MAXDOP.

63 OPTIMIZE FOR { UNKNOWN = literal_constant } [,...n ] ) Instrui o optimizador para usar um determinado valor, para uma variável local, quando a consulta é compilada e optimizada. O valor é utilizado, apenas, durante a optimização da consulta, e não durante a sua execução. USE AdventureWorks; GO nvarchar(30); nvarchar(15); = 'Ascheim'; = 86171; SELECT * FROM Person.Address WHERE City AND PostalCode OPTION ( OPTIMIZE FOR (@city_name = UNKNOWN) ); GO Figura 5.3 Usando OPTIMIZE FOR. OPTIMIZE FOR UNKNOWN Instrui o optimizador de consulta para usar dados estatísticos, em alternativa aos valores iniciais, para todas as variáveis locais, quando a consulta é compilada e optimizada, incluindo os parâmetros criados com parametrização forçada. compilado. PARAMETERIZATION { SIMPLE FORCED } Especifica as regras de parametrização do optimizador de consulta SQL Server ao aplicar-se à consulta, quando ele é RECOMPILE Informa o SQL Server Database Engine, para descartar o plano gerado pelo optimizador, e gerar um novo plano na próxima execução, forçando o optimizador a gerar e recompilar, de novo, a consulta. ROBUST PLAN Forçar o optimizador a utilizar um plano que aumente a performance do máximo número de linhas possível. KEEP PLAN Forçar o optimizador a relaxar a estimativa recompilada para um ponto da consulta. Esse ponto é, automaticamente, recompilado quando a coluna indexada é modificada. Ao utilizar o KEEP PLAN, garante-se que a consulta não será recompilada, frequentemente, quando existem múltiplas actualizações. KEEPFIXED PLAN Forçar o optimizador a não recompilar consultas, caso as estatísticas tenham mudado. EXPAND VIEWS Especificar que, quando um vista indexada é expandida, mesmo que o optimizador de consulta não considere vistas indexadas, como parte de consultas. Uma vista é expandida quando o nome da vista é substituído pela definição da vista numa consulta. MAXRECURSION number

64 Especificar o número máximo de recursividade para uma consulta. USE PLAN N'xml_plan' Forca o optimizador a usar um plano XML existente, especificado em 'xml_plan'. TABLE HINT ( exposed_object_name [, <table_hint> [ [, ]...n ] ] ) Aplica a um hint específico de uma tabela, ou view, correspondente ao exposed_object_name Table Hints Uma das melhores maneiras de reduzir os acessos ao disco, é utilizar índices. Um índice permite ao SQL Server encontrar a informação em tabelas, sem necessitar de pesquisar toda a tabela. SELECT column_list FROM table_name WITH (INDEX (index_name) [,...]) Figura 5.4 Cláusula para especificar o índice. Caso sejam utilizados múltiplos índices num único hint, os duplicados são ignorados. O resto da lista de índices é utilizado para adquirir tuplos das tabelas. FORCESEEK Especifica que o optimizador de consultas use, somente,, o índice de uma operação de pesquisa como caminho de acesso aos dados na tabela ou vista referenciada na consulta. WITH (FORCESEEK) Figura 5.5 Clausula para utilizar forceseek. Este aplica-se em ambas as operações (clustered e nonclustered) de pesquisa utilizando índices. Pode ser especificado para qualquer tabela ou vista na cláusula FROM, na instrução SELECT, ou na cláusula FROM <table_source> das intrusões UPDATE, MERGE, ou DELETE. O FORCESEEK pode ser especificado sem utilizar qualquer hint de INDEX. Quando combinado com um hint de INDEX, o optimizador de consultas considera, apenas, pesquisar por caminhos através do índice especificado. Se FORCESEEK tiver, como consequência, a não existência de planos, é retornado o erro É recomendado usar os hints INDEX ou FORCESEEK em consultas em contexto de plan guides. Os plan guides são bastante úteis quando não se deseja alterar modificações na consulta original. É possível utilizar, apenas, os hints INDEX ou FORCESEEK em tabelas, vistas, vistas indexadas, expressões comuns sobre tabelas, Dynamic management views e Named subqueries. SELECT * FROM HumanResources.Employee WITH (INDEX (IX_Employee_Test)) WHERE SickLeaveHours = 59 AND Gender = F AND MaritalStatus = M Figura 5.6 Usando index. SELECT * FROM HumanResources.Employee WITH (FORCESEEK) WHERE SickLeaveHours = 59 AND Gender = F AND MaritalStatus = M Figura 5.7 Usando FORCESEEK.

65 5.3 Algoritmos de junção O SQL Server implementa três algoritmos de junção, sendo estes Hash Join, Merger Join e Nested Loop Join Hash Join O hash joint tem dois inputs distintos, o build input e probe input. O optimizador de consultas implementa os inputs para que o menor seja atribuído ao build input. A figura ilustrada, em seguida, especifica a utilização o algoritmo hash joint. Figura 5.8 Algoritmo in-memory hash join O hash join é usado em diferentes tipos de operações: inner join; left, right, e full outer join; left e right semi-join; intersection; union; e difference. Além disso, uma variante do hash join faz remoção de duplicados e agrupamentos, como SUM (salary) GROUP BY department. Essas modificações podem utilizar, apenas, um dos inputs, ou então os dois. Consoante a dimensão dos inputs, existem diversos tipos de execução do hash join, sendo estes: in-memory hash join, grace hash join, e recursive hash join. 1) In-Memory Hash Join O hash join pesquisa todo o input e constrói toda a hash table em memória. Cada linha é inserida dentro de bucket da hash table, consoante o seu valor de hash. Caso a tabela inteira caiba em memória, todas as linhas são inseridas na hash table. A build phase é seguida da probe phase. Toda a probe input é pesquisada linha a linha, onde, para cada linha, é gerado o seu hash e verificado se corresponde com algum existente na hash table. Caso exista, correspondência, essa linha é adicionada ao resultado. 2) Grace Hash Join Caso o build input não caiba em memória, o hash join segue diversas etapas. Inicialmente, todo o build input e o probe input são consumidos e particionados (utilizando uma função de hash) em múltiplos ficheiros. Utilizando a função de hash, garante-se que nenhum estará em dois pares de ficheiros distintos. Assim, a tarefa de unir duas grandes entradas foi reduzida. Seguidamente, é aplicado o hash join para cada.

66 3) Recursive Hash Join Este é utilizado caso o build input seja demasiado grande para a junção standard, logo são necessárias múltiplos níveis de junção e múltiplos níveis de particionamento. Se, apenas algumas das partições são demasiado grandes, os passos de particionamento adicionais são usados, apenas, para essas partições específicas. Nem sempre é possível, durante a optimização, determinar qual o hash a ser usado. Logo, o SQL Server, inicia usando o in-memory hash join e, gradualmente, transita para a grace hash join, e recursive hash join, dependendo do tamanho da entrada. USE AdventureWorks; GO SELECT p.name, pr.productreviewid FROM Production.Product p LEFT OUTER HASH JOIN Production.ProductReview pr ON p.productid = pr.productid Figura 5.9 Utilização do Hash Join Merge Join Esta junção tem, como exigência, que as tabelas envolvidas na operação estejam ordenadas. Mantém ambas as tabelas em paralelo e compara, cada linha da tabela, com todas as linhas da outra tabela. Compara, ainda, uma linha da primeira tabela com outra linha da segunda tabela. Se elas são iguais, então essa linha é seleccionada, caso contrário, o algoritmo percorre todas as linhas com o identificador mais baixo. Em seguida, está um exemplo da utilização deste algoritmo. USE AdventureWorks; /* Merge Join Query Hint */ SELECT * FROM Production.Product AS p INNER MERGE JOIN Sales.SalesOrderDetail AS sod ON p.productid = sod.productid WHERE Weight = Figura 5.10 Utilização do Merge Join Nested Loop Join O Nested Loop Join é composto por dois loops, um interno e um externo. Quando a junção é executada, para cada linha da tabela externa, o loop interno é executado, na totalidade, para todas as linhas da tabela interna. Esta junção é mais eficaz quando a tabela externa é menor que a tabela interna. USE AdventureWorks; /* Nested Loop Join Query Hint */ SELECT * FROM Production.Product AS p INNER LOOP JOIN Sales.SalesOrderDetail AS sod ON p.productid = sod.productid WHERE Weight = Figura 5.11 Utilização do Nested Loop Join

67 5.3.4 Remote Join Esta operação de junção é executada quando se utiliza base de dados distribuídos. É útil quando a tabela esquerda é uma tabela local e a tabela direita é uma tabela remota. Deve ser usado, somente, quando a tabela esquerda tiver menos linhas do que a tabela direita. Se a tabela direita for local, a junção será executada localmente. Se ambas as tabelas forem remotas, mas de fontes de dados diferentes, este join fará com que a junção seja executada no site da tabela direita. Se ambas as tabelas forem tabelas remotas, da mesma fonte de dados, esta junção não será requerida. Este algoritmo de junção não poderá ser usado quando um dos valores, que são comparados no predicado de junção, for lançado num agrupamento diferente usando a cláusula COLLATE. O remote Join deverá ser usado, somente, para operações de INNER JOIN. USE AdventureWorks; /* Remote Join Query Hint */ SELECT * FROM Production.Product AS p INNER Remote JOIN Sales.SalesOrderDetail AS sod ON p.productid = sod.productid WHERE Weight = Figura 5.12 Utilização do Remote Join 5.4 Ordenação A ordenação é utilizada como fases auxiliares a outras operações, ou para definir a ordenação dos resultados da instrução SELECT. ORDER BY { order_by_expression [ COLLATE collation_name ] [ ASC DESC ] } [,...n ] ] Figura 5.13 Sintaxe Ordenação order_by_expression Especifica a coluna que define a ordem de ordenação. COLLATE {collation_name} Especifica que a operação ORDER BY, deve ser processada segundo o agrupamento especificado em collation_name, e não pelo agrupamento das colunas da tabela ou vista. ASC Define que os valores devem ser ordenados ascendentemente. Este é o default.

68 DESC Especifica que os valores devem ser ordenados descendentemente. USE AdventureWorks GO SELECT ProductID, Name FROM Production.Product WHERE Name LIKE 'Lock Washer%' ORDER BY ProductID ; Figura 5.14 Exemplo de Ordenação 5.5 Optimização de consultas O SQL Server baseia-se em custo para optimizar as consultas, gerando vários planos de execução e optando por um. A optimização considera metadados e as estatísticas correntes para definir as estratégias com índices e junções. A figura seguinte mostra os passos relativos à geração do plano de execução para a consulta. Figura 5.15 Geração de planos de execução O SQL Server utiliza como linguagem intermédia uma Query Processor Tree. Esta faz a ligação entre o parser da sintaxe e o optimizador de consultas. A fase de optimização de consultas baseia-se na complexidade da consulta, incluindo o número de tabelas referidas e índices disponíveis. Existem diversos caminhos para executar a consulta contida na Query Processor Tree. Exaustivamente, são comparados os custos de cada caminho, executando aquele que aparenta despender o menor tempo possível. O optimizador adopta diferentes técnicas, tais como: Trivial plan match, Multiple optimizations phases e Parallel plan optimization. O diagrama apresentado, em seguida, ilustra as decisões do optimizador.

69 Trivial plan match Figura 5.16 Fases do optimizador Caso seja uma consulta básica, por exemplo uma tabela única sem índices, sem agregações ou cálculos, o optimizador, ao invés de gastar tempo tentando calcular um plano ideal absoluto, aplica um único plano trivial. Multiple optimizations phases Para uma consulta complexa o número de estratégias de execução a ser analisada é bastante elevado, e gasta demasiado tempo a avaliar cada opção. Logo, ao invés de analisar todos os planos de execução juntos, o optimizador divideos em múltiplas configurações onde cada uma utiliza diferentes índices e técnicas de junção. O optimizador considera as estatísticas das colunas, utilizadas na cláusula WHERE, para avaliar os efeitos do uso de índices e das técnicas de junção. É baseado nas estatísticas que o optimizador avalia o custo das configurações nas múltiplas fases. Após cada fase, o optimizador avalia o custo de processar o plano. Caso o custo encontrado seja suficiente barato, o optimizador pára as iterações e sai do processo de optimização. Caso contrário, continua a iterar.

70 Parallel plan optimization O optimizador considera vários factores enquanto avalia o custo de processar a consulta utilizando parallel plan. Esses factores são: Número de CPU disponível no servidor SQL Server, a memória disponível, o tipo de consulta a ser executada, o número de linhas a processar e o número de conexões concorrentes. Caso só exista um CPU, o optimizador não considera a hipótese de parallel plan. O número de CPU disponível, para ser utilizado em paralelo, pode ser definido utilizado a instrução affinity_mask.sql. O utilizador pode limitar, explicitamente, numa dada consulta, o número de CPU a utilizar, utilizando o hint OPTION (MAXDOP N), sendo N o número máximo de servidores. SELECT * FROM t1 WHERE c1 = 1 OPTION (MAXDOP 2) Figura 5.17 Limitar o número de CPU a utilizar em paralelo Execution Plan Caching O plano de execução de uma consulta, gerado pelo optimizador, é guardado numa memória especial do SQL Server, designada plan caching. Ao guardar o plano em cache, permite, ao SQL Server, não ter de voltar a executar o mesmo processo de optimização para a mesma consulta, caso esta seja novamente requerida. O SQL Server suporta diferentes técnicas como: plan cache aging e plan cache types, para aumentar a reutilização dos planos em cache. Uma novidade no SQL Server 2008, é que a cache permite, também, guardar dois valores binários, designados de query hash e query plan hash. Um plano de execução, gerado pelo optimizador, é composto por dois componentes: Query Plan e Execution Context. O Query Plan representa os comandos que especificam todas as operações físicas para executar a consulta. O Execution Context é uma estrutura de dados que contém as partes variáveis da consulta. O procedimento de cache é parte do SQL Server s buffer cache. Para os novos planos de execução, são adicionados ao procedimento de cache. Assim, o tamanho deste vai aumentado, afectando a retenção de páginas de dados importantes em memória. Para evitar isso, o SQL Server, dinamicamente, controla a retenção de planos de execução em cache, e guarda, apenas, as que são usadas frequentemente, descartando aquelas que não são utilizadas durante um período de tempo. É possível obter as informações sobre os planos de execução em cache, efectuando uma consulta sobre a view sys.dm_exec_plans. O exemplo seguinte ilustra uma possível consulta. A figura apresentada descreve cada campo da view sys.dm_exec_plans. SELECT * FROM sys.dm_exec_plans Figura 5.18 Consulta ao planos de execução em cache

71 Figura 5.19 Descrição dos campos da view sys.dm_exec_plans Reutilização de Execution Plans Quando um consulta é submetida, o SQL Server verifica se a cache contém um plano de execução para essa consulta. Caso não seja encontrada, o SQL Server efectua o processo de optimização, como já foi descrito. No entanto, se for encontrado na cache, este é reutilizado, reduzindo o tempo para gerar um plano de execução. 5.6 Indexed Views As Indexed Views em SQL Server são semelhantes às Materialized Views em Oracle. As Indexed Views reflectem as modificações, após estas serem efectuadas nas tabelas. CREATE VIEW V1 WITH SCHEMABINDING AS SELECT ColA, ColB, ColC * (ColD + 10) AS ExpCol FROM dbo.tablet Figura 5.20 Criação de uma vista indexada. 5.7 Pipelining Microsoft SQL Server 2008 Integration Services (SSIS) faz com que seja possível aumentar a performance das soluções integradas, incluindo extracções de dados, transformações, e loaging (ETL) de dados para data warehousing e, assim, como suporte compatível para Data Transformation Services (DTS). Esta última versão do Microsoft Integration Services inclui novas técnicas, como lookup cache, pipeline parallelism, data profile, ADO. NET e suporte C#. 5.8 Visualização de Planos de execução Utilizando o Microsoft Manager Studio, é possível visualizar os planos de consultas gerados pelo optimizador de consultas. A figura 5.21 apresenta um plano de execução gerado. Como pode ser observado, esse plano contém o custo atribuido a cada operação, bem como os algoritmos utilizados. Figura 5.21 Plano de execução.

72 6. Gestão de transacções e controlo de concorrência Cada vez mais a modificação de dados entra numa área das bases de dados, que devem agir concorrentemente com outras modificações. Esse processo deve ocorrer transaccionalmente para garantir que é mantida a integridade dos dados. As operações transaccionais seguem a norma ACID (Atomicity, Consistency, Isolation, Durability), que define que todas as transacções devem ser atómicas, consistentes, executadas de forma isolada e durável. O isolamento pretende evitar que os impactos de uma transacção influenciem outras transacções antes da sua finalização, com Commit ou Rollback. O SQL SERVER força o isolamento utilizando Locks. Os locks são mecanismos que previnem que as operações, com ambiente de dados partilhados se interfiram, o que seria crítico para a integridade dos dados. Outro mecanismo implementado no SQL SERVER é o control de versões. A integridade dos dados é crítica para as empresas, e a manutenção da integridade é bastante complicada com a actividade de múltiplos utilizadores no mesmo espaço de dados. Apesar de SQL SERVER tratar do processo de locks, esses têm um grande impacto na performance e na actividade do servidor. O SQL SERVER, para garantir a durabilidade das transacções, utiliza o mecanismo de logging. Este mecanismo garante a consistência dos dados na ocorrência de falhas de hardware ou software, revertendo as operações efectuadas pelas transacções incompletas. 6.1 Controlo de transacções Por defeito, as transacções são geridas ao nível da conexão. Quando uma transacção inicia sobre uma conexão, as instruções Transact-SQL, executadas nessa conexão, são parte da operação até que a transacção termine. No entanto, sobre uma sessão Multiple Active Result Set (MARS), uma transacção torna-se batch-scoped, e é gerida ao nível batch. Quando o batch termina, caso a transacção batch-scoped não tiver sido committed ou rolled back, esta é, automaticamente, abortada pelo SQL SERVER. É possível iniciar transacções no SQL Server Database Engine, em diversos modos, tais como: explicit transactions, autocommit transactions, implicit transactions e batch-scoped transactions Explicit Transactions A transacção é iniciada, explicitamente, através de funções de APIs, ou através de instruções Transact-SQL. Este modo é, apenas, válido durante a transacção. Quando a transacção termina, o modo transaccional volta a ser o que estava antes de ser especificado no inicio da transacção, ou seja implicit ou autocommit mode. 1) Instruções Transact-SQL: BEGIN TRANSACTION Define o iniciar de uma transacção. COMMIT TRANSACTION ou COMMIT WORK- Utilizada no fim de uma transacção, para finalizar uma transacção com sucesso, caso não contenha erros. Todos os dados modificados pela transacção, ficam permanentes na base de dados.

73 ROLLBACK TRANSACTION ou ROLLBACK WORK Utilizado para anular uma transacção, caso existam erros. Todas as modificações nos dados são anuladas, voltando a ter os valores que tinham antes do inicio da transacção. 2) Object Linking and Embedding, Database (OLE DB): É possível usar transacções em OLE DB, utilizando o método ITransactionLocal::StartTransaction, para iniciar uma transacção. Para terminar uma transacção é possível utilizar os métodos ITransaction::Commit ou ITransaction::Abort, para finalizar com sucesso uma transacção, ou para a anular, respectivamente. 3) ActiveX Data Objects (ADO): Em ADO, é utilizado o método BeginTrans num objecto Connection para iniciar, explicitamente, uma transacção. Para finalizar uma transacção são invocados, no objecto Connection, os métodos CommitTrans ou RollbackTrans, para finalizar com sucesso uma transacção, ou para a anular, respectivamente. 4) ADO.NET: Com ADO.NETSqlClientmanaged provider, utiliza-se o método BeginTransaction do objecto SqlConnection, para iniciar, explicitamente, transacções. Para finalizar uma transacção, são invocados os métodos Commit() ou Rollback() do objecto SqlTransaction. 5) Open Data Base Connectivity (ODBC): A API ODBC não suporta, explicitamente, transacções, apenas autocommit ou transacções implícitas Autocommit Transactions Este é o modo por defeito dodatabase Engine. Cada instrução individualtransact-sql é committed quando termina. Não é necessário especificar nenhuma instrução para controlar a transacção. Para definir o modo de autocommit numa dada conexão, é utilizada a instrução SET IMPLICIT_TRANSACTIONS seguido de OFF Implicit Transactions Definir, implicitamente, o modo de transacção através de uma função API ou com o comando SET IMPLICIT_TRANSACTIONS ON em Transact-SQL. A próxima instrução, inicia uma nova transacção, automaticamente. Quando a transacção termina, a próxima instrução inicia uma nova transacção. 1) Object Linking and Embedding, Database (OLE DB): Estas API não contêm métodos para definir o modo de transacções implícitas. 2) ActiveX Data Objects(ADO): A API ADO não suporta transacções implícitas, apenas suporta os modos autocommit e transacções explícitas. 3) Open Data Base Connectivity (ODBC): Invocando a função SQLSetConnectAttr com os atributos SQL_ATTR_AUTOCOMMIT e o ValuePtr definidos com o valor SQL_AUTOCOMMIT_OFF para iniciar o modo de transacções implícita. A conexão irá manter-se no modo de transacções implícitas, até que seja chamada a função SQLSetConnectAttr com os atributos SQL_ATTR_AUTOCOMMIT e o ValuePtr definidos com o valor SQL_AUTOCOMMIT_ON. Chamando a função SQLEndTran com CompletionType definido com SQL_COMMIT ou SQL_ROLLBACK, este irá fazer commit ou roll back para cada transacção.

74 6.1.4 Batch-scoped Transactions Aplicável, apenas, em (MARS), a transacção implícita ou explícita, inicia sobre a sessão MARS, tornando-se uma transacção batch-scoped transaction. Uma transacção batch-scoped, que não faça commited ou rolled back, quando termina, esta é, automaticamente, rolled back pelo SQL SERVER Savepoints Savepoints oferece um mecanismo para recuperar parcelas de operações em transacções. É possível criar um savepoint utilizando a instrução SAVE TRANSACTIONsavepoint_name. Posteriormente, ao executar a instrução ROLLBACKsavepoint_name, a transacção é revertida para savepoint, em vez de reverter para o início da transacção. Figura Savepoints Os savepoints são úteis em situações em que os erros são susceptíveis de ocorrer. Actualizações e reversões são operações caras, assim savepoints só são eficazes, se a probabilidade de encontrar o erro é baixa e o custo de verificar a validade de uma actualização, antecipadamente, é relativamente alta. O exemplo a seguir mostra a utilização de savepoints. SET NOCOUNT OFF; GO USE AdventureWorks; GO CREATE TABLE InvCtrl (WhrhousIDint, PartNmbrint, QtyInStkint, ReordrPtint, CONSTRAINT InvPK PRIMARY KEY (WhrhousID, PartNmbr), CONSTRAINT QtyStkCheck CHECK (QtyInStk> 0) ); GO CREATE @OrderQtyint AS SAVE TRANSACTION StkOrdTrn; UPDATE InvCtrl SET QtyInStk = QtyInStk WHERE WhrhousID AND PartNmbr

75 IF (@ErrorVar = 547) BEGIN ROLLBACK TRANSACTION StkOrdTrn; RETURN (SELECT QtyInStk FROM InvCtrl WHERE WhrhousID AND PartNmbr END ELSE RETURN 0; Figura 6.2:Savepoints. 6.2 Nesting Transactions As transacções podem ser nested explicitamente. Este tipo de operação foi destinado a apoiar as operações em procedimentos, que podem ser chamados a partir de uma transacção, já em curso, ou em processos que não têm nenhuma transacção activa. No exemplo 6.6 pode observar-se a aplicação dessa técnica. SET QUOTED_IDENTIFIER OFF; GO SET NOCOUNT OFF; GO USE AdventureWorks; GO CREATE TABLE TestTrans(Cola INT PRIMARY KEY, ColbCHAR(3) NOT NULL); GO CREATE PROCEDURE AS BEGIN TRANSACTION InProc INSERT INTO TestTrans VALUES INSERT INTO TestTrans VALUES (@PriKey + COMMIT TRANSACTION InProc; GO /* Start a transaction and execute TransProc. */ BEGIN TRANSACTION OutOfProc; GO EXEC TransProc 1, 'aaa'; GO /* Roll back the outer transaction, this will roll back TransProc's nested transaction. */ ROLLBACK TRANSACTION OutOfProc; GO EXECUTE TransProc 3,'bbb'; GO /* The following SELECT statement shows only rows 3 and 4 are still in the table. This indicates that the commit of the inner transaction from the first EXECUTE statement of TransProc was overridden by the subsequent rollback. */ SELECT * FROM TestTrans; GO Figura 6.3:Nesting Transactions.

76 O committing de inner transactions é ignorado pelo SQL SERVER Database Engine. As transacções são, igualmente, committed ou rolled back com base na acção tomada no final da transacção principal. Se a transacção do exterior for committed, as transacções internas são committed também. Caso a transacção exterior seja rolled back, as transacções internas também são rolled back, independentemente de haver ou não transacções internas individualmente committed. Cada instrução COMMIT TRANSACTION ou COMMIT WORK aplica-se à última BEGIN TRANSACTION. Caso as instruções BEGIN TRANSACTION sejam nested, então a instrução COMMIT aplica-se apenas à última transacção nested, que é a transacção mais interna. Mesmo que uma instrução COMMIT TRANSACTION transaction_name dentro de uma transacção nested se refira ao nome transacção externa, o committed só se aplica à transacção interna. Não é permitido que o parâmetro transaction_name de uma instrução ROLLBACK TRANSACTION se referira às operações internas de um conjunto de transacções nested. O parâmetro transaction_name só se pode referir ao nome de transacção mais extrema. Se a instrução ROLLBACKtransaction_name utilizar o nome da transacção externa e for executada em qualquer nível de um conjunto de transacções aninhadas, todas as transacções nested, todas as transacções do conjunto serão rolled back. Caso a instrução ROLLBACK WORK ou ROLLBACK TRANSACTION, sem o parâmetro transaction_name, for executada em qualquer nível de um conjunto de transacções aninhadas, são rolls back todas astransactions nested, incluindo a transacção mais externa. A retorna o nível corrente de nesting de uma transacção. Cada instrução BEGIN TRANSACTION incrementa, uma unidade. Cada instrução COMMIT TRANSACTION ou COMMIT WORK subtrai, uma unidade. Por conseguinte, a instrução ROLLBACK WORK ou a ROLLBACK TRANSACTION sem qualquer parâmetro, a 0. Uma possível utilização da instrução é visualizar se, num dado momento, se está dentro de uma transacção, e efectuando a consulta Caso seja 0, é porque não se está dentro de uma transacção, caso contrário sim. 6.3Suporte para transacções de longa duração O início e o final da transacção de longa duração são registados, respectivamente, no primeiro e no segundo backup do log. A operação de commit ou roll back não é registada no primeiro backup. Se, ao aplicar o primeiro backup durante uma operação de recuperação, a transacção de longa duração será tratada como incompleta, e as suas modificações no backup serão revertidas. Além disso, não é permitida a aplicação do segundo backup nesta situação. O SQL SERVER possibilita obter informações sobre as transacções a decorrer numa base de dados. Para isso é utilizada a instrução sys.dm_tran_database_transactions. Caso se queira forçar uma dada transacção a terminar, utiliza-se a instrução KILL { Session ID UOW } [ with STATUSONLY ].

77 6.4 Mecanismos para garantia isolamento O sistema de base de dados SQL SERVER usa diversos mecanismos para garantir a integridade das transacções e a consistência dos dados, quando estes estão a ser acedidos concorrentemente. Um desses mecanismos é designado por locks. Cada transacção solicita locks de tipos diferentes de recursos, como tuplos, tabelas ou mesma a base de dados. Os locks não permitem que transacções concorrentes modifiquem recursos de forma a causar problemas no isolamento de transacções. Cada transacção liberta os locks quando termina a utilização dos recursos bloqueados. O outro mecanismo é o controlo de versões. Quando um nível de isolamento baseado em versões é utilizado, o sistema de base de dados mantém versões dos dados, tais como estes eram no inicio da transacção. Quando um utilizador actualiza os dados, o sistema verifica se outro utilizador alterou os dados, depois de terem sido lidos. Se outro utilizador actualizou os dados, é lançado um erro, e a transacção recomeça. Este mecanismo é usado, principalmente, em ambientes onde existem poucos conflitos entre transacções, e onde o custo de recomeçar uma transacção é inferior ao custo de bloqueio. Para garantir a durabilidade de uma transacção, são usados logs. Mesmo que algo falhe, o sistema, ao reiniciar, utiliza os logs para abortar transacções não concluídas, e para actualizar a base de dados com as transacções finalizadas com sucesso. 6.5 Protocolos com locks Um protocolo de locks utilizado pelo SQL SERVER, é Two-Phase Locking. Este é utilizado em transacções distribuídas, que pode ser visto no capítulo relativo a bases de dados distribuídas. 6.6Gestão de Deadlocks A detecção de deadlocks é executada por uma thread de monitorização de locks, que, periodicamente, inicia uma pesquisa por todas as tarefas do Database Engine. Os seguintes pontos descrevem esse processo de pesquisa: O intervalo por defeito entre cada pesquisa é de 5 segundos. Se a thread de monitorização de locks encontra um deadlocks, o intervalo de detecção de deadlocks reduz para menus de 100 milissegundos, dependendo da frequência de deadlocks. Se thread de monitorização de locks termina uma pesquisa sem encontrar deadlocks, o Database Engine aumenta o intervalo, entre as pesquisas, para 5 segundos. Após um deadlock ser detectado, presume-se que os próximos threads devem esperar por um lock, entrando num ciclo de deadlock. O primeiro conjunto de locks, posteriormente a um deadlock,

78 desencadeia, imediatamente, uma pesquisa de deadlock, ao invés de esperar pela próxima pesquisa de deadlock. Quando a monitorização de locks inicia uma pesquisa de deadlocks para um thread em particular, esta identifica os recursos onde está bloqueado e em espera. O monitor de locks, então, procura os threads que estão a usar esse recurso e, recursivamente, continua a pesquisa até encontrar um ciclo. Caso exista esse ciclo, o deadlock é identificado. Após o deadlock ser detectado, o Database Engine finaliza o deadlock, escolhendo uma das threads como vítima. O Database Engine termina a thread escolhida, revertendo todas as suas operações, e retornando o erro 1205, libertando todas as outras threads em espera no deadlock. Por defeito, o Database Engine escolhe, como vítima do deadlock, a thread, executando a operação que é menos dispendiosa para ser revertida. Em alternativa, o utilizador pode especificar a prioridade de um thread para uma situação de deadlock, utilizando a instrução SET DEADLOCK_PRIORITY. Esta instrução pode ter como valores, NORMAL, ou HIGH, ou, alternativamente, pode ser definido com um inteiro entre -10 a 10. A prioridade por defeito é NORMAL. Numa situação deadlock, é escolhida como vitima a thread com menor prioridade. Caso seja igual, é escolhida a que tem um menor custo na reversão. Caso esse custo também seja igual, é escolhida aleatoriamente. Em Common Language Runtime (CLR), o monitor detecta, automaticamente, deadlocks impasse para recursos de sincronização (monitors, reader/writer lock e thread join) acendidos dentro de procedimentos geridos. No entanto, o deadlock é resolvido lançando uma excepção no procedimento, seleccionando a vítima. A excepção não libera, automaticamente, os recursos. Estes devem ser liberados explicitamente. 6.7 Níveis de Granularidade O Microsoft SQL Server Database Engine tem diversos níveis de granularidade, utilizando locks. Estes permitem bloquear diversos tipos de recursos durante uma transacção. Para minimizar o custo de um lock, o Database Engine, automaticamente, define o nível apropriado do lock, minimizando o custo do bloqueio. Bloquear num nível baixo de granularidade, como linhas, aumenta a concorrência, mas tem uma sobrecarga maior, porque mais locks devem vir a ser requeridos quando se necessita de mais linhas. Bloqueando um nível maior de granularidade, como tabelas, são caros em termos de concorrência, porque bloquear a tabela inteira restringe o acesso a qualquer parte desta por outras transacções. No entanto, tem uma sobrecarga menor, porque menos locks estão sendo mantidos. A tabela apresentada em seguida, descreve o tipo de locks disponibilizados pelo SQL SERVER.

79 Figura 6.4 Níveis de Granularidade Dynamic Locking Usando locks de nível baixo, tal como locks de linhas, a concorrência aumenta, diminuindo a probabilidade de duas transacções solicitarem bloqueios no mesmo pedaço de dados em simultâneo. Usando o baixo nível locks também aumenta o número de locks e os recursos necessários para os gerir. Usando um alto nível reduz a sobrecarga, mas à custa da redução da concorrência. Figura Dynamic Locking O Microsoft SQL Server Database Engine utiliza uma estratégia dinâmica de bloqueio para determinar a melhor relação custo/eficiência. O Database Engine, automaticamente, determina os locks mais apropriados quando a consulta é executada, com base nas características do esquema da consulta. Dynamic locking tem as seguintes vantagens: Simplificar a administração da base de dados, ou seja, que os administradores não tenham que ajustar lock. Aumenta a performance. O Database Engine minimiza a sobrecarga do sistema usando locks apropriados para a tarefa. Os programadores podem concentrar-se, apenas, nas suas aplicações, visto que o Database Engine ajusta os locks automaticamente

80 6.8Tipos de Locks Além de apoiar diferentes níveis de granularidades, o Microsoft SQL Server Database Engine suporta inúmeros tipos de locks para diferentes situações. A Tabela, descrita em seguida, mostra os diferentes tipos de locks utilizados pelo SQL SERVER. Modos de Lock Shared (S) Update (U) Exclusive (X) Intent Schema Bulk Update (BU) Key-range Descrição Usada para operações de leitura que não mudam, ou actualização de dados, como a instrução SELECT Usado em recursos que podem ser actualizados. Impede que uma forma comum de deadlock ocorra quando múltiplas sessões estão a ler, estão bloqueadas, e potencialmente actualizarão recursos mais tarde. Usado para operações de modificação de dados, tais como INSERT, UPDATE ou DELETE. Garante que várias actualizações não podem ser feitas para o mesmo recurso, em simultâneo. Usado para estabelecer uma hierarquia de locks. Os tipos de intenção de locks são: intent shared (IS), intent exclusive (IX), and shared with intent exclusive (SIX). Usado quando uma operação dependente do esquema de uma tabela que está a ser executada. Os tipos de locks de esquema são: schema modification (Sch-M) and schema stability (Sch-S). Utilizado quando se copia dados em massa de uma tabela e o TABLOCKhint é especificado Protege o intervalo de linhas lidas por uma consulta, ao usar o nível de isolamento serializable. Assegura que outras transacções não podem inserir linhas que modifiquem as consultas da transacção serializable, caso esta venha a executar as consultas novamente. Figura 6.6 Diferentes tipos de locks 6.9 Transact-SQL Locking Hints Quando se escreve código Transact-SQL (TSQL), é possível adicionar hints específicos para o Database Engine definir qual o lock, permitindo definir o nível de granularidade a utilizar no lock. O exemplo, ilustrado em seguida, mostra a utilização de um hint numa dada consulta. USE AdventureWorks2008; SELECT * FROMPerson.PersonWITH(TABLOCK, NOWAIT) WHERELastNameLIKE K% ; Figura 6.7 Utilização de hint numa consulta Em seguida, está descrita na tabela 6.1, apresentado os diferentes hints utilizando locks, disponíveis pelo SQL SERVER.

81 Figura 6.8 LockHints 6.10 Níveis de Isolamento O SQL SERVER implementa 6 níveis de isolamento. Quatro deles são os do standard SQL, e utilizam locks. Os outros dois baseiam-se em row version. Estes, podem ser configurados utilizando o comando SET TRANSACTION LEVEL, ou por hints. 1) Read Uncommitted:Este é o nível mais baixo de isolamento, e permite que uma instrução SELECT, obtenha a resposta sem requerer locks. Para utilizar este nível no SQL SERVER, utiliza-se o comando SET TRANSACTION LEVEL READ UNCOMMITTED, ou numa, dada consulta, adiciona-se WITH(NOLOCK) (ex: SELECT * FROM Production. Products WITH(NOLOCK); ). Este nível de isolamento pode ter, como consequência, dirty read. 2) Read Committed: Este nível difere do anterior, prevenindo dirty read. Ou seja, é requisitado um lock pela instrução SELECT. Este é o nível por defeito do SQL SERVER. Pode ser, explicitamente, definido pelo utilizador, utilizando a instrução SET TRANSACTION LEVEL READ COMMITTED. 3) Repeatable Read: Este nível define que as instruções não possam ler dados que foram modificando, mas ainda não committed por outras transacções. Esse nível pode ser definido utilizando a instrução SET TRANSACTION LEVEL REPEATABLE READ. 4) Serializable: Este é o nível de isolamento mais elevado entre os seis. Este adquire um conjunto de locks das linhas que vão sendo requeridas, ou seja, bloqueia todas as operações que possam interferir com as operações da transacção. Esse nível pode ser definido utilizando a instrução SET TRANSACTION LEVEL SERIALIZABLE.