Tecnologia de Base de Dados SQL Server Tecnologia de Base de Dados Nuno Costa – Nº 50099

Tópicos Introdução História Estrutura do SQL Server Armazenamento Tabelas/Índices Scan e read-ahead Views Tipos de Views Execução/Optimização de querys Acesso concorrente Save-points Updates Níveis de isolamento

História O SQL Server, originalmente designado Sysbase SQL Server, nasceu de uma parceria entre a Sybase, Ashton-Tate e a Microsoft, competindo directamente com a Oracle e IBM. A primeira versão resultante da parceria, denominada SQL Server 4.2 surgiu em 1989, para OS/2, sendo igual ao Sybase SQL Server 4.0 compatível com sistemas Unix e VMS. O primeiro lançamento do Microsoft SQL Server para NT surgiu em 1992, sendo que a primeira versão totalmente compatível com NT, sem qualquer ligação à Sybase, só apareceu com o Microsoft SQL Server v6.0 Por volta da altura em que o Windows NT saiu, já a Microsoft e Sybase tinham seguindo percursos distintos no que diz respeito ao desenho e implementação do seu próprio SGBD, tendo a Sybase mudado o nome do seu produto para Adaptive Server Enterprise. Ashton-Tate (Ashton-Tate Corporation) is a former US based software company best known for developing the popular dBASE database application. The company was bought by Borland in September 1991, who no longer sells any of their products. OpenVMS (Open Virtual Memory System or just VMS) is the name of a high-end computer server operating system that runs on the VAX and Alpha family of computers developed by Digital Equipment Corporation of Maynard, Massachusetts (now owned by Hewlett-Packard), and more recently on Hewlett-Packard systems built around Intel Itanium CPU. Adaptive Server Enterprise (ASE) is Sybase Corporation's flagship relational database management system product. A graphical user interface (or GUI, sometimes pronounced "gooey") is a method of interacting with a computer through a metaphor of direct manipulation of graphical images and widgets in addition to text. Fonte(s): http://en.wikipedia.org/wiki/MS-SQL

Armazenamento No SQL Server uma BD envolve uma colecção de ficheiros, contendo os dados e suportada por um único log de transacção De seguida irá ser mencionada a forma de armazenamento de tabelas e as várias formas de acesso a estas.

Armazenamento - Tabelas O SQL Server suporta dois tipos de organização: Heap – a localização de cada linha de uma tabela é determinada pelo sistema, não sendo possível ao utilizador especificá-la. Cada linha tem um identificador (RID), nunca sendo mudado excepto quando o ficheiro é comprimido ou a linha mudada. Clustered index – as linhas de uma tabela são guardadas numa B+ tree, ordenada pela chave do clustered index. Esta chave serve igualmente para identificar cada linha da tabela, podendo ser definida como nonunique e neste caso o SQL Server adiciona uma coluna oculta de forma a tornar a chave única.

Armazenamento – Scans e Read-Aheads A execução de querys no SQL Server poderá ser feita usando diferentes métodos de procura em tabelas e índices, como por exemplo scan total de tabelas vs filtered scans, forwards vs backward ou ordered vs unordered scans. Cada um destes tipos de scan usa um mecanismo de read-ahead que tenta estar sempre à frente da linha de execução da query de forma a reduzir o tempo de procura e idle do disco. O algoritmo read-ahead usa o conhecimento obtido partir do plano de execução da query de forma a assegurar-se que apenas é obtida a informação requisitada pela query. A quantidade de informação a ser lida pelo read-ahead é automaticamente ajustada de acordo com a dimensão do buffer, capacidade de I/O e ritmo ao qual os dados são “consumidos” na execução da query.

Views As views são tabelas virtuais cuja informação é definida através de um select As tabelas referenciadas por views são denominadas tabelas base Os resultados de uma View podem ser obtidas a partir de outras O optimizador de custos avalia uma View como se esta não existisse

Tipos de Views Indexed Views: têm como único propósito optimizar a performance na execução de querys que trabalham com grandes quantidades de informação, agregando-a sob a forma de sums, counts e averages. Partitioned Views: são usadas para particionar dados por vários tabelas, BD´s ou instâncias de SQL Server, distribuindo a carga computacional, sendo possível fazer a query a partir de vários servidores de BD. Exemplo no livro...

Execução/Optimização de querys Na execução de querys, o SQL Server tem baseia-se no protótipo de optimização Cascades. Os passos na execução de uma query são: Parsing/Binding – o optimizador procede ao parsing de cada statement da query e identifica as tabelas, nomes de colunas recorrendo ao catálogo. Constrói views de forma a gerar uma árvore de operadores e verifica na cache de procedimentos se já existe um plano de execução para aquela query, podendo assim evitar o processo de optimização. Através de algebra relacional, é elaborada uma combinação de operadores relacionais

Execução/Optimização de querys Simplificação/Optimização – o optimizador aplica uma série de regras à árvore de operadores de forma a obter uma forma simplicada. Durante este processo o optimizador calcula e recorre a estatísticas para calcular a cardinalidade (caso não existam estatísticas o optimizador gera-as antes de dar seguimento ao processo de optimização) Optimização cost-based – o optimizado explora (reordenação de operadores, como por exemplo joins) e implementa diferentes regras (merge join, hash join, etc) de forma a gerar alternativas e estimando o custo de execução de cada uma, escolhe o plano de execução mais favorável. Preparação do plano – com base no plano seleccionado, o optimizador cria as estruturas necessárias para a execução da query

Acesso concorrente e recuperação - Save-points O SQL Server suporta dois tipos de save-points de transacção: Statement – o save-point é definido no início da statement de modo a que caso esta falhe não haja rollback de toda a transacção Named - a aplicação define um save-point algures na transacção e caso haja rollback, a transacção irá ser retomada a partir do ponto definido.

Acesso concorrente e recuperação - opções de concorrência nos Updates O SQL Server tem duas opções no acesso concorrente, na operação de update: Optimista – parte do princípio que qualquer conflito de recursos que surga entre múltiplos utilizadores é improvável (mas não impossível) que aconteça e permite a execução de transacções sem recorrer a locks. Caso ocorra um conflito, a aplicação terá de ler a informação e tentar de novo. As aplicações detectam as mudanças comparando valores ou verificando um valor especial de versão, atribuído a cada linha.

Acesso concorrente e recuperação - opções de concorrência nos Updates(cont.) Pessimista (default) – sempre que necessário, o controlo de concorrência recorre a locks durante a execução de um transacção. Caso não ocorram deadlocks o sucesso da transacção é assegurado. Os locks podem ser feitos a vários tipos de recursos: RID – usado para lock de uma única linha numa tabela Chave – permite protecção de um determinado range key Página – tabela/Página de index de 8Kbyte Extent – grupo contíguo de 8 páginas de dados ou indíces Tabela – tabela inteira, incluindo indíces BD

Acesso concorrente e recuperação - Níveis de Isolamento Os níveis de isolamento suportados pelo SQL Server são: Read uncommited (dirty read) – nível mais baixo, onde as transacções são isoladas apenas ao ponto de garantir que não existem leituras de dados fisicamente corrumpidos. Read commited (nível default) – O SQL Server usa shared locks na leitura de informação e assegura que dados fisicamente corrumpidos nunca irão ser lidos bem como leitura de informação que foi alterada mas não foi commited, no entanto, não assegura que essa informação não irá ser alterada antes de a transacção acabar Repeatable read – não permite a ocorrência de dirty reads e nonrepeatable reads, ou seja, irá ser feito um lock a toda a informação requisitada por uma query, impossibilitando outras transacções de alterar esses dados, até que a transacção que fez o lock acabe. Serializable – nível mais alto de isolamento, onde cada transacção é totalmente isolada de outras que estejam a ser executadas

Bibliografia http://en.wikipedia.org/wiki/MS-SQL http://www.mssqlcity.com/Articles/Adm/SQL70Locks.htm Silberschatz, Korth, Sudarshan, “Database System Concepts”, Cap. 27, McGraw-Hill, 4th Edition

Fim