Livro Banco de Dados

Projeto Fsico de Banco de Dados
Esta unidade discute em detalhes os principais aspectos relacionados ao projeto fsico de sistemas de bancos de dados. Inicialmente, defini-se o que um Sistema de Banco de Dados. Em seguida, discute-se uma possvel arquitetura para um Sistema de Banco de Dados. Uma classificao das vrias tendncias para arquiteturas de Sistemas de Bancos de dados apresentada. Posteriormente, examinamos os conceitos, tcnicas e estratgias relacionadas ao armazenamento de dados, ao gerenciamento de buffer e indexao de dados.
SUMRIO
UNIDADE I PROJETO FSICO DE BANCOS DE DADOS
1. SISTEMAS DE BANCOS DE DADOS 1.1. Introduo .................................................................. 15 1.2. Arquitetura ................................................................. 18 1.3. Classificao...... ........................................................ 21 1.4. Exerccios ................................................................... 37
2. ARMAZENAMENTO DE DADOS 2.1. Introduo .................................................................. 40 2.2. Discos Magnticos...................................................... 43 2.3. RAID............................................................................ 46 2.4. Armazenamento Tercerio.......................................... 49 2.5. Gerenciamento de Arquivos ........................................ 2.6. Organizao de Arquivos .............................................
3. GERENCIAMENTO DE BUFFER 3.1. Sistema de Memria Virtual........................................ 51 3.2. O Gerenciador de Buffer............................................. 53 3.3. Mecanismo de Paginao de SGBDs......................... 58 3.4. Polticas de Alocao de Pginas............................... 3.5. Exerccios .................................................................. 61
4. INDEXAO DE DADOS 3.1. Conceitos Bsicos...................................................... 51 3.2. ndices Baseados em rvores.................................... 53 3.3. ndices Baseados em Hash........................................ 58 3.4. ndices em SQL.......................................................... 3.4. Exerccios .................................................................. 61
5. WEBLIOGRAFIA ..................................................................... 64
6. REFERNCIAS BIBLIOGRFICAS ........................................ 65

SISTEMAS DE BANCOS DE DADOS A finalidade de um sistema de bancos de dados simplificar e facilitar o acesso aos dados. Assim, os usurios do sistema no devem preocupar-se desnecessariamente com os detalhes fsicos da implementao do sistema. Contudo, o principal fator na satisfao de um usurio com o sistema de bancos de dados seu desempenho. Se o tempo de resposta a uma solicitao muito longo, o valor do sistema diminudo. Porm, o desempenho de um sistema de banco de dados depende da eficincia das estruturas de dados internas usadas para representar os dados no banco de dados, das tcnicas utilizadas para a troca de dados entre o disco rgido e a memria principal do sistema, bem como das estruturas de ndices utilizadas para recuperar dados de forma mais eficiente.
1.1. Introduo Um Banco de Dados (BD) uma coleo de dados interrelacionados, representado informaes sobre um domnio
especfico. J um Sistema Gerenciador de Banco de Dados (como no Brasil) ou Sistema de Gerenciamento de Banco de Dados (SGBD) o conjunto de programas de computador (softwares) responsveis pelo gerenciamento de um banco de dados, o que inclui o armazenamento, o acesso, o controle de concorrncia e a recuperao desses dados. Assim, o principal objetivo de um SGBD retirar da aplicao cliente a responsabilidade de gerenciar o acesso, manipulao e organizao dos dados. O SGBD
disponibiliza uma interface para que os seus clientes possam incluir, alterar ou consultar dados. Um Sistema de Banco de Dados (SBD) consiste em uma coleo de dados inter-relacionados (BD) e uma coleo de programas para prover o acesso aos dados 4
armazenados (SGBD). O objetivo principal de um sistema de banco de dados prover um ambiente que seja adequado e eficiente para uso no armazenamento e recuperao de informaes.
1.2. Arquitetura Um sistema de banco de dados (SBD) dividido em mdulos que tratam de cada uma das responsabilidades do sistema. Na maioria dos casos, o sistema operacional (SO) do computador fornece apenas os servios mais bsicos e o sistema de banco de dados precisa ser construdo sobre essa base. Portanto, o projeto do sistema de banco de dados precisa incluir consideraes sobre a interface entre o sistema de banco de dados e o sistema operacional.
Figura 1.1: Possvel Arquitetura de um SGBD
A Figura 1.1 ilustra os principais componentes funcionais de um sistema de banco de dados. Nesta arquitetura, um SGBD (ou DBMS Database Management System) formado por dois mdulos principais: O Processador de Consultas e o Sistema de Armazenamento.
O processador de consultas responsvel por traduzir as consultas recebidas do usurio ou de uma aplicao, as quais so representadas por comandos em uma determinada linguagem de consulta (como SQL, por exemplo), em operaes de baixo nvel que o gerenciador do banco de dados pode interpretar e executar. Alm disso, o processador de consultas tenta transformar uma requisio do usurio em uma representao interna que seja equivalente (ou seja, retorne os dados solicitados) consulta recebida, porm mais eficiente em termos de desempenho, encontrando uma boa estratgia para executar a consulta. O processador de consultas dividido nos seguintes mdulos:
Compilador DML Analisa sintaticamente e semanticamente os comandos DML
(Data Manipulation Language) expressos em uma determinada linguagem de consulta (SQL, por exemplo) recebidos do usurio. Em seguida, traduz estes comandos para uma das formas de representao interna de consultas (como por exemplo, a lgebra relacional). Pr-Compilador DML Traduz comandos DML, embutidos em um programas aplicativos que acessam o sistema de banco de dados, em chamadas a procedimentos (rotinas) em uma linguagem hospedeira. O pr-compilador precisa interagir com o processador de consultas pra gerar o cdigo apropriado. Interpretador DDL Interpreta comandos DDL (Data Definition Language) e os armazena no catlogo. Um catlogo uma tabela que armazena meta-dados. J os meta-dados descrevem o banco de dados, ou seja, o esquema do banco de dados. Mecanismo de Consultas Responsvel pela otimizao e gerao de planos de execuo de consultas.
O Sistema de Armazenamento fornece a interface entre os dados de baixo nvel armazenados no disco e os programas aplicativos e de consulta que necessitam acessar os dados armazenados. O Sistema de Armazenamento dividido nos seguintes mdulos:
Gerenciador de Transaes Responsvel pelo controle de concorrncia e pela
recuperao do banco de dados aps falhas. Gerenciador de Buffer Responsvel por recuperar objetos em disco e carreg-los na memria principal em forma de pginas. Gerenciador de Arquivo (File System) Responsvel pelo armazenamento fsico em disco. O gerenciador de arquivos gerencia a alocao do espao em disco e as estruturas de dados usadas para representar a informao armazenada no disco.
Adicionalmente, diversas estruturas de dados so requeridas como parte da implementao do sistema fsico de um banco de dados (BD), incluindo: Arquivos de dados, que armazenam o banco de dados propriamente dito. Catlogo ou Dicionrio de dados, que armazena
metadados sobre a estrutura do banco de dados. Esse metadados incluem: nomes das tabelas, atributos de cada tabela, definio de ndice para uma tabela, alm de informaes estatsticas, como por exemplo, a cardinalidade de uma tabela. O dicionrio de dados usado com freqncia. Assim, deve-se dar grande nfase no desenvolvimento de um bom projeto e implementao eficiente do dicionrio. ndices, estruturas que fornecem acesso rpido aos itens de dados guardando determinados valores. 7
Fragmentos
de
Cdigo,
tais
como
procedimentos
armazenados (stored procedures) e gatilhos (triggers).
1.3. Classificao dos Sistemas de Bancos de Dados Os primeiros Sistemas de Bancos de dados usavam mainframes para executar o processamento de todas as funes do sistema, incluindo os programas aplicativos, programas de interface com o usurio, bem como a funcionalidade dos SGBDs. Assim, a maioria dos usurios fazia acesso aos sistemas via terminais que no possuam poder de processamento, apenas a capacidade de visualizao. Todos os processamentos eram feitos remotamente, apenas as informaes a serem visualizadas e os controles eram enviados do mainframe para os terminais de visualizao, conectados a ele por redes de comunicao. Como os preos do hardware foram decrescendo, muitos usurios trocaram seus terminais por computadores pessoais (Personal Computer - PC) e estaes de trabalho. Inicialmente, os SGBDs usavam esses computadores da mesma maneira que usavam os terminais, ou seja, o SGBD era centralizado e toda sua funcionalidade, execuo de programas aplicativos e processamento da interface do usurio eram executados em apenas uma mquina. Gradualmente, os SGBDs comearam a explorar a disponibilidade do poder de processamento no lado do usurio, o que levou arquitetura clienteservidor. Atualmente, existem vrias tendncias para arquitetura de Sistemas de Bancos de Banco de Dados, nas mais diversas direes. Essas tendncias sero discutidas a seguir. As arquiteturas possveis para um Sistema de Bancos de Dados podem ser classificadas em dois grandes grupos:
Arquitetura Centralizada e Arquitetura Distribuda. Na arquitetura centralizada os componentes do SBD residem no mesmo host (hardware). Os SBDs que utilizam essa arquitetura so denominados Sistema de Banco de Dados Centralizados.
Nas arquiteturas distribudas, busca-se distribuir alguns dos seguintes critrios: funo, controle e dados. Neste contexto, algumas arquiteturas de SBDs so possveis:
Sistema de Banco de Dados Cliente-Servidor Distribuio de funes do SGBD entre clientes e servidor. Sistema de Banco de Dados Paralelos Distribuio do controle de funes do DBMS entre diversos
sistemas computacionais. Sistema de Banco de Dados Distribudos Distribuio de dados atravs de diversos SBDs homogneos. Sistema de Banco de Dados Heterogneos Caracteriza-se pela distribuio de dados atravs de SBDs heterogneos e autnomos. Diversas abordagens foram propostas para SBDs Heterogneos, dentre elas destacam-se: Sistema de banco de dados mltiplos (MDBS Multiple Database System) Sistema de banco de dados federados (FDBS Federated Database System) Arquitetura de Mediadores
Sistema de Banco de Dados Mvel Caracteriza-se pela distribuio de funes e dados do SGBD
entre clientes e servidor em ambientes de computao mvel.
1.4. Exerccios 1. Descreva os componentes funcionais de um SGBD.

2. ARMAZENAMENTO DE DADOS
Um dos aspectos importantes que distinguem os sistemas de bancos de dados de outros sistemas a habilidade de um SBD de lidar de forma eficiente com grandes volumes de dados. Embora um sistema de banco de dados oferea uma viso de alto nvel dos dados armazenados, estes dados, em ltima instncia, precisam ser armazenados como bits em um ou mais dispositivos de
armazenamento. A grande maioria dos SBDs atuais armazena dados em discos magnticos. Quando os dados necessitam ser processados, o SBD copia os dados armazenados nos discos magnticos para a memria principal do computador. Alm disso, o SBD pode copiar os dados armazenados em disco para fitas e outros dispositivos de armazenamento, por questes de segurana (backup), e retornar esses dados para o disco magntico quando for necessrio. As caractersticas fsicas dos dispositivos de
armazenamento desempenham um papel importante no modo como os dados so armazenados. Por exemplo, o acesso aleatrio a um dado armazenado em disco muito mais lento que em memria principal. Contudo, a capacidade de armazenamento da memria principal muito menor que a de um disco rgido. Neste captulo discutiremos as principais tcnicas utilizadas pelos SBDs para representar, armazenar e recuperar dados.
2.1. Introduo Na maioria dos sistemas computacionais existem vrios tipos de armazenamento de dados. Esses meios fsicos de armazenamento so classificados pela velocidade com que os dados podem ser acessados, pelo custo e pela confiabilidade. A seguir, destacamos os principais tipos de meios fsicos de armazenamento. Esses meios 10
de armazenamento formam uma hierarquia de armazenamento que inclui as seguintes categorias:
Memria Interna do Processador Compreende pequeno conjunto de registradores de alta
velocidade. Esses registradores so utilizados como memria de trabalho para armazenamento temporrio de instrues e dados. Memria Cache Dispositivo de memria que funciona como dispositivo de armazenamento temporrio e intermedirio entre registradores e memria principal. Memria Principal (ou Memria Primria)
Utilizada no armazenamento de programas e dados que esto sendo operados pelo sistema computacional. uma memria relativamente rpida, cara, normalmente apresenta capacidade muito limitada e voltil, ou seja, seu contedo perdido em caso de queda de energia ou crash do sistema. Os endereos de memria so facilmente e rapidamente acessados pelo conjunto de instrues da CPU. A memria principal denominada RAM (Random Access Memory) ou Memria de Acesso Randmico (Aleatrio). Atualmente comeam a surgir tecnologias de bancos de dados armazenados inteiramente em memria principal. Memria Flash A memria flash difere da memria principal porque os dados sobrevivem falta de energia. A leitura de dados da memria flash apresenta aproximadamente a mesma velocidade da leitura de dados em memria principal. Porm, a escrita de dados na memria flash mais complicada. Para escrever sobre um endereo de memria que j foi escrito, necessrio apagar um bloco de memria inteiro ao mesmo tempo e, em seguida, gravar o novo contedo. Uma desvantagem da memria flash que ela s pode aceitar um nmero limitado de ciclos de apagamento, variando de 10.000 a 1 milho. A memria flash um tipo de memria EEPROM (Electrically-Erasable Programmable Read-Only Memory). 11
A memria flash ganhou popularidade como um substituto para os discos magnticos, para armazenar pequenos volumes de dados, em equipamentos portteis como cmeras fotogrficas digitais e pendrives USB (Universal Serial Bus). Memria Secundria (Armazenamento em Discos
Magnticos) O principal meio para armazenamento de dados em longo prazo o disco magntico. Este dispositivo apresenta uma capacidade de armazenamento maior que a memria principal. Em contrapartida, o acesso a dados em disco mais lento que na memria principal. Os discos magnticos apresentam um
armazenamento no voltil, ou seja, os dados armazenados sobrevivem a sobrevivem a faltas de energia e falhas do sistema. Assim, os discos magnticos so utilizados para armazenar dados de forma persistente (permanente), podendo armazenar programas aplicativos, grandes arquivos de dados, etc. Normalmente, o banco de dados inteiro armazenado em disco magntico. Logo, o SBD precisa mover os dados do disco para a memria principal, de modo que possam ser acessados. Posteriormente, os dados que foram modificados na memria principal precisam ser gravados
(atualizados) em disco. Logicamente, os discos magnticos tambm esto sujeitos a falhas e, portanto, dados podem ser perdidos, mas estas falhas normalmente ocorrem com muito menos freqncia do que as falhas do sistema. Memria Terciria Classe composta por dispositivos mais lentos, tais como: fitas magnticas e discos ticos (CD Compact Disk e DVD Digital Video Disk). Esse tipo de memria utilizado para armazenar um grande volume de dados (back-up). Nos discos pticos os dados so armazenados de forma ptica e so lidos por um laser. Sistemas de junkebox de discos pticos contm algumas unidades e vrios discos que podem ser carregados em uma das unidades automaticamente (por um brao mecnico). 12
O armazenamento em fita usado principalmente para backup e arquivamento de dados. Embora a fita magntica seja mais barata do que os discos pticos, o acesso aos dados muito mais lento, pois a fita precisa ser acessada seqencialmente desde o incio. Assim, o armazenado em fita chamado de armazenamento de acesso seqencial, enquanto o armazenamento em disco chamado de armazenamento de acesso direto. As fitas possuem uma alta capacidade de armazenamento, alm disso, podem ser removidas das unidades Logo, so (leitoras/gravadoras) bastante de fita para e o
transportadas.
adequadas
armazenamento de grandes volumes de dados, por longos perodos de tempo. Bibliotecas de fitas (jukeboxes) so usadas para manter colees de dados excepcionalmente grandes, como dados de satlites, que poderiam incluir at centenas de terabytes (1 terabyte = 1012 bytes), ou ainda vrios petabytes (1 petabyte = 1015 bytes) de dados.
Figura 2.1. Hierarquia de Meios de Armazenamento
Os diversos meios fsicos de armazenamento podem ser organizados em uma hierarquia (Figura 2.1), de acordo com sua velocidade (tempo de acesso) e seu custo. Os nveis mais altos so caros, mas so rpidos. Ao descemos na hierarquia, o custo por bit diminui, a capacidade de armazenamento aumenta e a velocidade diminui (ou seja, o tempo de aceso tambm cresce).
13
2.1.1. Caractersticas dos Meios Fsicos de Armazenamento Custo
(c):
custo
de
um
meio
fsico
de
armazenamento definido por:
c=CT/CA (dollars/bit)
onde, CT representa o custo total do sistema de memria completo cuja capacidade de armazenamento dado por CA. Tempo de Acesso (TA): Representa o tempo mdio necessrio para ler uma quantidade fixa de informao da memria, como por exemplo, uma palavra (word). O tempo de acesso utilizado como medida de performance memria. Taxa de acesso (bA): A taxa de acesso de um dispositivo de memria dada por 1/TA e representa a quantidade de palavras lidas por segundo. (desempenho) para dispositivos de
Mtodo de Acesso: (i) Random-access memory (RAM): Dispositivos de memria cujas posies podem ser acessadas em qualquer ordem. O tempo de acesso independente da localizao a ser acessada, uma vez que existe um mecanismo de acesso (leitura/gravao) para cada posio de memria.
14
(ii)
Serial-access
memory
(memria
de
acesso
seqencial): Dispositivos cujas posies s podem ser acessadas em seqncias pr-definidas. Este tipo de memria apresenta um nico mecanismo de acesso (leitura/gravao) compartilhado por vrias posies de memria. Alterabilidade: memria. (i) Read-only memory (ROM) (ii) Read-write memory (RWM) Persistncia de Armazenamento: Os processos fsicos envolvidos no armazenamento so algumas vezes instveis, podendo provocar a perda da informao armazenada aps certo perodo de tempo. A seguir discutimos algumas propriedades de memria de que podem destruir informao armazenada. (i) Destructive read-out DRO (leitura destrutiva): Em alguns dispositivos de armazenamento, o mtodo de leitura destri a informao armazenada. Em
Caracterstica
que
representa
capacidade de permitir a alterao do contedo de
dispositivos DRO, cada operao de leitura precisa ser seguida de uma operao de escrita para restaurar o estado original da memria. (ii) Memria dinmica: Certos dispositivos de
armazenamento apresentam a seguinte caracterstica: Um 1 armazenado torna-se um 0 devido a algum 15
processo
de
decaimento.
Por
exemplo,
muitos
dispositivos armazenam um 1 atravs de uma carga eltrica em um capacitor, com o passar do tempo, a carga armazenada tende a se descarregar (decair). Logo, esses dispositivos necessitam de um processo de recarga, denominado de refreshing. (ii) Volatilidade: Fenmeno no qual certos dispositivos de memria tm seu contedo destrudo por falhas eltricas ou crash de sistema. Distinguem-se dois tipos de memria: memria voltil e memria no voltil.
2.1.2. Armazenamento de Bancos de Dados Em geral, os bancos de dados envolvem grandes volumes de dados que devem ser armazenados por longos perodos de tempo. Durante sua existncia, os dados necessitam ser acessados e processados diversas vezes. Esse requisito contrasta com a noo de estruturas de dados transitrios (transient), que so armazenados somente por um tempo limitado, durante a execuo de um programa, por exemplo. Os bancos de dados, geralmente, necessitam ser armazenados de forma permanente (ou persistente) em memria secundria, ou seja, em discos magnticos, pelas seguintes razes: Freqentemente os bancos de dados so muito grandes para caberem inteiramente na memria principal; As circunstncias que causam a perda permanente de dados armazenados so menos do freqentes que em em armazenamento secundrio
armazenamento primrio. O custo de armazenamento por unidade de dado uma ordem de grandeza menor para discos magnticos do que para o armazenamento primrio;
16
Por estes motivos, espera-se que os discos magnticos continuem a ser a mdia mais utilizada para grandes bancos de dados nos prximos anos. Vale ressaltar que as tcnicas utilizadas para armazenar grandes volumes de dados em discos magnticos so importantes para os projetistas de bancos de dados e DBAs (Database Administrator), os quais devem conhecer as vantagens e desvantagens de cada tcnica de armazenamento, a fim de poderem projetar, implementar e operar, com eficincia, um banco de dados em um SGBD especfico. Em geral, os SGBDs fornecem diversas opes para a organizao dos dados, e o processo de projeto fsico envolve escolher, dentre as opes disponveis, as tcnicas de organizao que melhor se adqem aos requisitos de uma determinada aplicao. J os desenvolvedores (ou fabricantes) de SGBDs devem estudar as tcnicas de organizao de dados a fim que possam implement-las de forma eficiente e, assim, proporcionar boas opes aos DBAs e usurios de SGBDs.
2.2. Discos Magnticos Disco rgido, disco duro, (popularmente tambm winchester) ou HD (do ingls Hard Disk) a parte do computador onde so armazenadas as informaes, ou seja, a "memria permanente" propriamente dita. caracterizado como memria fsica, no-voltil, que aquela na qual as informaes no so perdidas quando o computador desligado. O disco rgido um sistema lacrado contendo discos de metal recobertos por material magntico onde os dados so gravados atravs de cabeas, e revestido externamente por uma proteo metlica que presa ao gabinete do computador por parafusos. nele que normalmente gravamos dados (informaes) e a partir dele lanamos e executamos nossos programas mais usados. Este mecanismo necessrio porque o contedo da memria RAM apagado quando o computador desligado. Desta forma, temos um meio de executar novamente programas e carregar arquivos contendo os dados da prxima vez em que o computador 17
for ligado. O disco rgido tambm chamado de memria de massa ou ainda de memria secundria. Um disco rgido possui uma ou vrias superfcies de gravao/leitura com uma estrutura de gravao composta por cilindros, trilhas e setores. Em cada superfcie de um disco, existem vrias trilhas que so arranjadas de forma concntrica (existem de 20 a 1500 trilhas por disco). Cada trilha est subdividida em setores. Um setor representa a menor unidade de informao que pode ser lida ou escrita no disco. Setores podem variar de 32 bytes at 4096 bytes. Mas, tipicamente, um setor possui 512 bytes e existem de 4 a 32 setores por trilha. Um cilindro definido como sendo um conjunto de trilhas verticalmente alinhadas e com mesmo dimetro. Os discos magnticos (superfcies) de um disco rgido so recobertos por uma camada magntica extremamente fina. Na verdade, quanto mais fina for esta camada de gravao, maior ser sua sensibilidade, e conseqentemente maior ser a densidade de gravao permitida por ela. Poderemos assim armazenar um volume maior de dados num disco do mesmo tamanho, criando HDs de maior capacidade.
18
2.2.1. Acessando uma Unidade de Disco O motor de rotao faz o disco girar a uma velocidade constante (60, 90 ou 120 rps). Cada superfcie do disco possui um cabeote de leitura/escrita. O cabeote est montado em um dispositivo chamado brao do disco. O brao movimenta-se transversalmente pelo disco para acessar as diferentes trilhas do disco. Uma unidade de disco possui geralmente um conjunto de discos (superfcies). Os cabeotes de leitura/escrita de todas as 19
superfcies de discos de uma unidade movimentam-se em conjunto (simultaneamente) e so acionadas pelo suporte do brao. A ttulo de exemplo suponha que os discos de uma unidade A apresentem 1000 trilhas cada um. Em um instante de tempo t todos os cabeotes acessam a mesma posio nos diferentes discos (superfcies). Assim, os cabeotes acessam trilhas de diferentes discos ou superfcies, mas que apresentam mesmo dimetro, ou seja, pertencem ao mesmo cilindro (como por exemplo, o conjunto de todas as trilhas 450 dos discos da unidade A). Por este motivo, procura-se otimizar o acesso a disco armazenando-se os dados de um mesmo arquivo em um mesmo cilindros. A superfcie de gravao dos discos (ou pratos) composta de materiais sensveis ao magnetismo (geralmente, xido de ferro). O cabeote de leitura e gravao manipula as molculas desse material atravs de seus plos. Para isso, a polaridade das cabeas muda numa freqncia muito alta: quando est positiva, atrai o plo negativo das molculas e vice-versa. De acordo com essa polaridade que so gravados os bits (0 e 1). No processo de leitura de dados, o cabeote simplesmente "l" o campo magntico gerado pelas molculas e gera uma corrente eltrica correspondente, cuja variao analisada pela controladora do HD para determinar os bits.
2.2.2. Medidas de Desempenho de Discos Tempo de procura (TP) ou Tempo de Busca ou Seek Time: Tempo gasto para posicionar o brao sobre a trilha correta. Tempo mdio de latncia rotacional (TL): Tempo mdio necessrio para que o setor desejado passe pelo cabeote de leitura/escrita. O TL definido como 1/2 do tempo de uma rotao completa. Assim, se r a taxa de rotaes/segundo, ento TL=(2r)-1.
20
Taxa de transferncia de dados (TTr): Taxa na qual os dados so lidos ou armazenados por segundo. Se N a capacidade das trilhas em palavras, ento TTr= rN. Tempo de transferncia de dados de um setor (TT): Tempo (segundos) necessrio para transferir dados de um setor. Se n o tamanho (em palavras) de um setor, ento TT= n(rN)-1. Tempo de acesso a um setor (TA): Tempo gasto desde um pedido de leitura/escrita at o fim da transferncia de dados. A frmula para determinar o tempo de acesso de um disco dada por: TA=TP + TL + TT TA= TP + (2r)-1 + n(rN)-1 O acesso a disco extremamente lento. Logo, o custo de acesso a disco domina o custo de execuo das consultas executadas pelo SGBD.
2.3. Tcnicas RAID RAID a sigla para Redundant Array of Independent Disks. Sua definio em portugus seria "Matriz Redundante de Discos Independentes". Trata-se de uma tecnologia que combina vrios discos rgidos (HD) para formar uma nica unidade lgica. Em outras palavras, um conjunto de HDs que funcionam como se fossem um s. Isso permite ter uma alta tolerncia contra falhas, pois se um disco tiver problemas, os demais continuam funcionando. O RAID uma tecnologia consolidada, tendo sido proposta por pesquisadores da Universidade de Berkesley, na California (EUA) no final da dcada de 1980. Para que o RAID seja formado, preciso utilizar pelo menos 2 HDs. O sistema operacional, neste caso, enxergar os discos como uma unidade lgica nica. Quando h gravao de dados, os 21
mesmos se repartem entre os discos do RAID (dependendo do nvel). Com isso, alm de garantir a disponibilidade dos dados em caso de falha de um disco, possvel tambm equilibrar o acesso s informaes, de forma que no haja "gargalos". As tcnicas RAID so baseadas em dois mecanismos principais: o espelhamento e a distribuio paralela de dados. O espelhamento assegura confiabilidade (atravs da redundncia dos dados), contudo uma tecnologia extremamente cara. A distribuio paralela de dados possibilita altas taxas de transferncia de dados, porm no garante confiabilidade. Assim, as tcnicas RAID buscam combinar diferentes graus redundncia. de distribuio de dados e de
2.3.1. Os nveis de RAID A tecnologia RAID funciona de vrias maneiras. Tais maneiras so conhecidas como "nveis de RAID".
RAID nvel 0 - Este nvel tambm conhecido como "Striping" ou "Fracionamento" e consiste em uma distribuio de paralela e no-redundante dos blocos que compem um arquivo. Nele, os dados so divididos em pequenos segmentos e distribudos entre os discos. Este nvel no oferece tolerncia a falhas, pois no existe redundncia. Isso significa que uma falha em qualquer um dos HDs pode ocasionar perda de informaes. Por essa razo, o RAID 0 usado para melhorar a performance do computador, uma vez que a distribuio dos dados entre os discos proporciona grande velocidade na gravao e leitura de informaes. Quanto mais discos houver, mais velocidade obtida. Isso porque, se os dados fossem gravados em um nico disco, esse processo seria feito de forma seqencial.
22
As principais caractersticas do RAID nvel 0 so: Projeto simples Fcil de implementar No apresenta overhead com clculos de paridade Requer pelo menos dois discos A perda de um disco implica na perda total dos dados I/O performance is greatly improved by spreading the I/O load across many channels and drives Should never be used in mission critical environments
RAID nvel 1 - Tambm conhecido como "Mirroring" ou "Espelhamento", o RAID 1 funciona adicionando HDs paralelos aos HDs principais existentes no computador. Assim, se, por exemplo, um computador possui 2 discos, pode-se aplicar mais um HD para cada um, totalizando 4. Os discos que foram adicionados trabalham como uma cpia do primeiro. Assim, se o disco principal recebe dados, o disco adicionado tambm os recebe. Da o nome de 23
"espelhamento", pois um HD passa a ser uma cpia praticamente idntica do outro. Dessa forma, se um dos HDs apresentar falha, o outro imediatamente pode assumir a operao e continuar a disponibilizar as informaes. A conseqncia neste caso, que a gravao de dados mais lenta, pois realizada duas vezes. No entanto, a leitura dessas informaes mais rpida, pois pode-se acessar duas fontes de dados distintas. Por esta razo, uma aplicao muito comum do RAID 1 seu uso em servidores de arquivos. O RAID 1 utiliza uma organizao de discos com distribuio paralela (baseada em blocos) e redundncia
(implementada atravs de replicao).
RAID nvel 2 - Este tipo de RAID adapta o mecanismo de deteco de falhas em discos rgidos para funcionar em memria. Assim, todos os discos da matriz ficam sendo "monitorados" pelo mecanismo. Atualmente, o RAID 2 pouco usado, uma vez que praticamente todos os discos rgidos novos saem de fbrica com mecanismos de deteco de falhas implantados. O RAID 2 utiliza uma organizao de discos com distribuio paralela (baseada em bytes) e redundncia implementada atravs de bits de correo, os quais podem ser implementados atravs de bit de paridade. 24
RAID nvel 3 - Neste nvel, os dados so divididos entre os discos da matriz, exceto um, que armazena informaes de paridade. Assim, todos os bytes dos dados tem sua paridade (acrscimo de 1 bit, que permite identificar erros) armazenada em um disco especfico. Atravs da verificao desta informao, possvel assegurar a integridade dos dados, em casos de recuperao. Por isso e por permitir o uso de dados divididos entre vrios discos, o RAID 3 consegue oferecer altas taxas de transferncia e confiabilidade das informaes. Para usar o RAID 3, pelo menos 3 discos so necessrios.
25
RAID nvel 4 - Este tipo de RAID, basicamente, divide os dados entre os discos, sendo que um exclusivo para paridade. A diferena entre o nvel 4 e o nvel 3, que em caso de falha de um dos discos, os dados podem ser reconstrudos em tempo real atravs da utilizao da paridade calculada a partir dos outros discos, sendo que cada um pode ser acessado de forma independente. O RAID 4 indicado para o armazenamento de arquivos grandes, onde necessrio assegurar a integridade das informaes. Isso porque, neste nvel, cada operao de gravao requer um novo clculo de paridade, dando maior confiabilidade ao armazenamento (apesar de isso tornar as gravaes de dados mais lentas). O RAID 4 no apresenta distribuio, ou seja, os blocos so armazenados da mesma forma que em discos comum. Assim, uma 26
leitura de bloco acessa somente um disco. Isso permite que outras solicitaes sejam processadas pelos outros discos de forma paralela. A redundncia implementada atravs de blocos de paridade. Um disco redundante (disco de paridade) armazena todos os blocos de paridade. Neste disco, o bloco i armazena bit de paridade dos blocos i de todos os discos de dados.
O RAID nvel 4 utiliza um mecanismo de paridade de blocos entrelaados. Assim, caso um disco falhe, o bloco de paridade mais
27
os blocos dos discos em funcionamento so utilizados para recuperar os blocos do disco que falhou. O RAID 4 apresenta ainda as seguintes caractersticas: RAID Level 4 requires a minimum of 3 drives to implement; Block Read transfer rate equal to that of a single disk ; A taxa de transferncia de dados para cada acesso menor, mas mltiplos acessos de leitura podem ser processados em paralelo, levando a uma taxa geral de I/O mais alta; Uma nica escrita requer quatro acessos ao disco: dois para ler os dois blocos (dados e paridade) antigos e dois para gravar os dois blocos;
RAID nvel 5 - Este muito semelhante ao nvel 4, exceto o fato de que a paridade no fica destinada a um nico disco, mas a toda a matriz. Isso faz com que a gravao de dados seja mais rpida, pois no necessrio acessar um disco de paridade em cada gravao. Apesar disso, como a paridade distribuda entre os discos, o nvel 5 tende a ter um pouco menos de performance que o RAID 4. O RAID 5 o nvel mais utilizado e que oferece resultados satisfatrios em aplicaes no muito pesadas. Este nvel precisa de pelo menos 3 discos para funcionar. O RAID nvel 5 apresenta distribuio de dados (baseada em blocos). A redundncia implementada atravs de blocos de paridade, onde se utiliza um bloco de paridade para cada bloco armazenado nos discos de dados. Assim, o RAID nvel 5 conhecido como mecanismo de paridade distribuda de blocos entrelaados. Os blocos de dados e de paridade so distribudos nos N+1 discos, enquanto que no RAID nvel 4, os dados so armazenados nos N discos e o bloco de paridade armazenado em um disco separado. 28
Considere o seguinte exemplo. Para cada bloco i em um conjunto de 5 discos o bloco de paridade de i armazenado no disco (i mod 5) +1, enquanto os i-simos blocos dos outros quatro discos armazenam os dados do bloco i. Assim, o bloco de paridade para um bloco i armazenado em um disco diferente dos discos que armazenam i. Caso um disco falhe, o bloco de paridade mais os blocos dos discos em funcionamento so utilizados para recuperar os blocos do disco que falhou. 29
O RAID 5 apresenta ainda as seguintes caractersticas: RAID Level 5 requires a minimum of 3 drives to implement; Highest Read data rate/Medium Write data rate; More difficult to rebuild in the event of a disk failure; RAID nvel 6 - Semelhante ao nvel 5 (mas, usa redundncia P + Q), ou seja, armazena informaes adicionais para recuperar dados no caso de falha em mais de um disco. Assim, garante maior grau de confiabilidade que o nvel 5. Contudo, o RAID 6 requer um mnimo de quatro discos para ser implementado.
RAID nvel 10 ou 1 + 0 - Em um RAID 1+0 os dados so primeiramente espelhados, e para cada espelho h a segmentao sobre vrios discos.
30
Este nvel de RAID apresenta as seguintes caractersticas: RAID Level 10 requires a minimum of 4 drives to implement; Very expensive / High overhead; All drives must move in parallel to proper track lowering sustained performance;
RAID 0 + 1 - O RAID 0 + 1 uma combinao dos nveis 0 (Striping) e 1 (Mirroring), onde os dados so divididos entre os discos para melhorar o rendimento, mas tambm utilizam outros discos para duplicar as informaes. Assim, possvel utilizar o bom rendimento do nvel 0 com a redundncia do nvel 1. No entanto, necessrio pelo menos 4 discos para montar um RAID desse tipo. Tais caractersticas fazem do RAID 0 + 1 o mais rpido e seguro, porm o mais caro de ser implantado. A ilustrao abaixo ilustra este tipo de RAID:
31
As principais caractersticas do RAID 0 + 1 so: RAID Level 0+1 requires a minimum of 4 drives to implement; Very expensive / High overhead; All drives must move in parallel to proper track lowering sustained performance; Excellent solution for sites that need high performance but are not concerned with achieving maximum reliability (confiabilidade/integridade);
2.3.2. Tipos de RAID Existem 2 tipos de RAID, sendo um baseado em hardware e o outro baseado em software. Cada uma possui vantagens e desvantagens. O primeiro tipo o mais utilizado, pois no depende de sistema operacional (pois estes enxergam o RAID como um nico disco grande) e so bastante rpidos, o que possibilita explorar integralmente seus recursos. Sua principal desvantagem ser um tipo caro inicialmente. O RAID baseado em hardware utiliza 32
dispositivos denominados "controladores RAID", que podem ser, inclusive, conectados em slots PCI da placa-me do computador. J o RAID baseado em software no muito utilizado, pois apesar de ser menos custoso, mais lento, possui mais dificuldades de configurao e depende do sistema operacional para ter um desempenho satisfatrio. Este tipo ainda fica dependente do poder de processamento do computador em que utilizado.
2.4. Armazenamento Tercirio.......................................... 49 2.5. Gerenciamento de Arquivos ........................................ 2.6. Organizao de Arquivos .............................................
2.7. Exerccios
1. Tanto a memria principal quanto o disco possibilitam o acesso direto a uma determinada localizao (pgina). Entretanto, em mdia, o acesso a memria principal mais rpido. Qual a outra diferena fundamental entre esses dispositivos (do ponto de vista do tempo necessrio para acessar uma determinada pgina) ? 2. Caso voc tenha um arquivo que freqentemente percorrido seqencialmente, qual a melhor maneira de armazenar as pginas deste arquivo em um disco ? 3. Considere um disco com setores de 512 bytes (tamanho), 2.000 trilhas por superfcie, 50 setores por trilha, 5 pratos (discos fsicos) de dupla face e tempo de busca de 10 ms. Qual a capacidade de uma trilha em bytes ? Qual a capacidade de uma superfcie ? Qual a capacidade de um disco (prato) ? Quantos cilindros existem em um disco ? Fornea exemplos de tamanhos de blocos vlidos. Pode existir um bloco de 256 bytes ? Podemos ter blocos de 2048 bytes ? e de 51.200 ? Se a taxa de rotao for de 5.400 rpm (rotaes por minuto), qual o tempo mximo de espera ? Assumindo-se que uma trilha de dados pode ser transferida a cada rotao, qual a taxa de transferncia ?
33
4. Considere a especificao do disco da questo anterior, e suponha que os blocos utilizados so de 1024 bytes. Suponha tambm que um determinado arquivo que contm 1000.000 registros de 100 bytes cada deve ser armazenado no disco em questo, e que os dados de um registro devem ser armazenados em um nico bloco. Quantos registros podem ser armazenados em um bloco ? Quantos blocos so necessrios para armazenar o arquivo por inteiro ? Quantos registros de 100 bytes cada podem ser armazenados usando este disco ? Qual o tempo necessrio para ler um arquivo contendo 100.000 registros de 100 bytes cada seqencialmente ? Qual o tempo necessrio para ler um arquivo contendo 100.000 registros de 100 bytes cada em uma determinada ordem randmica ?
34

3. GERENCIAMENTO DE BUFFER
O gerenciador de buffer o subsistema responsvel pela alocao de memria onde so armazenados os blocos (pginas) de informaes que compem um banco de dados e que so lidos/gravados nos discos rgidos (armazenamento secundrio). O ideal seria que todas as informaes que um banco de dados manipula estivessem na memria principal do computador, como isso no possvel, pois as memrias so pequenas e caras, necessrio gerenciar a alocao do espao disponvel na memria principal para o armazenamento dos blocos que compem um banco de dados. O buffer a parte da memria principal disponvel para o armazenamento de cpias dos blocos (pginas) de um banco de dados. H sempre uma cpia de cada bloco que mantida no disco rgido. Contudo, para um determinado bloco possa ser efetivamente utilizado (processado) ele necessita estar armazenado na memria principal (mais precisamente no buffer). Assim, a cpia de um determinado bloco armazenada em disco pode ser uma verso mais antiga do que a verso da cpia do mesmo bloco armazenada do buffer.
3.1. Sistema de Memria Virtual Quando uma aplicao solicita uma informao do banco e dados, o SGBD antes de busc-la no disco, verifica se ela no se encontra em algum bloco no buffer, caso afirmativo, o SGBD envia aplicao o endereo do bloco na memria. Se o bloco no estiver no buffer, o gerenciador alocar espao no buffer para o bloco requisitado, retirando algum outro bloco, pra liberar espao e far a transferncia do bloco requisitado do disco para a memria principal 35
e enviar o endereo para a aplicao que requisitou a informao. O bloco retirado do buffer reescrito no disco apenas se ele foi modificado desde a ltima vez que foi escrito no disco. O gerenciador de buffer funciona de maneira anloga ao gerenciador de memria virtual de um sistema operacional. Uma diferena que um banco de dados pode ser muito maior que a memria virtual de um sistema computacional qualquer. Outra diferena que as tcnicas utilizadas para gerenciamento do buffer so mais sofisticadas que as de gerenciamento de memria virtual. Mais formalmente, um sistema de memria virtual pode ser definido como um sistema de armazenamento hierrquico, com no mnimo dois nveis de memria. A maioria dos sistemas de memria virtual implementam uma hierarquia de dois nveis, compreendendo: Uma memria principal M1 (Buffer), cuja capacidade de armazenamento representada por S1 e cujo custo dado por C1. O tempo de acesso memria M1 dado por TA1. Uma memria secundria M2 (Disco), cuja
capacidade de armazenamento representada por S2 e cujo custo dado por C2. O tempo de acesso memria M2 dado por TA2. Sabe-se que: S2 >> S1 ; C1 > C2 ; TA1 < TA2 O objetivo de um sistema de memria virtual dar a iluso ao usurio do SGBD que existe uma nica memria principal com grande capacidade, permitir um compartilhamento eficiente do espao de memria entre diferentes usurios (Reentrncia), apresentar altas taxas de acesso a baixo custo de armazenamento por bit e otimizar acesso ao banco de dados. A reentrncia consiste na capacidade de um cdigo de programa (cdigo reentrante) ser compartilhado, na memria, por diversos usurios, existindo, deste modo, apenas uma cpia carregada. Logicamente, este cdigo no pode ser alterado e cada 36
usurio pode estar em um ponto diverso do programa, manipulando seus prprios dados.
3.2. O Gerenciador de Buffer O gerenciador de buffer funciona com base no seguinte princpio: toda informao armazenada em M1, em qualquer instante, tambm est armazenada em M2. Contudo, o inverso no verdade. O SGBD comunica-se diretamente com M1 e M1 comunica-se com M2. Caso a informao desejada pelo SGBD no se encontre em M1, o gerenciador de buffer realiza uma realocao de armazenamento apropriada de M1, ou seja, carrega de M2 para M1 a informao requerida. Desta forma, um gerenciador de buffer eficiente aquele em que a Informao desejada deve ser encontrada em M1 com uma taxa de freqncia tima. O desempenho (performance) de um gerenciador de buffer medida com base na sua taxa de acerto (H). A taxa de acerto definida pela probabilidade que os endereos gerados pelo SGBD refiram-se a informao j alocada em M1. A taxa de acerto determinada experimentalmente como descrito a seguir: um conjunto de programas (consultas) executado. Os nmeros de referncias de endereos satisfeitas por M1 e M2 so registrados (contabilizados). Essas quantidades so denotadas por N1 e N2. Assim, N1 a quantidade de vezes que a informao (bloco/pgina) desejada j se encontrava em M1, enquanto N2 a quantidade de vezes que a informao (bloco/pgina) desejada teve que ser levada (copiada) do disco (M2) para o buffer (M1). A taxa de acerto calculada aplicando-se a frmula:
H= N1 / (N1+N2) Assim, a taxa de acerto tima deve tender a 1. J taxa de no acerto definida por 1-H.
37
Considere que TA1 e TA2 sejam os tempos de acesso de M1 e M2, respectivamente. O tempo mdio para o SGBD acessar um dado no sistema de memria dado por:
TA = H.TA1 + (1-H).TA2
(1)
Caso um determinado bloco (pgina) no seja encontrado em M1, uma pgina do banco de dados (em disco) contendo a palavra transferida para M1. Seja TB o tempo de transferncia de uma pgina do disco para o buffer, temos que:
TA2 = TB + TA1 Assim, substituindo (2) em (1), temos:
(2)
TA = TA1 + (1-H).TB A razo (r) do tempo de acesso de um sistema de memria virtual com dois nveis definida como:
r= TA2 / TA1 A eficincia de acesso (e) de um sistema de memria virtual determinada pela equao:
e= 1 / [r+(1-r).H]
O objetivo obter valores para e prximos a 1.Para isso necessrio que H seja prximo a 1.
38
3.3. Mecanismo de Paginao em SGBDs A operao mais importante em qualquer sistema de memria virtual a troca de blocos de informao entre os nveis de memria. Esta operao denominada paginao (ou swapping). Essa troca ocorre de acordo com a demanda de processamento. Por Demanda de Paginao entende-se a propriedade que indica quando uma operao de paginao deve ocorrer. A Poltica de Alocao diz respeito ao mtodo utilizado para determinar o local (endereo) da memria principal, onde uma nova pgina deve ser carregada. Existem dois tipos de alocao: Alocao esttica e Alocao Dinmica. Na alocao esttica, cada pgina de dados est ligada a uma regio fixa da memria principal. J na alocao dinmica, a regio de memria principal na qual uma pgina K carregada varivel. A alocao dinmica pode ser ainda classificada em preemptiva e no preemptiva. Na alocao dinmica no preemptiva, a pgina a ser carregada s pode ser alocada em um espao vazio da memria principal (buffer), enquanto na alocao dinmica preemptiva a pgina a ser carregada pode ser alocada em um espao ocupado por outra pgina K. Neste caso, a pgina K deve ser re-alocada em outro endereo ou removida totalmente da memria (e copiada para disco).
3.4. Polticas de Alocao de Pginas Quando no h mais lugar disponvel no buffer, um bloco deve ser removido do buffer antes que um novo bloco possa ser copiado para ele. O objetivo principal de uma poltica (ou estratgia) de substituio de pginas (blocos) em um buffer minimizar os acessos a disco. As principais polticas de alocao dinmica preemptiva so:
39
FIFO (First-In First-Out): A pgina a ser carregada alocada na regio de buffer ocupada pela pgina carregada menos recentemente no buffer.
LRU (Least Recently Used): A pgina a ser carregada alocada na regio de buffer ocupada pela pgina acessada mais remotamente (tempo).
MRU (Most Recently Used): A pgina a ser carregada alocada na regio de buffer ocupada pela pgina acessada mais recentemente.
Para programas de propsito geral, como um sistema operacional, por exemplo, no possvel prever precisamente quais blocos sero referenciados. Por isso, tais sistemas, em geral, utilizam o padro de referncias passadas como uma forma de prever as referncias futuras. Entretanto, um sistema de banco de dados capaz de prever o modelo de futuras referncias de forma mais precisa que um sistema operacional. A solicitao de um usurio ao sistema de banco de dados envolve diversos passos. O sistema de banco de dados capaz de determinar antecipadamente quais blocos sero necessrios por meio da verificao de cada um dos passos necessrios para executar a operao solicitada pelo usurio. Assim, diferentemente dos sistemas operacionais, que devem se basear no passado para prever o futuro, os sistemas de bancos de dados podem ter informaes relativas ao futuro prximo. Os SGBDs costumam utilizar os algoritmos LRU (Least Recently Used) ou Clock2 (Two Round Clock) para gerenciar o buffer na memria principal. Contudo, o esquema LRU, em banco de dados, mais elaborado que em sistemas operacionais, pois o sistema de banco de dados capaz de determinar antecipadamente quais blocos sero necessrios por meio da verificao de cada um dos passos necessrios para executar a operao solicitada pelo usurio. Para ilustrar, consideremos a seguinte expresso da lgebra relacional:
40
Credor
Cliente
Suponha que o algoritmo de juno a ser utilizado o NestedLoop Join (mostrado a seguir). Assuma tambm que as duas relaes deste exemplo sejam armazenadas em arquivos
separados. For each tupla b de credor do For each tupla c de cliente do If b[nome_cliente] = c[nome_cliente] then Begin Seja x definida da seguinte forma: X[nome_cliente]:= b[nome_cliente] X[numero_emprestimo]:= b[numero_eprestimo] X[rua_cliente]:= b[rua_cliente] X[cidade_cliente]:= b[cidade_cliente] Inclua a tupla x como parte do resultado de credor x cliente End End End
Porm, as polticas de LRU e clock2 nem sempre constituem a melhor estratgia para substituio de pginas em um sistema de banco de dados. Um dos principais cenrios que evidenciam este fato ocorre quando vrios usurios requisitam a leitura seqencial (scan) de um conjunto de dados (uma tabela, por exemplo). Considere a seguinte situao. Suponha que o buffer pool possua 10 pginas, e que o arquivo a ser lido contm 10 ou menos pginas. Assuma, por simplicidade, que no existe concorrncia na requisio das pginas, durante o primeiro scan sobre o arquivo todas as pginas sero levadas do disco para o buffer pool (executa operaes de I/O). As operaes de scan subseqentes iro
sempre encontrar a pgina desejada no buffer. Por outro lado, suponha que o arquivo, a ser lido seqencialmente, possui 11 pginas (o qual um nmero maior que o nmero de pginas disponveis no buffer pool). Usando LRU, todas as operaes de scan (sobre o arquivo) tero que ler todas as pginas do arquivo do 41
disco e levar para o buffer pool (operao de I/O). Nesta situao, chamada sequential flooding, LRU a pior estratgia para substituio de pginas. Podemos observar, para este exemplo, que uma vez que uma tupla de Credor tenha sido processada, a tupla no ser necessria novamente. Portanto, uma vez que o processamento de um bloco inteiro de tuplas de Credor seja completado, este bloco no mais necessrio na memria. Entretanto, como ele foi usado
recentemente ele ainda permanecer no buffer por um longo perodo de tempo. O gerenciador de buffer deveria ser instrudo a liberar o espao ocupado por um bloco de credor assim que a ltima tupla tenha sido processada. Essa estratgia de gerenciamento de buffer chamada de arremesso imediato. Agora considere os blocos contendo as tuplas de Cliente. Precisamos analisar cada bloco de tuplas de Cliente uma vez para cada tupla da relao Credor. Assim, quando o processamento de um bloco de tuplas de Cliente concludo, este no ser mais necessrio at o processamento da prxima tupla de Credor, antes disso todos os demais blocos de Cliente devero ser lidos novamente. Entretanto, como este bloco foi usado recentemente ele ainda permanecer no buffer por certo perodo de tempo, o que inteiramente desnecessrio. Na verdade, a estratgia tima para a substituio de pginas neste exemplo a MRU. Para que esta estratgia funcione corretamente para o nosso exemplo, o sistema deve imobilizar (fixar) o bloco cliente sendo correntemente processado. Assim que a ltima tupla deste bloco tiver sido processada, o bloco liberado e ele se tornar o bloco mais recentemente utilizado. Sendo, portanto, o prximo a ser retirado do buffer. De forma similar este mecanismo se aplica aos blocos da relao Credor. Surpreendentemente, a estratgia mais utilizada em sistemas de banco de dados a LRU. A poltica FIFO tambm possui situaes em que comete srios equvocos. Um bloco usado repetidamente, digamos o bloco raiz de um ndice de uma rvore B, eventualmente se tornar o bloco 42
mais antigo em um buffer poll. Logo, ele ser gravado mais uma vez em disco. Entretanto, pouco tempo depois ele ter que ser lido novamente e transferido do disco para o buffer (por exemplo, quando o ndice for utilizado novamente). Uma soluo para este problema fixar a raiz, ou seja, indicar que a pgina em que esta se encontra no pode ser removida do buffer. Estes blocos so ditos fixados. A estratgia ideal de substituio de pginas em bancos de dados requer o conhecimento das operaes de banco de dados em processamento. No se conhece uma nica estratgia que manipule bem todos os possveis cenrios. De fato, surpreendentemente, um grande nmero de SGBDs utiliza o LRU a despeito das falhas dessa estratgia. A estratgia utilizada por um gerenciador de buffer para a substituio de blocos influenciada por outros fatores alm do tempo no qual o bloco ser referenciado novamente. Se o sistema est processando solicitaes de vrios usurios concorrentemente, o subsistema de controle de concorrncia pode ter de atrasar algumas solicitaes para assegurar a preservao da consistncia do banco de dados. Se o gerenciador de buffer receber informaes do subsistema de controle de concorrncia indicando quais solicitaes esto sendo atrasadas, ele pode usar estas informaes para alterar sua estratgia de substituio de blocos.
Especificamente, os blocos necessrios para as solicitaes ativas (no atrasadas) podem ser retidos no buffer s custas de blocos necessrios para as solicitaes atrasadas. O subsistema de recuperao de falhas impe restries rigorosas substituio de blocos. Se um bloco tiver sido modificado, o gerenciador de buffer no tem permisso de escrever de volta no disco a nova verso do bloco no buffer, uma vez que isso destruiria a verso antiga. Em vez disso, o gerenciador de buffer deve obter permisso do subsistema de recuperao de falhas antes de escrever um bloco de volta. O subsistema de recuperao de falhas pode demandar que determinados blocos tenham sua sada 43
forada antes de dar permisso para que o gerenciador de buffer remova o bloco solicitado. Adicionalmente utilizao do conhecimento que o sistema deve ter sobre a solicitao sendo processada, o gerenciador de buffer pode utilizar informaes estatsticas relativas probabilidade de que uma solicitao ir referenciar uma relao em particular. O dicionrio de dados uma das partes do banco de dados mais freqentemente acessadas. Assim o gerenciador de buffer no deveria tentar remover blocos do dicionrio de dados da memria principal a no ser que outros fatores determinem que isso seja feito. Como um ndice pode ser acessado mais freqentemente que o prprio arquivo, o gerenciador de buffer, em geral, no deveria remover os blocos de ndices da memria principal se houver outras alternativas.
3.5. Exerccios 1. Considere um mecanismo de buffer com dois nveis. A rea de buffer em memria principal M1 apresenta tempo de acesso igual a 10-7s e taxa de acerto igual a 0.7. A memria M2 est montada atravs de uma unidade de disco com as seguintes caractersticas: (a) Palavra de 64 bits (b) Velocidade de rotao do disco: 5400 r/min (c) Capacidade de armazenamento de cada trilha: 64000 bits (d) Capacidade de cada setor de uma trilha: 64 bits Suponha que o sistema apresenta um barramento com velocidade de transmisso extremamente alta. Portanto, o tempo gasto para transferir dados atravs do barramento da unidade de disco at a memria principal desprezvel. Considere o tempo de procura igual a 10-6s. Calcule a eficincia de acesso desse sistema e indique se este valor est prximo ou no do valor ideal. Justifique sua resposta.
44
Processamento de Transaes
Esta
unidade
discute
em
detalhes
problema
do
processamento de transaes em bancos de dados. definido precisamente os conceitos do modelo convencional de transaes. Noes de transao e schedules so discutidas e examinadas. O critrio de corretude convencional, denominado de serializabilidade, descrito. Vantagens e desvantagens deste modelo so apontadas e discutidas. Abordamos tambm a relao entre corretude e confiabilidade de schedules.
45
SUMRIO
UNIDADE II PROCESSAMENTO DE TRANSAES
1. INTRODUO 1.1. O Problema da Concorrncia em BDs ..................... 00 1.2. Conceito de Transao............................................. 00 1.3. Estados de uma transao........................................00 1.4. Propriedades da transao....................................... 00
2. EXECUES CONCORRENTES 2.1. Acessos Concorrentes.............................................. 00 2.2. Controle de Concorrncia......................................... 00 2.3. Reviso..................................................................... 00
3. ISOLAMENTO DE TRANSAES 3.1. Transaes Sequenciais........................................... 00 3.2. Execuo Correta de Transaes Concorrentes...... 00 3.2.1. Equivalncia de estado final.......................... 00 3.2.2. Equivalncia de viso.................................... 00 3.2.3. Equivalncia de conflito................................. 00 3.3. Serializabilidade........................................................ 00 3.4. Grafo de serializao de um schedule S................... 00 3.5. Prefixo de um Schedule............................................ 00 3.6. Exerccios.................................................................. 00
4. CONFIABILIDADE DE SCHEDULES 4.1. Corretude x Confiabilidade....................................... 00 4.2. Schedule Recupervel............................................... 00 4.3. Schedule que Evita Abort em Cascata.......................00 4.4. Schedule Preciso (Strict)............................................ 00 46
4.5. Exerccios............................................. 00
47

1. INTRODUO
Aps o acompanhamento dessa lio o aluno ser capaz de entender como tratar as questes referentes a transaes, tipos de isolamento e modos de bloqueios.
1.1. O Problema da Concorrncia em BDs Os SGBDs so sistema multiusurio, geralmente. Desta forma, a informao contida nele pode ser acessada e modificada de maneira concorrente. Esta situao pode levar o banco de dados a um estado inconsistente (por exemplo, redundncia de dados). Para que possamos entender melhor esta situao, vamos definir que todo banco de dados em seu estado inicial, est em um estado consistente, ou seja, todas as suas restries de consistncia esto preservadas. A mudana de estado (figura 1) do Banco de Dados (BD) se d no instante em que os dados do mesmo sofrem alguma alterao. Sendo assim, as operaes de incluso, excluso e alterao de dados, alteram o estado do BD e necessrio que qualquer alterao de estado do BD, leve o mesmo a um estado sempre consistente.
Figura 1. Mudana de estados do BD
O SGBD deve oferecer mecanismos para esse controle sem prejudicar o acesso concorrente aos dados, pois um SGBD multiusurio tem que permitir o acesso simultneo de vrios usurios 48
base de dados. O SGBD deve oferecer um controle de concorrncia para garantir que o resultado de vrias modificaes base de dados seja correto, como no caso de uma aplicao que controla reservas de vos. desta necessidade que surge o princpio do controle de concorrncia que limita as leituras e modificaes simultneas disparadas ao mesmo dado por diferentes usurios. A ideia de acesso concorrente ou multi-usurios considera que operaes de um programa podem ser executadas entre duas operaes de outro programa. Como vimos, estas operaes causam transies de estado no BD e caso estas transies de estado gerem estados inconsistentes do BD, ento elas so ditas transies incorretas. (Figura 2) Portanto, o estado de um banco de dados representa uma viso instantnea do mundo, refletindo apenas seus aspectos estticos. Entretanto, as mudanas que ocorrem em um mundo real devem ser refletidas no banco de dados. Essas mudanas so capturadas pelo conceito de transio de estados. Uma transio de estado representa o salto de um determinado estado para outro. Estas transies so realizadas pelos programas aplicativos que contm operaes de leitura e escrita sobre os objetos do banco de dados. A figura 2 apresenta o caso de transies incorretas. Acompanhando a execuo de acordo com a linha do tempo (seta verde, de cima para baixo), vemos que o programa 1 inicia sua execuo realizando duas leituras de dados (select) e uma atualizao (update) antes do programa 2 iniciar suas operaes. Quando o programa 2 realiza suas consultas base de dados, verificando os saldos das contas 12 e 13, respectivamente, neste instante o programa 1 ainda no alterou o valor do saldo da conta 13. Desta forma quando o programa 2 mostrar os valores dos saldos, a atualizao feita pelo programa 1 no saldo da conta 13 no aparecer, provocando uma inconsistncia no resultado da consulta.
49
medida que mais usurios comeam a compartilhar os mesmos dados, aqueles sistemas que no tiveram um planejamento adequado esto sujeitos a apresentar problemas de desempenho, deadlocks e bloqueios que diminuem a concorrncia no acesso aos dados.
Programa-1 Select saldo into :valor1 From t_conta where num_conta = 12 Select saldo into :valor2 From t_conta where num_conta = 13 valor1 = valor1 + 500 update t_conta set saldo = :valor1 where num_conta = 12
Programa-2
Select saldo into :valor1 From t_conta where num_conta = 12 Select saldo into :valor2 From t_conta where num_conta = 13
Valor2 = valor2 +300 update t_conta set saldo = :valor2 where num_conta = 13
Tempo
Display (Valor1, Valor2) inconsistente retrieval
Figura2. Transies Incorretas
Este um problema comum em SGBDs. No decorrer deste captulo, veremos mais exemplos como este, bem como a forma existente para trat-lo. Para entender o conceito de concorrncia em banco de dados, se faz necessrio entender primeiramente o conceito de transao.
50
1.2. Conceito de transao Transao pode ser entendida como uma Abstrao que representa a seqncia de operaes de bancos de dados resultantes da execuo de um programa [Eswaram et al]. A transao leva em conta apenas as operaes de leitura (read) e escrita (write) que esto presentes nela. Como pode ser visto na Figura 3, o cdigo executado pelo programa-1 executado em uma transao (T1) e para esta transao, apenas os acessos ao Banco de Dados sero contabilizados.
Programa-1 Select saldo into :valor1 From t_conta where num_conta = 12 valor1 = valor1 + 500 update t_conta set saldo = :valor1 where num_conta = 12
Figura 3. Cdigo de uma transao
Desta forma, a expresso que soma 500 varivel valor1 desconsiderada pela transao, sendo que apenas as operaes de select (read) e update (write) sero consideradas como operaes da transao T1. Como forma de simplificao abreviamos a leitura (read) para r e a escrita (write) para w, ambos indexados pelo nmero da transao, neste caso T1. Sendo assim, a sequncia de operaes executadas na figura 3, passa a ser representada da seguinte forma: T1 = r1(conta_12) w1(conta_12) Como visto, transao pode ser entendida como uma srie de operaes sobre itens no banco de dados que podem alterar o seu estado. As operaes so delimitadas com uma instruo de incio da transao (Begin Transaction) e no final com uma instruo de fim da transao Commit para efetivar as alteraes, ou uma 51
instruo Rollback quando for necessrio descartar todas as alteraes realizadas no banco de dados. Para alguns renomados autores, Transao : uma unidade lgica de processamento no BD (Navathe) uma unidade de execuo do programa que acessa e possivelmente atualiza vrios itens de dados (Silberschatz)
Possveis operaes dentro de um banco de dados: BEGIN_TRANSACTION Incio da execuo de uma transao END_TRANSACTION Fim da Transao READ(x) ou WRITE(x) Operaes de leitura de um dado x e escrita do dado x em um banco de dados COMMIT Transao completou sua execuo com sucesso ROLLBACK (ou ABORT) Transao foi abortada, no terminou com sucesso e as mudanas realizadas devem ser desfeitas.
Este conjunto de operaes compreendidos dentro da transao considerado uma unidade lgica de trabalho, desde que possua um conjunto de propriedades conhecida pelo acrnimo de ACID, descrito mais frente neste captulo.
52
1.3 Estados de uma transao
Ativa estado inicial de toda transao selecionada para execuo enquanto ativa, uma transao executa uma ou mais operaes read e write
Em Processo de Efetivao entra nesse estado aps executar sua ltima operao (solicitao de COMMIT) neste momento, o SGBD precisa garantir que as suas atualizaes sejam efetivadas com sucesso (no sofra falhas) aplicao de tcnicas de recovery
Efetivada entra nesse estado aps o SGBD confirmar que todas as modificaes da transao esto garantidas no BD (COMMIT OK) exemplos: gravao em Log, descarga de todos os buffers em disco
53
Em processo de aborto entra nesse estado se no puder prosseguir a sua execuo pode passar para esse estado enquanto ativa (I) ou em processo de efetivao (II) exemplo (I): violao de RI exemplo (II): pane no S.O. suas aes j realizadas devem ser desfeitas (ROLLBACK)
Concluda estado final de uma transao indica uma transao que deixa o sistema as informaes da transao mantidas em catlogo podem ser excludas operaes utilizados, ... se a transao no concluiu com sucesso, ela pode ser reiniciada automaticamente feitas, dados manipulados, buffers
1.4. Propriedades da transao Nos bancos de dados que trabalham com transaes de curta durao, como o caso dos bancos de Dados Relacionais (BDR), excencial que sejam respeitadas as propriedades de ACID (Atomicidade, Consistncia, Isolamento, Durabilizade), descritas a seguir: Atomicidade: tudo ou nada. Todas as aes da transao acontecem ou nenhuma pode acontecer; Consistncia: se toda a transao consistente, e o BD inicia consistente, ento o BD termina consistente; Isolamento: a execuo de uma transao isolada de outras transaes, ou seja, as alteraes realizadas por uma
54
transao no sero visualizadas pelas outras transaes at que elas sejam efetivamente atualizadas (commit); Durabilidade: se uma transao finalizada, seu efeito persiste.
Exemplo Bancrio - considere a seguinte transao: Suponha que T2 seja uma transao que transfere R$ 100,00 da conta X para a conta Y. T2: read (X); X := X 100; write (X); read (Y); Y := Y + 100; write (Y)
Analisando cada uma das propriedades ACID no exemplo bancrio: Atomicidade Suponha os valores X=R$1.000 e Y=R$2.000 Suponha uma falha no meio da transao R$ 900,00 e R$ 2.000,00 (somente a retirada foi efetuada) A atomicidade garante que todas as operaes sero efetuadas ou nenhuma delas ser. Para esta suposta falha, a operao de retirada desfeita retornando o saldo da conta X para R$ 1.000 Consistncia Se os dados elas estiverem devem consistentes permanecer antes da
transao,
consistentes
depois da transao tambm. Isolamento Operaes no podem se intercalar, gerando um estado inconsistente. Mesmo que uma operao leia informaes da outra, a consistncia deve ser garantida. Durabilidade 55
Quando uma transao executou com sucesso, preciso garantir que nenhuma falha resulte na perda dos dados j armazenados.
56
2. EXECUES CONCORRENTES
2.1 Acessos Concorrentes Os acessos concorrentes devem ser tratados pelos bancos de dados para garantir a integridade das alteraes realizadas nas informaes. Em um mesmo momento diversos usurios podem estar realizando as mais variadas atualizaes no mesmo banco de dados, e em alguns casos alterando as mesmas informaes. Para solucionar este problema o banco de dados possui diferentes mecanismos, possibilitando ao desenvolvedor a escolha da melhor forma para a aplicao tratar acessos concorrentes mesma informao.
Figura 4. Lost update
Na figura 4 apresentado um erro provocado pelo acesso concorrente ao banco de Dados, a perda de atualizao ou lost update. Este problema ocorre com bastante frequncia e se no for tratado devidamente pode trazer srios problemas de inconsistncia 57
para os dados. O occorreu neste caso, foi que a atualizao (update da conta 12) do programa-1 foi sobreposta pela atualizao (update da conta 12) do programa-2, perdendo a adio de 500 ao valor inicial. Ou seja, o banco de dados foi levado de um estado incial consistente a um novo estado, agora inconsistente. Quando vrias transaes executam simultaneamente, a propriedade de ISOLAMENTO pode no ser mais preservada, pode haver interferncias. Um modo de evitar o problema de transaes executando simultaneamente executar transaes de modo serial, uma aps a outra. Para garantir que ela seja PRESERVADA o sistema precisa controlar a interao entre as transaes simultneas. Da a necessidade de se fazer o CONTROLE DE CONCORRNCIA.
2.2 Controle de Concorrncia o gerenciamento das operaes concorrentes no BD, garantindo o isolamento Permite das que transaes vrios usurios executadas acessem
concorrentemente.
simultaneamente os dados compartilhados. Estes usurios entram em concorrncia quando tentam acessar os mesmos dados ao mesmo tempo. Porque fazer o controle de concorrncia: Melhor throughput e utilizao dos recursos Transao consiste de muitas etapas como: atividades de E/S, utilizao da CPU que podem ser executadas em paralelo. Tudo isso aumenta o throughput, isto , o nmero de transaes executadas em determinada quantidade de tempo e a utilizao dos recursos. Tempo de espera reduzido Pode haver transaes curtas e longas. Se a execuo for serial, uma transao curta pode esperar muito tempo at uma que transao longa termine. Se elas forem executadas simultaneamente, compartilhando os
58
ciclos da CPU, o tempo mdio de resposta ser reduzido.
No SGBD, o responsvel pelo Controle de Concorrncia o escalonador (Scheduler). Ele o responsvel por fazer o entrelaamento (interleaving) de operaes. Por entrelaamento, entenda que operaes de um programa podem ser executadas entre duas operaes de outro programa. O Schedule (histria) representa a ordem cronolgica em que as instrues so executadas no sistema. O escalonador (scheduler) define uma seqncia de operaes de um conjunto de transaes concorrentes, preservando a ordem das operaes em cada uma das transaes.
Escalonador serializvel: As operaes de cada transao so executadas de maneira consecutiva sem nenhuma intercalao nas operaes. Soluo ineficiente !!! vrias transaes podem esperar muito tempo para serem executadas. CPU pode ficar muito tempo ociosa. enquanto uma transao faz I/O, por exemplo, outras transaes poderiam ser executadas.
59
Obs.1: A execuo em srie no permite nunca que um BD fique em um estado inconsistente. Obs.2: Planos seriais desperdiam tempo da CPU e so inaceitveis na prtica.
Escalonador no-serializvel: as operaes de um conjunto de transaes so executadas de maneira intercaladas. escalonamento (schedule) no-serial e ntegro.
O objetivo da capacidade de serializao de encontrar escalonadores no seriais que permitam uma execuo concorrente, sem interferir uma transao na outra e conseqentemente, sem gerar um estado inconsistente.
Execuo
concorrente
de
transaes
implica
em
um
entrelaamento das operaes destas transaes. Sendo assim, uma execuo correta das transaes depende do entrelaamento correto de suas operaes (Figura 5).
60
Figura 5. Entrelaamento de operaes.
Quando um entrelaamento est correto? Dizemos que uma execuo correta produz um estado consistente no BD.
Problemas de um escalonamento no-serial mal definido (invlido): atualizao perdida (lost-update)
Uma transao Ty grava em um dado atualizado por uma transao Tx
leitura suja (dirty-read)
61
TX atualiza um dado X, outras transaes posteriormente lem X, e depois TX falha
2.3 Reviso
O que uma transao? Uma seqncia de aes que so consideradas uma unidade atmica (indivisvel) de trabalho.
O que conflito entre transaes? O conflito entre transaes ocorre quando mais de uma transao tenta acessar o mesmo item de dado.
O que mecanismo de controle de concorrncia? um mecanismo que garante a Consistncia e a Isolao dos dados, dada a atomicidade das transaes.
Por que estudar mecanismos de controle de concorrncia? Trabalhamos em ambientes multi-tarefas necessrio compartilhar dados; necessrio manter a consistncia dos dados.
62
3. ISOLAMENTO DE TRANSAES
3.1 Transaes Sequenciais Conforme vimos anteriormente, transaes executadas de forma seqencial uma seguida da outra so ditas transaes corretas. Entretanto a execuo de schedules seriais limita o acesso concorrente aos dados e, por conseqncia, diminui o throughput (quantidade de trabalho realizado em um intervalo de tempo). O ideal seria permitir a execuo concorrente de transaes, mas de tal forma que resultados consistentes sejam produzidos no banco de dados. Podemos dizer ento que temos: Premissa o A execuo de uma transao correta, se executada isoladamente. consistente. Teorema o Toda execuo serial de transaes correta S=T1 T2 T3 ... Tn-1 Tn Este o padro para corretude de schedules!!! Pois, produz sempre um estado
A figura 6 apresenta o exemplo da execuo serial de transaes. Primeiramente executada toda a transao T1 e s depois executada a transao T2.
63
T1 Select saldo into :valor1 From t_conta where num_conta = 12 Select saldo into :valor2 From t_conta where num_conta = 13 valor1 = valor1 + 500 update t_conta set saldo = :valor1 where num_conta = 12 Valor2 = valor2 +300 update t_conta set saldo = :valor2 where num_conta = 13
T2
Select saldo into :valor1 From t_conta where num_conta = 12 Select saldo into :valor2 From t_conta where num_conta = 13
Figura 6. execuo serial de transaes
Como vimos, apesar de correto este mtodo no o desejvel para um ambiente multi-usurio. Precisamos de um critrio de corretude que garanta mais paralelismo. Neste caso, precisamos de transaes executando concorrentemente e de maneira correta. 3.2 Execuo Correta de Transaes Concorrentes Partindo do teorema de que toda execuo serial de transaes correta, temos que um escalonamento no-serial de um conjunto de transaes deve produzir resultado equivalente a alguma execuo serial destas transaes. Logo: Seja um schedule S o Se S produz um estado de banco de dados igual ao produzido por alguma execuo serial do mesmo conjunto de transaes, ento a execuo S correta (Figura 7).
64
Figura 7. Execuo serial e execuo no-serial de schedules.
Logo, escalonamento serializvel um escalonamento equivalente a uma execuo serial das transaes. Desta premissa, surge o conceito de SERIALIZABILIDADE. Serializabilidade a Iluso de que transaes so executadas como aes atmicas (sem interferncias ou interleavings). Equivalncia de schedules o Dado um conjunto = {T1, T2, ..., Tn} de transaes Encontrar schedules cujas execues produzam o mesmo estado no BD que a execuo de algum schedule serial sobre . Desta forma, reduzimos o problema de identificar schedules corretos ao problema de definir equivalncia entre schedules. Existem trs diferentes noes de equivalncia que podem ser encontradas na literatura. So elas: Equivalncia de estado final Equivalncia de viso Equivalncia de conflito Para o estudo de equivalncias, a notao ri(x) e wi(x) ser utilizada para representar operaes de leitura e escrita executadas por uma transao Ti sobre um objeto x. OP(Ti) representa o conjunto de todas as operaes executadas pela transao Ti. Alm das operaes de leitura e escrita uma transao Ti dever conter aps todas as operaes de leitura e escrita uma operao commit (ci) ou abort (ai), mas no ambas. 65
A relao de ordem <i representa a precedncia entre duas operaes de uma transao Ti. Por exemplo, ri(x) <i wi(x) indica que a operao ri(x) ocorreu antes da operao wi(x). 3.2.1 Equivalncia de estado final o Dois Schedules sobre um conjunto = {T1, T2, ..., Tn} so equivalentes de estado final (S FS S) se, e somente se, (i) tm as mesmas operaes pertencentes s transaes de e (ii) produzem o mesmo estado final no BD, se forem executados sobre um mesmo estado inicial PROBLEMA: Schedules no capturam o
conceito de estados inicial e final.
3.2.2 Equivalncia de viso o Dois Schedules S e S sobre um conjunto ={T1, T2, ..., Tn} so equivalentes de viso (S V S) se, e somente se, (i) tm as mesmas operaes pertencentes a transaes de e (ii) para cada operao ri(x) de Ti , o valor lido por ri o mesmo nos dois schedules (iii) Se wi(x) a ltima operao de escrita sobre x em S, ento wi(x) a ltima operao de escrita sobre x em S PROBLEMA: Controle sobre todas as
operaes de leitura e escrita.
Para entendermos o prximo tipo de equivalncia (equivalncia em conflito), precisamos entender primeiro o conceito de operaes em conflito.
Operaes em conflito (conflitantes) Operaes de transaes distintas 66
Executadas sobre um mesmo objeto e Pelo menos uma delas uma operao de escrita (write) T1=r1(x)w1(x) T2=r2(x)w2(y) S= r2(x)r1(x)w2(y)w1(x)
3.2.3 Equivalncia de conflito o Dois Schedules S e S sobre um conjunto ={T1, T2, ..., Tn} so equivalentes de conflito (S C S) se, e somente se, (i) tm as mesmas operaes pertencentes a transaes de e (ii) Ordenam (seqenciam) as operaes em conflito da mesma forma
Para qualquer duas operaes em conflito pi OP(Ti) e qj OP(Tj), com ij, se pi <S qj, ento pi <S qj
T1=r1(y)r1(x)w1(y)
T2=r2(x)r2(y)w2(x)
S = r1(y)r1(x)r2(x)w1(y)r2(y)w2(x) S= r1(y)r1(x)w1(y)r2(x)r2(y)w2(x)
Operaes em conflito do Schedule S
r1(x) <S w2(x) w1(y) <S r2(y)
r1(x) <S w2(x) w1(y) <S r2(y)
Analisando
as
operaes
em
conflito
dos
dois
schedules,
verificamos que os dois schedules so equivalentes em conflito.
67
3.3 SERIALIZABILIDADE
Trs diferentes noes de equivalncia de schedules Trs diferentes noes de corretude de schedules
Serializabilidade por estado final (FSR) Um schedule S serializavel por estado final, se ele equivalente de estado final a algum schedule serial. Serializabilidade por viso (VSR) Um schedule S serializavel por viso, se ele equivalente de viso a algum schedule serial. Serializabilidade por conflito (CSR) Um schedule S serializavel por conflito, se ele equivalente de conflito a algum schedule serial.
Qual critrio a adotar ??? Apresentam o mesmo grau de corretude Apresentam diferentes graus de paralelismo, pois permitem diferentes nveis de entrelaamento SS= r2(x)w2(x,5)r1(x)w1(x,10) e o valor inicial de x 2 S1= r1(x)r2(x)w2(x,5)w1(x,10) S1 produz o mesmo estado final que SS, ento S1 serializavel por estado final; S1 correto, embora no seja serializavel por viso (o valor lido por r1(x) diferente nos dois schedules) e nem por conflito. FSR VSR CSR
68
Qual critrio a adotar??? (cont.) Apresentam diferentes graus de complexidade Identificar schedules FSR ou VSR Problema NP completo Pior caso: n! o n o nmero de transaes
Identificar se um schedule CSR poder ser feito em tempo polinomial, por este motivo, o critrio adotado o da serializabilidade por conflito.
Serializabilidade por conflito S serializavel por conflito, se S equivalente por conflito a algum schedule serial SS sobre o mesmo conjunto de transaes Exemplo T1=r1(y)r1(x)w1(y) T3=r3(y)r3(x)w3(z)
S = r3(y)r1(y)r1(x)r2(x)w1(y)r2(y)r3(x)w2(x)w3(z) SS=r3(y)r3(x)w3(z)r1(y)r1(x)w1(y)r2(x)r2(y)w2(x) Schedule original Schedule serial (T3,T1,T2)
T2=r2(x)r2(y)w2(x)
69
Operaes em conflito do Schedule SS
r3(y) <S w1(y) r1(x) <S w2(x) w1(y) <S r2(y) r3(x) <S w2(x)
r3(y) <S w1(y) r3(x) <S w2(x) r1(x) <S w2(x) w1(y) <S r2(y)
Como verificamos atravs da forma como os dois schedules ordenam suas operaes em conflito, podemos dizer que o Schedule S serializvel por conflito. Esta uma das formas de verificao da serializabilidade por conflito de um schedule. Mas, no a nica forma. Podemos verificar se um Schedule serializvel por conflito atravs do seu Grafo de Serializao, onde no precisamos comparar um Schedule dado com um outro serial.
3.4 Grafo de serializao de um schedule S S est definido para um conjunto ={T1, T2, ..., Tn} de transaes SG(S)=(V,E) Grafo direcionado V= Ti Tj E i. Ti,Tj , ii. p OP(Ti), q OP(Tj), tal que p conflita com q e p <S q O grafo de serializao de um Schedule um grafo direcionado, onde cada transao um vrtice do grafo e as operaes em conflito so as arestas que conectam os vrtices (transaes).
Grafo de serializao de um schedule S S est definido para um conjunto ={T1, T2, T3} S=r3(y)r1(y)r1(x)r2(x)w1(y)r2(y)r3(x)w2(x)w3(z) Vrtices T1, T2, T3 70
(Transaes): Arestas (operaes em conflito): r3(y) < w1(y) r1(x) < w2(x) w1(y) < r2(y) r3(x) < w2(x) aresta de 3 para 1 aresta de 1 para 2 aresta de 1 para 2 aresta de 3 para 2
Teorema Um schedule S serializavel por conflito o grafo de serializao de S no contm ciclos Verificar existncia de ciclos em grafos o Resolvido em tempo polinomial o O(n2), onde n representa o nmero de
transaes
3.5 Prefixo de um schedule Com base no grafo de serializao, chegamos a outro importante conceito que muito til para identificar corretude de schedules dinamicamente, o conceito de Prefixo de um Schedule.
Vamos considerar o prefixo L de um Schedule S: 1. OP(L) OP(S) 2. p,q OP(L), p <Lq p <S q 3. q OP(L), p OP(S), p <Sq p OP(L)
S=r3(y)r1(y)r1(x)r2(x)w1(y)r2(y)r3(x)w2(x)w3(z)
71
Propriedade P de schedule fechada por prefixo Se P vlida para o schedule completo S, P tambm vlida para qualquer prefixo de S
Este conceito, na verdade, mostra que a Serializabilidade por conflito uma propriedade fechada por prefixo: Se algum prefixo no serializavel por conflito, o schedule completo tambm no ser! Schedule incorreto.
Desta forma, medida que as operaes vo sendo escalonadas, se ocorrer um ciclo em qualquer parte do Schedule, o mesmo j pode ser considerado incorreto. No precisa checar todo o Schedule.
3.6 Exerccios 1) Verifique se o seguinte schedule serializavel por estado final e por viso. Justifique sua resposta. T1=r1(y)r1(x)w1(y) T2= w2(u)r2(x)r2(y)w2(x)
T3=r3(y)r3(x)w3(u)w3(z) T4= r4(v)w4(u)

S=r4(v)r3(y)r1(y)w2(u)r2(x)r2(y)w1(y)w4(u)w2(x)r1(x)r3(x)w3(u)w3(z)
2) Verifique a corretude do seguinte schedule: S=r3(y)r1(y)r1(x)r2(x)w1(y)r2(y)w2(x)r3(x)w3(z) 3) Verifique se o seguinte schedule serializavel por conflito. Justifique sua resposta. T1=r1(y)r1(x)w1(y) T2= w2(u)r2(x)r2(y)w2(x) T3=r3(y)r3(x)w3(u)w3(z) T4=r4(v)w4(u) S=r4(v)r3(y)r1(y)r1(x)w2(u)r2(x)w1(y)r2(y)w4(u)r3(x)w2(x)w3(u)w3(z)
72
4) Prove que se dois schedules so equivalentes, ento seus grafos de serializao so iguais. Prove tambm que o inverso no verdade.
73
4. CONFIABILIDADE DE SCHEDULES
4.1 CORRETUDE x CONFIABILIDADE At agora, temos discutido o modelo clssico para a execuo de transaes concorrentes sem considerar a presena de falhas. Na prtica, as transaes so executadas em ambientes onde podem ocorrer falhas. Logo, um mecanismo eficiente para o processamento de transaes deve suportar a existncia de falhas.
Outra
contribuio
importante
do
modelo
clssico
de
processamento de transaes o conceito de schedule confivel. A confiabilidade est relacionada ao grau de consistncia. A seguir definiremos formalmente a noo de schedule confivel.
Dizemos que um schedule confivel se as seguintes condies so satisfeitas: i. O abort de uma determinada transao Ti no afeta a semntica das transaes que j executaram sua operao de commit, e ii. Quando uma determinada transao Ti aborta, os valores dos objetos atualizados anteriormente por Ti devem ser restaurados como se esta transao nunca tivesse sido executada. Os efeitos de uma transao abortada devem ser completamente desfeitos.
Torna-se
importante
destacar
que
os
conceitos
de
serializabilidade e confiabilidade de schedules so propriedades ortogonais. Existem schedules serializveis que no so confiveis e
74
vice-versa. Contudo, do ponto de vista prtico os schedules devem ser corretos (serializveis) e confiveis. Vejamos o exemplo abaixo: T1=w1(x,2)r1(z) c1 T2= r2(u)r2(x)w2(y,x+3) c2
S= r2(u)w1(x,2)r2(x)w2(y, x+3)c2 Aps o abort de T1 o r2(x) torna-se uma leitura inconsistente (dirty read) o Desfazer execuo de T1 Violao da semntica da operao r2(x) (r2(x) leu o valor que j tinha sido alterado por w1(x)) o Abortar T2 Violao da semntica da operao c2 (nenhuma transao pode ser abortada aps ter realizado Commit) Execuo de S correta (serializavel), porm Execuo de S no confivel
A seguir iremos caracterizar melhor os schedules confiveis. De fato, existem trs diferentes nveis de confiabilidade de schedules: Recupervel, Evita Abort em Cascata e Preciso. 4.2 Schedule Recupervel O nvel mais genrico chamado de recuperao de schedules. Um schedule S dito recupervel se a condio abaixo satisfeita:
Se wi(x) <S rj(x), ento a operao commit da transao Ti precede a operao de commit da transao Tj, isto , ci <S cj.
75
Schedules recuperveis garantem que, uma vez que uma transao Ti executa sua operao de commit, seus efeitos nunca sero desfeitos. Por exemplo:
T1=w1(x,2)r1(z)c1
T2= r2(u)r2(x)w2(y, x+3)c2
S1= r2(u)w1(x,2)r2(x)r1(z)w2(y, x+3)c1c2
Se w1(x) <S1 r2(x) c1<S c2 S1 recupervel 4.3 Schedule que Evita Abort em Cascata Entretanto, mesmo em schedules recuperveis, o abort de uma transao Ti pode provocar efeitos colaterais indesejveis. Por exemplo, se wi(x) <S rj(x), e a transao Ti aborta aps a execuo da operao rj(x) e antes de Tj executar sua operao de commit, o valor lido por rj(x) no vlido. Isto implica que a transao Tj tambm deve ser abortada. Este fenmeno chamado de abort em cascata. A fim de evitar a ocorrncia destes fenmenos ns necessitamos de um nvel de confiabilidade mais forte. Um schedule dito que evita aborts em cascata se:
Sempre que wi(x) <S rj(x), ento ci <S rj(x) ou ai <S rj(x) Por exemplo: S1= r2(u)w1(x,2)r2(x)w2(y, x+3) Neste caso, o abort de T1 fora o abort de T2. Exemplo2:
S2= r2(u)w1(x,2)r1(z)c1r2(x)w2(y, x+3)c2 Se wi(x) <S rj(x) ci<S rj(x) S2 evita aborts em cascata 76
4.4 Schedule Preciso (strict) Algumas vezes, a propriedade que evita o abort em cascata ainda no suficientemente forte para garantir um nvel de confiabilidade desejvel. O schedule S mostrado a seguir ilustra este fato.
S = wi(x) wj(x) cj ai Como Ti foi abortada, o valor do objeto x deve ser restaurado para o valor anterior execuo da transao Ti. Infelizmente, isto no possvel, pois a transao Tj j executou sua operao de commit e sobrescreveu o valor escrito por Ti. Este problema pode ser evitado fazendo com que a operao wj(x) espere at que a transao Ti execute sua operao de commit ou de abort, s ento a operao wi(x) poder ser executada. Esta condio garantida pelo nvel mais forte de confiabilidade, que chamado strictness. Um schedule chamado estrito (strict) se: Sempre que wi(x) <S pj ento ci <S pj ou ai <S pj, onde pj {r(x), w(x)} Observe que um schedule estrito (strict) evita aborts em cascata e recupervel. Isto deve-se ao fato de que a classe de schedules estritos (strict) uma subclasse dos schedules que evitam aborts em cascata, o qual por sua vez uma subclasse dos schedules recuperveis.
Exemplo 1:
S3= w1(x,2)w2(x,5) c2 No possvel recuperar o valor que x tinha antes da operao w1(x,2)
77
Exemplo 2: S4= w1(x,2)c1w2(x,5)c2 o Se wi(x) <S opj(x) ci<S opj(x) ou ai<S opj(x), onde opj {rj, wj} o S4 preciso E como funcionam os DBMSs existentes?
Os atuais DBMSs produzem schedules: Corretos Serializaveis por conflito Precisos (grau de confiabilidade)
Confiveis 4.5 Exerccios:
1) Classifique os schedules abaixo de acordo com a seguinte classes de schedules: serializveis por conflito, recuperveis, que evitam aborts em cascata, e estritos (strict).
a) b) c)
d)
r1(x) r2(y) r3(x) w3(x) r2(x) r1(y) w1(x) c1 c2 c3 r1(x) r1(y) w1(x) r2(y) w3(y) w1(x) r2(y) c1 c2 c3 r4(v)r3(y)r1(y)r1(x) w2(u)r2(x)w1(y)r2(y)w4(u)r3(x)w2(x)w3(u)w3(z) c1 c2 c3 c4 r1(x) w2(x) w1(x) a2 c1
2) Considere o seguinte schedule S (incompleto) : r1(x) r1(y) w1(x) r2(y) w3(y) w1(x) r2(y) Assumindo que as trs transaes executam suas operaes de commit, mostre o grafo de serializao para o schedule S. Para cada uma das opes baixo modifique o schedule S a fim de criar um novo schedule (completo) T tal que: T evita aborts em cascata e no recupervel. T recupervel. T serializvel por conflito. Para criar o schedule T voc pode adicionar novas operaes em qualquer posio do schedule S, mas no pode alterar a ordem das operaes j existentes. Caso no seja possvel criar o schedule T como se pede, comente brevemente.
78
Controle de Concorrncia
Esta unidade discute em detalhes o problema de controle de concorrncia em bancos de dados. Vrios algoritmos para controle de concorrncia so apresentados e discutidos. A apresentao de cada mtodo acompanhada de uma discusso sobre problemas adicionais, ocasionados pelo mtodo, que possam impedir o trmino normal das transaes. Uma classificao destes protocolos tambm apresentada e discutida.
79
SUMRIO
UNIDADE III CONTROLE DE CONCORRNCIA
1. INTRODUO 1.1. Conceitos iniciais .................................................... 00 1.2. Classificao............................................................. 00 1.3. Exerccios ................................................................. 00
2. PROTOCOLOS CONSERVADORES 2.1. Protocolos baseados em bloqueios.......................... 00 2.2. Granularidade mltipla.............................................. 00 2.3. Esquemas de mltipla verso................................... 00 2.4. Tratamento de impasse ............................................ 00 2.5. Arquitetura de GTs que utilizam 2PL........................ 00 2.6. Controle de Concorrncia em SQL .......................... 00 2.7. Exerccios ................................................................. 00
3. PROTOCOLOS AGRESSIVOS 3.1. Protocolos baseados em timestamp......................... 00 3.2. Protocolos baseados em validao...........................00 3.3. Teste do grafo de serializao................................. 00 3.4. Exerccios ................................................................ 00
4. WEBLIOGRAFIA ..................................................................... 00
80
UNIDADE III INTRODUO AO CONTROLE DE CONCORRNCIA
5. INTRODUO
1.1. Conceitos Iniciais Os modelos de processamento de transaes so
implementados atravs dos protocolos de controle de concorrncia. Estes protocolos so responsveis por produzir estrias (schedules) em conformidade com o critrio de corretude (ou correo) adotado. Pelo termo produzir schedules', entendemos que um protocolo de controle de concorrncia recebe como entrada as operaes pertencentes a um determinado conjunto de transaes e produz como sada uma seqncia corretamente entrelaada destas operaes. Por exemplo, o protocolo 2PL (Two Phase Locking) um protocolo de controle de concorrncia que implementa o modelo clssico de processamento de transaes, logo, utiliza
serializabilidade como critrio de correo. Assim, o protocolo 2PL produz schedules serializveis. Os protocolos de controle de concorrncia constituem o ncleo dos escalonadores (schedulers).
1.2. Classificao dos Protocolos de Controle de Concorrncia Os protocolos de controle de concorrncia podem ser classificados conservadores). como agressivos ou conservativos (ou
Um protocolo agressivo
tenta escalonar as
operaes imediatamente. Desta forma, um protocolo agressivo evita adiar a execuo das operaes de uma transao. Entretanto, esta estratgia pode levar a situaes onde no possvel produzir uma execuo correta de todas as transaes ativas. Neste caso,
81
um protocolo agressivo rejeita operaes de uma ou mais transaes, levando estas transaes ao estado aborted. Assim, os protocolos agressivos podem gerar ndices de aborts inaceitveis. Adicionalmente, os protocolos agressivos podem ser
classificados em duas subclasses: pessimistas e otimistas. Um scheduler que implementa um protocolo pessimista deve decidir se aceita ou rejeita uma operao to logo ele receba esta operao. Por outro lado, um scheduler que utiliza um protocolo otimista escalona as operaes que recebe de forma imediata. Aps um determinado perodo de tempo, o scheduler verifica se o schedule que est sendo gerado correto ou no. Caso o schedule seja correto, o scheduler continua escalonando operaes. Caso contrrio, o scheduler deve abortar uma ou mais transaes. Um exemplo clssico para esta classe de protocolos so os
certificadores [Har84]. Por sua vez, um protocolo conservativo tende a adiar a execuo de determinadas operaes com a finalidade de escalonlas corretamente. Desta forma, estes protocolos, apesar de no
induzir o abort de transaes, podem levar as aplicaes a tempos de espera inaceitveis, principalmente se estas forem transaes de longa durao [Bray99a]. A figura 1.1 mostra uma viso geral desta classificao [Ber87].
82
Figura
1.1.
Classificao
dos
Protocolos
de
Controle
de
Concorrncia
1.3. Exerccios
1 - Considere um campeonato de futebol formado por: Equipe 01: Matemtica; Equipe 02: Fsica; Equipe 03: Qumica; Equipe 04: Biologia; Equipe 05: Computao1; Esboce um grafo que represente todas as combinaes de jogos possveis entre essas equipes. Utilizando este mesmo grafo d o grau de cada vrtice e a quantidade de arestas nele existente.
2 D o grau de cada vrtice e o nmero de arestas para cada um dos grafos abaixo.
83
UNIDADE III PROTOCOLOS CONSERVADORES
6. DESCRIO DOS PROTOCOLOS CONSERVADORES
Este captulo discute o uso de bloqueios para controle de concorrncia em um ambiente centralizado. Inicialmente os
problemas de gerncia de bloqueios e tratamento de bloqueios mtuos so abordados. Em seguida, um mtodo que utiliza o conceito de bloqueio para assegurar a gerao de schedules (execues) serializveis, denominado de bloqueio em duas fases, apresentado. Por fim, a correo do mtodo provada.
2.1. Protocolos Baseados em Bloqueios 2.1.1. Conceitos Iniciais Nos protocolos baseados em bloqueio, uma transao Ti somente pode acessar um item de dado caso tenha anteriormente obtido um bloqueio sobre este item. Assim, a fim de acessar um determinado item, a transao Ti precisa primeiramente bloque-lo. Caso o item de dado esteja bloqueado por outra transao (Tj, por exemplo) ento Ti dever esperar at que o bloqueio seja liberado. Desta forma, o scheduler garante que somente uma transao pode acessar um determinado item de dado por vez [Ber87]. Para ilustrar a utilizao do conceito de bloqueio, suponha inicialmente que s h um modo de bloqueio, ou seja, que cada item de dado (objeto) s pode estar em dois estados: i) bloqueado: permite acesso ao objeto apenas pela transao que detm o bloqueio; ii) livre: ainda no est bloqueado por nenhuma transao. Logo, este item de dado ainda no pode ser acessado por nenhuma 84
transao, uma vez que para acessar um determinado item de dado uma transao precisa inicialmente obter um bloqueio sobre este item. Neste caso, necessrio introduzir apenas duas novas aes elementares ao nosso repertrio (que contm at o momento as operaes ri(x), wi(x), ai e ci): i) li(x) bloqueia (lock) o item de dado (objeto) x para a transao Ti; ii) ui(x) a transao Ti libera (unlock) o bloqueio que detm sobre o item de dado (objeto) x; As informaes necessrias para gerenciar a concesso e liberao de bloqueios so, em geral, armazenadas em uma estrutura de dados denominada tabela de bloqueios. Esta tabela modelada como uma coleo de triplas (x,Ti,F) onde: i) x o nome de um item de dado (objeto); ii) Ti o nome da transao que mantm o bloqueio sobre x; iii) F uma fila de espera para x, contendo os nomes de todas as transaes que esperam a liberao de x.
2.1.2. Protocolo de Bloqueio Bsico A seguir apresentamos um protocolo de controle de concorrncia rudimentar, baseado na idia de bloqueio. Passo 1: Inicialmente a tabela de bloqueios est vazia ( indica a fila, F, vazia); Passo 2: Ao receber solicitao para bloquear o objeto x para a transao Ti, atravs da operao li(x), pesquise a tabela de bloqueios procurando uma tripla cujo primeiro elemento seja x: i) se nenhuma tripla for encontrada (ou seja, se x est livre), bloqueie x para Ti, acrescentando a tripla (x, Ti, ) tabela.
85
ii) caso contrrio, acrescente Ti ao final da fila de espera para x na tripla encontrada. Passo 3: Ao receber solicitao da transao Ti atravs da ao ui(x) para liberar o objeto x, pesquise a tabela de bloqueios procurando uma tripla cujos dois primeiros elementos sejam x e Ti: i) se nenhuma tripla for encontrada, ignore a liberao de x. ii) caso contrrio, seja (x, Ti, F) a tripla encontrada: a) se a fila F estiver vazia (F = ), retire a tripla da tabela, liberando x. b) se a fila F no estiver vazia (F ), passe o controle de x, ou seja, bloqueie x, para a primeira transao Tj em F, em seguida, retire Tj de F.
Exemplo 1 A fim de ilustrar o funcionamento do protocolo de bloqueio bsico considere inicialmente o seguinte conjunto de transaes: T1 = r1(x) r1(y) w1(x) w1(y) c1 T2 = r2(x) c2 Considerando que antes de qualquer operao sobre um determinado item de dado necessrio obter um bloqueio sobre este item e que a liberao dos bloqueios ocorrero assim que o item de dado no for mais utilizado, podemos representar as transaes T1 e T2 da seguinte forma: T1 = l1 (x) r1(x) l1(y) r1(y) w1(x) w1(y) u1(x) u1(y) c1 T2 = l2(x) r2(x) u2(x) c2 Considere agora a seguinte execuo (schedule): S1 = r1(x) r2(x) c2 r1(y) w1(x) w1(y) c1 ou, mais precisamente:
86
S1 = l1 (x) r1(x) l2(x) r2(x) u2(x) c2 l1(y) r1(y) w1(x) w1(y) u1(x) u1(y) c1 Assuma que esta execuo (S1) representa a ordem com que as operaes enviadas pelas transaes T1 e T2 chegaram ao escalonador (o qual utiliza o protocolo descrito acima). Observe que o schedule S1 no poderia ser obtido pelo protocolo discutido, uma vez que a operao l2(x), e conseqentemente r2(x), no pode ser executada at que a transao T1 libere o bloqueio obtido sobre o item x atravs da operao u1(x). Neste caso, o schedule gerado pelo protocolo poderia ser representado da seguinte forma: S2 = l1 (x) r1(x) l1(y) r1(y) w1(x) w1(y) u1(x) l2(x) r2(x) u2(x) c2 u1(y) c1 A figura 2.1 ilustra o grafo de serializao para o schedule S2. Como o grafo de serializao do schedule S2 no possui ciclo, podemos concluir que S2 serializvel por conflito (e, por conseguinte, correto).
Figura 2.1. Grafo de Serializao do Schedule S2. Porm, se montarmos o grafo de serializao para o schedule S1 (figura 2.2), veremos que este tambm no possui ciclo. Assim, podemos concluir que S1 tambm serializvel por conflito (e, por conseguinte, correto). Contudo, o schedule S1 no seria gerado pelo protocolo apresentado, apesar de apresentar um grau de concorrncia maior que o schedule S2. Esse maior grau de concorrncia decorre do fato de que no schedule S1 a operao r2(x) executada bem antes do que no schedule S2. 87
Figura 2.2. Grafo de Serializao do Schedule S1.
Bloqueio Compartilhado e Exclusivo O protocolo de bloqueio bsico pode ser melhorado
incorporando-se modalidades (ou modos) diferentes de bloqueio. Uma opo seria adotar duas modalidades de bloqueio: i) Bloqueio de leitura ou compartilhado (read lock - rl) ii) Bloqueio de escrita ou exclusivo (write lock - wl) Isto significa que agora um item de dado poder estar em trs estados: i) bloqueado para leitura (ou de forma compartilhada); ii) bloqueado para escrita (ou de forma exclusiva); iii) livre (ou seja, no est bloqueado por nenhuma transao).
Uma forma precisa de definir a compatibilidade das modalidades de bloqueio seria atravs de uma matriz de compatibilidades indicando quando duas transaes podem bloquear o mesmo item de dado e quando no o podem fazer (figura 2.3):
Figura 2.3. Matriz de Compatibilidade de Bloqueios A justificativa para as modalidades de bloqueio acima definidas simples. Duas ou mais transaes podero ler o item x 88
simultaneamente, sem perigo de conflito, bloqueando-o para leitura (modo compartilhado). Por outro lado, se uma transao Ti deseja atualizar (gravar ou escrever) o item x, esta operao conflita com qualquer outra operao de leitura ou escrita executada sobre x por outra transao Tj. Logo Ti dever bloquear x em modo exclusivo (para escrita), no permitindo assim que nenhuma outra transao bloqueie x em qualquer modo (leitura ou escrita). Cabe observar que a matriz de compatibilidades se refere a aes de transaes diferentes, e no se aplica a aes de uma mesma transao. Assim, se uma transao j mantm um item x bloqueado para leitura (bloqueio compartilhado) e desejar bloque-lo para escrita (bloqueio exclusivo), poder faz-lo se for a nica transao que no momento mantm x bloqueado. Neste caso, necessrio substituir a operao li(x) por duas novas operaes: i) rli(x) bloqueia (lock) o item de dado (objeto) x em modo de leitura (compartilhado) para a transao Ti; ii) wli(x) bloqueia (lock) o item de dado (objeto) x em modo de escrita (exclusivo) para a transao Ti; Alm disso, a tabela de bloqueios deve ser modelada agora como uma coleo de tuplas (x,modo,T, F) onde: i) x o nome de um item de dado (objeto); ii) modo representa a modalidade pela qual o item de dado x foi bloqueado (leitura ou escrita); iii) T conjunto das transaes que mantm bloqueios sobre x. Se x estiver bloqueado para escrita T ser um conjunto unitrio, ou seja, T conter uma nica transao. Se x estiver bloqueado para leitura o conjunto T poder conter mais de uma transao; iv) F uma fila de espera para x, contendo pares de valores do tipo <Ti, modo> onde Ti representa o nome de uma transao e modo indica a modalidade do bloqueio requisitado por Ti. 89
Agora, o protocolo de bloqueio bsico, utilizando bloqueios de leitura e escrita, pode ser descrito da seguinte forma: Passo 1: Inicialmente a tabela de bloqueios est vazia ( indica a fila, F, vazia); Passo 2: Ao receber solicitao para bloquear o objeto x para a transao Ti, atravs de uma operao rli(x) ou wli(x), genericamente representada por pli(x), pesquise a tabela de bloqueios procurando uma tupla cujo primeiro elemento seja x: i) se nenhuma tupla for encontrada (ou seja, se x est livre), bloqueie x para Ti, no modo requisitado, acrescentando a tupla (x, modo, Ti, ) tabela. ii) caso contrrio, o objeto x j se encontra bloqueado por uma ou mais transaes. Neste caso, verifique se o modo (leitura ou escrita) do bloqueio solicitado por Ti compatvel com o modo pelo qual o item x j se encontra bloqueado: a) em caso afirmativo, bloqueie x para Ti, no modo requisitado, atualizando a tupla (x, modo, T, F) tabela, ou seja, insira Ti em T. b) caso contrrio, acrescente Ti ao final da fila de espera para x na tripla encontrada, ou seja, insira <Ti, modo> em F. Passo 3: Ao receber solicitao da transao Ti atravs da ao ui(x) para liberar o objeto x, pesquise a tabela de bloqueios procurando uma tupla cujo primeiro elemento seja x e Ti T. i) se nenhuma tupla for encontrada, ignore a liberao de x. ii) caso contrrio, seja (x, modo, T, F) a tupla encontrada, onde Ti T. a) se T {Ti} = - se a fila F estiver vazia (F = ), retire a tupla da tabela, liberando x. 90
- se a fila F no estiver vazia (F ), passe o controle de x, ou seja, bloqueie x, para a primeira transao Tj em F, em seguida, retire Tj de F, adicione Tj em T e faa modo o modo do bloqueio solicitado por Tj. Exemplo 2 A fim de ilustrar o funcionamento do protocolo de bloqueio bsico com dois modos de bloqueio (leitura e escrita), considere inicialmente o seguinte conjunto de transaes: T1 = r1(x) r1(y) w1(x) w1(y) c1 T2 = r2(x) c2 Considerando que antes de qualquer operao sobre um determinado item de dado necessrio obter um bloqueio sobre este item e que a liberao dos bloqueios ocorrero assim que o item de dado no for mais utilizado, podemos representar as transaes T1 e T2 da seguinte forma: T1 = rl1 (x) r1(x) rl1(y) r1(y) wl1(x) w1(x) wl1(y) w1(y) u1(x) u1(y) c1 T2 = rl2(x) r2(x) u2(x) c2 Considere agora a seguinte execuo (schedule): S1 = r1(x) r2(x) c2 r1(y) w1(x) w1(y) c1 ou, mais precisamente: S1 = rl1 (x) r1(x) rl2(x) r2(x) u2(x) c2 rl1(y) r1(y) wl1(x) w1(x) wl1(y) w1(y) u1(x) u1(y) c1 Assuma que esta execuo (S1) representa a ordem com que as operaes enviadas pelas transaes T1 e T2 chegaram ao escalonador. Observe que o schedule S1, que no poderia ser obtido pelo protocolo discutido anteriormente (com um nico modo de bloqueio), passa a ser possvel na verso do protocolo de bloqueio bsico com dois modos de bloqueio (leitura e escrita). Assim, podemos observar 91
que esta nova verso do protocolo apresenta um grau de concorrncia maior, se comparado verso anterior.
A figura 2.4 ilustra o grafo de serializao para o schedule S1.
Figura 2.4. Grafo de Serializao do Schedule S1.
Exemplo 3 Sejam A e B duas contas que so acessadas pelas transaes T1 e T2. A transao T1 transfere R$50,00 da conta B para a conta A e tem a forma: T1 = rl1(B) r1(B) wl1(B) w1(B, B-50) u1(B) rl1(A) r1(A) wl1(A) w1(A, A+50) u1(A) c1 A transao T2 apresenta o saldo total das contas A e B, isto , a soma A+B e definida por: T2 = rl2(A) r2(A) u2(A) rl2(B) r2(B) u2(B) Display(A+B) c2 Suponha que o saldo inicial sejam R$100,00 e R$200,00 para as contas A e B, respectivamente. Se essas duas transaes so executadas serialmente, na ordem T1, T2 ou T2, T1, ento a transao T2 mostrar o valor R$300,00. Contudo, se essas transaes forem executadas concorrentemente, a execuo S1 (schedule) abaixo poder ocorrer e o valor R$250,00, que no correto, ser exibido pela transao T2. S1 = rl1(B) r1(B) wl1(B) w1(B, B-50) u1(B) rl2(A) r2(A) u2(A) rl2(B) r2(B) u2(B) Display(A+B) c2 rl1(A) r1(A) wl1(A) w1(A, A+50) u1(A) c1
92
Assuma que esta execuo (S1) representa a ordem com que as operaes enviadas pelas transaes T1 e T2 chegaram ao escalonador.
T1 rl1(B) r1(B) wl1(B) w1(B, B-50) u1(B)
T2
rl2(A) r2(A) u2(A) rl2(B) r2(B) u2(B) Display(A+B) c2 rl1(A) r1(A) wl1(A) w1(A, A+50) u1(A) c1 Figura 2.5. Execuo Concorrente S1 (Exemplo 3).
Este comportamento incorreto, denominado leitura suja (dirty read), ocorreu devido ao fato das transaes T1 e T2 terem liberado os bloqueios obtidos sobre os itens de dados A e B durante o decorrer da execuo concorrente. Logo, podemos concluir que o protocolo de bloqueio bsico no evita a ocorrncia de leituras sujas.
93
Exemplo 4 Considere agora o seguinte conjunto de transaes: T1 = rl1(x) r1(x) u1(x) rl1(y) r1(y) u1(y) wl1(x) w1(x) u1(x) c1 T2 = rl2(x) r2(x) u2(x) wl2(x) w2(x) u2(x) c2 Considere agora a seguinte execuo (schedule): S1 = rl1(x) r1(x) u1(x) rl2(x) r2(x) u2(x) rl1(y) r1(y) u1(y) wl1(x) w1(x) u1(x) wl2(x) w2(x) u2(x) c1 c2 Assuma que esta execuo (S1) representa a ordem com que as operaes enviadas pelas transaes T1 e T2 chegaram ao escalonador. Note que a execuo (histria) S1 apresenta o fenmeno da atualizao perdida (lost update) uma vez que o resultado da operao de escrita w1(x) ser sobrescrito pela operao w2(x). Alm disso, observe que o protocolo de bloqueio bsico ir considerar a execuo S1 correta e, conseqentemente, ir concluir com sucesso (commitar) as transaes T1 e T2. Contudo, se construirmos o grafo de serializao para a execuo S1 (figura 2.6) veremos que este apresenta um ciclo, o que indica que a execuo S1 no serializvel por conflito. Logo, neste caso, o protocolo de bloqueio bsico considerou correta uma execuo incorreta (ou seja, que no serializvel por conflito). Este comportamento ocorreu devido ao fato das transaes T1 e T2 terem liberado os bloqueios obtidos sobre o item de dado x durante o decorrer da execuo concorrente para posteriormente obter novo bloqueio sobre o mesmo item de dado. Assim, podemos concluir que o protocolo de bloqueio bsico no assegura a gerao de execues (schedules) serializveis. Alm disso, as execues geradas por este protocolo podem apresentar os fenmenos leitura suja e perda de atualizao.
94
Figura 2.6. Grafo de Serializao do Schedule S1 no Exemplo 4. Exemplo 5 Considere novamente que A e B so duas contas acessadas pelas transaes T1 e T2. A transao T1 transfere R$50,00 da conta B para a conta A e tem a forma: T1 = rl1(B) r1(B) wl1(B) w1(B, B-50) u1(B) rl1(A) r1(A) wl1(A) w1(A, A+50) u1(A) c1 A transao T2 apresenta o saldo total das contas A e B, isto , a soma A+B e definida por: T2 = rl2(A) r2(A) u2(A) rl2(B) r2(B) u2(B) Display(A+B) c2 Suponha agora, que os desbloqueios sejam realizados ao final da transao. A transao T3 similar transao T1, com desbloqueio ao final da transao, e definida como: T3 = rl1(B) r1(B) wl1(B) w1(B, B-50) rl1(A) r1(A) wl1(A) w1(A, A+50) u1(B) u1(A) c1 A transao T4 corresponde T2, com desbloqueio ao final da transao, e definida como: T4 = rl2(A) r2(A) rl2(B) r2(B) Display(A+B) u2(A) u2(B) c2 Observe agora a execuo a seguir (figura 2.7).
95
T3 rl1(B) r1(B) wl1(B) w1(B, B-50)
T4
rl2(A) r2(A) rl2(B) rl1(A) r1(A) wl1(A) Figura 2.7. Execuo Concorrente S1 (Exemplo 5). Observe que no momento em que a transao T4 tenta obter um bloqueio de leitura sobre o item de dado B (rl2(B)), este j se encontra bloqueado em um modo incompatvel (escrita) pela transao T3. Logo, a transao T4 ir esperar at que a transao T3 libere seu bloqueio de escrita sobre o item B. Assim, a transao T4 ter sua execuo suspensa at que ela possa obter um bloqueio de leitura sobre o item B. Contudo, a transao T3 continua sua execuo. No momento em que a transao T3 tenta obter um bloqueio de escrita sobre o item de dado A (wl1(A)), este j se encontra bloqueado em um modo incompatvel (leitura) pela transao T4. Logo, a transao T3 ir esperar at que a transao T4 libere seu bloqueio de escrita sobre o item A. Assim, a transao T3 ter sua execuo suspensa at que ela possa obter um bloqueio de leitura sobre o item A. Neste momento, chega-se a uma situao de impasse (deadlock), ou seja, nenhuma das duas transaes
96
prossegue sua execuo. A transao T4 est esperando pela transao T3 e a transao T3 est esperando pela transao T4.
Para solucionar alguns destes problemas surgiu a idia do protocolo de bloqueio em duas fases. 2.1.3. Protocolo de Bloqueio em Duas Fases (Bsico) O protocolo de bloqueio em duas fases (two phase lock 2PL) semelhante ao protocolo de bloqueio bsico, contudo exige que cada transao emita suas solicitaes de bloqueio e desbloqueio em duas fases: 1 Fase de expanso: uma transao est nesta fase quando ela pode obter bloqueios, mas no pode liberar nenhum; 2 Fase de encolhimento: uma transao pode liberar bloqueios, mas no consegue obter nenhum bloqueio novo.
Figura 2.6. Fases do protocolo 2PL.
97
Inicialmente uma transao est em fase de expanso. A transao adquire os bloqueios de que precisa. To logo a transao libera um bloqueio ela entra em fase de encolhimento. Considere qualquer transao, o ponto da escala no qual a transao obteve seu ltimo bloqueio (fim da fase de expanso) chamado ponto de bloqueio da transao. Assim, as transaes podem ser ordenadas de acordo com seus pontos de bloqueio. Agora, considere novamente a execuo concorrente
(schedule) S1 discutida no Exemplo 3 (figura 2.5):
S1 = rl1(B) r1(B) wl1(B) w1(B, B-50) u1(B) rl2(A) r2(A) u2(A) rl2(B) r2(B) u2(B) Display(A+B) c2 rl1(A) r1(A) wl1(A) w1(A, A+50) u1(A) c1
Observe que esta execuo concorrente no seria produzida pelo protocolo 2PL bsico, pois uma vez que a transao T1 libera o bloqueio obtido sobre o item B (u1(B)) est transao entra na fase de encolhimento e no pode mais obter bloqueios. Assim, a transao T1 no poderia obter o bloqueio sobre o item A (rl1(A)). Assim, podemos observar que o protocolo 2PL bsico evita o fenmeno leitura suja. Esta propriedade decorre do seguinte fato: quando uma transao Ti obtm um bloqueio de escrita sobre um determinado item de dado x, nenhuma outra transao TJ poder ler o item x at que a transao Ti libere o bloqueio de escrita obtido sobre x e, a ps Ti liberar o bloqueio sobre x, Ti entra na fase de encolhimento, no podendo mais obter nenhum bloqueio. Considere novamente a execuo concorrente (schedule) S1 discutida no Exemplo 4:
S1 = rl1(x) r1(x) u1(x) rl2(x) r2(x) u2(x) rl1(y) r1(y) u1(y) wl1(x) w1(x) u1(x) wl2(x) w2(x) u2(x) c1 c2
98
Observe que esta execuo concorrente tambm no seria produzida pelo protocolo 2PL bsico, pois uma vez que as transaes (T1 e T2) liberam o bloqueio obtido sobre o item x, estas transaes entram na fase de encolhimento e no podem mais obter bloqueios. Assim, podemos observar que o protocolo 2PL evita tambm o fenmeno da atualizao perdida (lost update). Contudo, caso as operaes das transaes T1 e T2 fossem enviadas a um escalonador 2PL seguindo a mesma ordem apresentada em S1 teramos uma execuo S2 na qual, para cada transao (T1 e T2), as liberaes de bloqueios seriam realizadas em algum momento aps a obteno do ltimo bloqueio. Assim a transao T1, por exemplo, somente iria realizar uma liberao de bloqueio aps obter seu ltimo bloqueio. O mesmo ocorrendo com a transao T2. S2 = rl1(x) r1(x) rl2(x) r2(x) rl1(y) r1(y) wl1(x) wl2(x) ... Observando a execuo concorrente S2 podemos notar que a transao T1, ao tentar obter um bloqueio de escrita sobre o item x (wl1(x)), ter sua execuo suspensa e ficar esperando at que a transao T2 libere o bloqueio de leitura (rl2(x)) anteriormente obtido sobre o item x. A transao T2 segue sua execuo. Contudo, no momento em que a transao T2 tenta obter um bloqueio de escrita sobre o item de dado x, T2 ter sua execuo suspensa e ficar esperando at que a transao T1 libere o bloqueio de leitura (rl1(x)) anteriormente obtido sobre o item x. Desta forma, ocorrer uma situao de impasse (deadlock) onde nenhuma das duas transaes (T1 e T2) conseguir prosseguir com sua execuo. Logo, podemos concluir que o protocolo de bloqueio em duas fases no garante a ausncia de deadlocks.
99
Exemplo 6 Considere as seguintes as seguintes transaes: T1=w1(x,2) r1(z) c1 T2= r2(u) r2(x) w2(y,x+3) c2 Suponha agora a execuo concorrente ilustrada pelo schedule S1. S1= rl2(u) r2(u) wl1(x) w1(x,2) u1(x) rl2(x) r2(x) wl2(y) w2(y, x+3) u2(u) u2(x) u2(y) c2 a1 Observe que o schedule S1 pode ser gerado pelo protocolo 2PL bsico, pois uma vez que a transao T1 libera o bloqueio obtido sobre o item de dado x, esta entra na fase de encolhimento e no solicita mais nenhum bloqueio. Contudo, a execuo S1 no confivel (recupervel) uma vez que w1(x,2) <S1 r2(x) e c1 no precede c2 em S1. Assim, o abort da transao T1 deveria causar o abort de T2, uma vez que T2 leu um valor escrito por T1. Contudo a transao T1 j commitou (concluiu) e no pode mais ser desfeita. Logo, podemos concluir que o protocolo 2PL bsico pode gerar execues (schedules) no confiveis, ou seja, no
recuperveis. Conseqentemente, o protocolo 2PL bsico no evita aborts em cascata e nem gera execues precisas (strict). Contudo, o protocolo 2PL bsico assegura a gerao de execues (schedules) serializveis por conflito.
100
2.1.3. Protocolo de Bloqueio em Duas Fases Preciso (Strict) O protocolo de bloqueio em duas fases severo exige, em adio ao bloqueio feito em duas fases, que todos os bloqueios de modo exclusivo tomados por uma transao sejam mantidos at que a transao seja efetivada. Assim, a transao est na fase de expanso at terminar. Essa exigncia garante que qualquer dado escrito por uma transao que no foi ainda efetivada seja bloqueado de modo exclusivo at que a transao seja efetivada, evitando que qualquer outra transao lei os dados em transio. Assim, todos os bloqueios exclusivos so liberados somente aps a operao de commit ou abort.
Figura 2.7. Fases do protocolo 2PL Preciso. A grande vantagem do protocolo 2PL Preciso que este gera execues serializveis e confiveis (estritas). Contudo, este protocolo no est livre da ocorrncia de deadlocks. Considere novamente a execuo S1 do exemplo 6: S1= rl2(u) r2(u) wl1(x) w1(x,2) u1(x) rl2(x) r2(x) wl2(y) w2(y, x+3) u2(u) u2(x) u2(y) c2 a1
101
Observe que este schedule no seria gerado pelo protocolo 2PL Preciso, pois a operao u1(x) s poderia ser realizada aps o
commit ou abort de T1. Conseqentemente, a transao T2 no conseguiria obter o bloqueio de leitura sobre o item x (rl2(x)) e ficaria esperando at que a transao T1 libere o bloqueio de escrita anteriormente obtido sobre o item x. Assim, a execuo gerada pelo protocolo 2PL Preciso seria: S2= rl2(u) r2(u) wl1(x) w1(x,2) a1 ...
2.1.4. Protocolo de Bloqueio em Duas Fases Rigoroso Este protocolo exige que os bloqueios (tanto compartilhados quanto exclusivos) sejam mantidos at que a transao seja efetivada. Pode facilmente ser verificado que, com o bloqueio em duas fases rigoroso, as transaes podem ser serializadas na ordem de sua efetivao. A maioria dos sistemas de banco de dados implementa os dois tipos de bloqueios em duas fases. A desvantagem deste protocolo que o grau de concorrncia ainda mais limitado que no protocolo 2PL Preciso. Alm disso, o protocolo 2PL Rigoroso no evita a ocorrncia de deadlocks.
2.1.5. Protocolo de Bloqueio em Duas Fases Conservador Neste protocolo, tambm conhecido como 2PL Conservador ou 2PL esttico, uma transao deve bloquear todos os itens de dados que deseja antes de iniciar qualquer operao. Caso no seja possvel bloquear todos os itens necessrios nenhum bloqueio realizado e a transao no inicia sua execuo. Neste caso, a transao deve esperar e tentar novamente em num momento futuro.
102
Figura 2.8. Fases do protocolo 2PL Conservador.
A grande vantagem do protocolo 2PL conservador evitar a formao de deadlocks. Pois, quando uma transao inicia sua execuo ela j detm todos os bloqueios de que necessita, logo ela no entrar em deadlock com nenhuma outra transao durante sua execuo. Assim, quando a transao inicia ela j est na fase de encolhimento. Contudo, o problema deste protocolo que a espera pela aquisio de todos os bloqueios necessrios pode apresentar um desempenho invivel na prtica, o que decorre do baixo grau de concorrncia proporcionado pelo protocolo.
103
2.2. Tratamento de Impasse (deadlock)
protocolo
2PL
Conservador
assegura
que
os
escalonamentos (schedules) gerados no apresentam situaes de impasse (deadlock). Contudo, as restries impostas pelo protocolo diminuem sobremaneira o grau de concorrncia. Por este motivo, o protocolo 2PL Conservador praticamente no utilizado pelos SGBDs. Por outro lado, as demais verses do protocolo 2PL no esto livres das situaes de impasse. Logo, torna-se necessrio desenvolver e utilizar alguma tcnica para tratar os impasses (deadlocks). Neste sentido, duas abordagens so possveis: 1. Deteco e Resoluo: Esta abordagem no evita a ocorrncia de deadlocks. Mas, pelo contrrio, aceita que eles possivelmente iro ocorrer. Logo, ser necessrio, primeiramente, detectar a ocorrncia de um deadlock, e, em seguida, usar alguma estratgia para solucionar o impasse. 2. Preveno: Esta abordagem utiliza tcnicas que
asseguram que uma situao de impasse (dedalock) nunca ir ocorrer. 2.2.1. Deteco e Resoluo
1. Deteco por Timeout Nesta tcnica, definido um tempo mximo pelo qual uma transao pode esperar por um bloqueio. Assim, se o tempo de espera de uma transao Ti por um determinado bloqueio atingir o tempo limite estipulado, o escalonador (scheduler) supe que Ti esteja envolvida em uma deadlock.
104
Uma vez que o escalonar supe que uma transao Ti esteja envolvida em uma situao de impasse, ele precisa solucionar (resolver) esta situao. A soluo consiste em abortar a transao Ti. Esta estratgia apresenta dois problemas principais: a) Pode ser que a transao Ti no estivesse envolvida em um deadlock; b) A deteco de deadlocks pode demorar longos perodos de tempo, ou seja, uma situao de deadlock s percebida aps o tempo mximo de esperar ser
ultrapassado. Assim, a situao de impasse no detectada no momento em que ela ocorre, e sim em um momento posterior.
2. Grafo de Espera (Wait-For) Nesta estratgia, o escalonador mantm um grafo onde os ns representam as transaes e as arestas so construdas da seguinte forma: Se uma transao Ti est esperando que outra transao Tj libere um bloqueio, ento uma aresta Ti Tj deve ser inserida no grafo. Se a incluso da aresta Ti Tj produzir um ciclo no grafo ento Ti e Tj esto envolvidas em um deadlock. A soluo para a situao de impasse identificada consiste em abortar a transao mais recente. Ou seja, a transao mais nova escolhida como vtima.
105
Exemplo 7 Considere o seguinte conjunto de transaes: T1 = rl1(x) r1(x) rl1(y) r1(y) wl1(x) w1(x) u1(x) u1(y) c1 T2 = rl2(x) r2(x) wl2(x) w2(x) u2(x) c2
Considere agora a seguinte execuo (schedule): S1 = rl1(x) r1(x) rl2(x) r2(x) rl1(y) r1(y) wl1(x) wl2(x) ...
A figura 2.9 ilustra o grafo wait-for para o schedule S1. Observe que a transao T1 ao tentar obter um bloqueio de escrita sobre o item x (wl1(x)) ir esperar pela transao T2, uma vez que T2 j detm um bloqueio (leitura), rl2(x), em modo incompatvel com o bloqueio desejado por T1. Neste momento, uma aresta T1 T2 ser no grafo wait-for. Em seguida, a transao T2 tenta obter um bloqueio de escrita sobre o item x (wl2(x)). Contudo, como a transao T1 j detm um bloqueio (leitura), rl1(x), em modo incompatvel com o bloqueio desejado por T2. Logo, T2 vai esperar por T1 e uma aresta T2 T1 ser inserida no grafo wait-for. Porm, esta nova aresta introduz um ciclo no grafo wait-for. Assim, o escalonador ir detectar que T1 e T2 esto envolvidas em uma situao de impasse (deadlock). A transao T2, por ser mais recente (iniciou sua execuo aps a transao T1) ser escolhida como vtima, e, conseqentemente, ser abortada.
Figura 2.9. Grafo Wait-For para o Schedule S1 no Exemplo 7.
106
2.2.2. Preveno de Impasses (Deadlocks)
1. Bloqueio de Atualizao (Update) A estratgia do bloqueio de atualizao (update) surgiu da constatao de que 90% das situaes de impasse (deadlocks) eram produzidos pela converso de bloqueios de leitura em bloqueios de escrita, o que ocorre quando uma transao obtm um bloqueio de leitura, efetua a leitura e, posteriormente, tenta obter um bloqueio de escrita sobre o mesmo item de dado. A idia bsica desta tcnica consiste em utilizar um novo tipo de bloqueio: o bloqueio de atualizao (ou update). Um bloqueio de atualizao consiste em um bloqueio de leitura com a inteno de executar uma operao de escrita no futuro. O objetivo reduzir as converses de bloqueio de leitura para bloqueio de escrita. A figura 2.10 mostra a tabela de compatibilidade de bloqueios considerando agora a operao bloqueio de atualizao, representada por uli.
Figura 2.10. Tabela de Compatibilidade de Bloqueios.
Observe ento como ficaria a execuo discutida no Exemplo 7 se o conceito de bloqueio de atualizao fosse utilizado: T1 = ul1(x) r1(x) rl1(y) r1(y) w1(x) u1(x) u1(y) c1 T2 = ul2(x) r2(x) w2(x) u2(x) c2
S1 = ul1(x) r1(x) ul2(x) rl1(y) r1(y) wl1(x) u1(x) u1(y) c1 r2(x) w2(x) u2(x) c2 107
Note que a transao T2, ao tentar obter um bloqueio de atualizao sobre o item de dado x (ul2(x)), ficar esperando pela transao T1, uma vez que T1 j detm um bloqueio sobre o item x (ul1(x)) incompatvel com o tipo de bloqueio solicitado por T2 (ul2(x)). Assim, neste momento, T2 ficar suspensa at que a transao T1 libere seu bloqueio sobre o item x. Contudo, a transao T1 continua sua execuo normalmente. J a transao T2 s continuar sua execuo quando a transao T1 entrar na fase de encolhimento e liberar o bloqueio sobre o item x. Logo, a situao de impasse no ocorrer. Podemos perceber que esta estratgia evita a formao de deadlocks. concorrncia. Contudo, reduz substancialmente o grau de
2. Soluo por Timestamp A idia desta abordagem para evitar a formao de deadlocks baseia-se na utilizao de marcadores de tempo (timestamps). A seguir descreveremos mais detalhadamente esta tcnica. Primeiramente, precisamos definir uma ordenao temporal entre as transaes. Para isso, cada transao Ti possui um marcador de tempo (timestamp), representado por ts(Ti), o qual ir representar a ordem em que as transaes iniciaram suas execues. Desta forma:
Se Ti inicia sua execuo antes de Tj ento: ts(Ti) < ts(Tj)
Ou seja, neste caso, Ti uma transao mais antiga que Tj.
108
Quando uma transao Ti solicitar um bloqueio sobre um item de dado j bloqueado por Tj, duas estratgias so possveis:
wait-die: Se ts(Ti) < ts(Tj) ento //Ti mais antiga que Tj Ti espera Se no //Ti mais recente que Tj Abortar Ti //Transao mais recente abortada. Fim Se
Nesta estratgia, as transaes mais antigas podem esperar por uma transao mais recente. J as transaes mais novas no esperam por uma transao mais antiga, sendo ento canceladas. Assim, medida que uma transao fica mais antiga, ela tende a esperar pelas transaes mais jovens.
wound-wait: Se ts(Ti) < ts(Tj) ento //Ti mais antiga que Tj Abortar Ti //Transao mais recente abortada. Se no //Ti mais recente que Tj Ti espera Fim Se
Nesta estratgia, as transaes mais recentes podem esperar por uma transao mais antiga. J as transaes mais antigas no esperam por uma transao mais nova, neste caso, as transaes mais antigas provocam o abort das transaes mais jovens.
109
Vale destacar que nas duas estratgias sempre a transao mais recente escolhida como vtima. Assim, as transaes mais antigas so priorizadas. Esta escolha decorre da expectativa que as transaes mais jovens tenham executado uma quantidade menor de operaes, logo o trabalho a ser refeito deve ser menor. Contudo, esta escolha apresenta o risco de que uma determinada transao Tj (jovem) seja sempre escolhida como vtima, sendo sempre reiniciada, ao envolver-se em deadlocks com transaes mais antigas. Assim, Tj poderia ser abortada continuamente, fenmeno denominado de livelock, ou enfraquecimento. A soluo para esta situao consiste em ao reiniciar uma transao Tj no reiniciar o seu timestamp (ts(Tj)), ou seja, manter um nico timestamp para cada transao. Desta forma, razovel esperar que as transaes mais antigas que Tj em algum momento concluam sua execuo, ficando Tj como a transao mais antiga, passando a ter prioridade sobre as transaes mais recentes que ela.
Exemplo 8 Considere o seguinte conjunto de transaes: T1 = rl1(x) r1(x) rl1(y) r1(y) wl1(x) w1(x) u1(x) u1(y) c1 T2 = rl2(x) r2(x) wl2(x) w2(x) u2(x) c2
Considere agora a seguinte execuo (schedule): S1 = rl1(x) r1(x) rl2(x) r2(x) rl1(y) r1(y) wl1(x) wl2(x) ...
Vamos assumir que: ts(T1) = 1 ts(T2) = 2
110
Assim, a transao T1 mais antiga que T2.
Supondo que a estratgia wait-die seja utilizada teramos: S1 = rl1(x) r1(x) rl2(x) r2(x) rl1(y) r1(y) wl1(x) wl2(x) a2 ...
Neste exemplo, vale destacar que quando uma transao T1 solicita um bloqueio de escrita sobre o item de dado x (wl1(x)), este j est bloqueado por T2 (rl2(x)) em um modo incompatvel. Neste caso, teremos: ts(T1) < ts(T2) Logo, T1 ir esperar por T2, ou seja, T1 ir esperar at que T2 libere o seu bloqueio sobre x (rl2(x)). A transao T2 prossegue sua execuo. Quando a transao T2 solicita um bloqueio de escrita sobre o item de dado x (wl2(x)), este j est bloqueado por T1 (rl1(x)) em um modo incompatvel. Neste caso, teremos: ts(T2)
<
ts(T1)
Logo, T2 ser cancelada (abortada) e seus bloqueios liberados. O escalonamento gerado mostrado a seguir. S1 = rl1(x) r1(x) rl2(x) r2(x) rl1(y) r1(y) wl1(x) wl2(x) a2 w1(x) u1(x) u1(y) c1 rl2(x) r2(x) wl2(x) w2(x) u2(x) c2
Agora, suponha que a estratgia wound-wait seja utilizada.
Neste caso, quando uma transao T1 solicita um bloqueio de escrita sobre o item de dado x (wl1(x)), este j est bloqueado por T2 (rl2(x)) em um modo incompatvel. Neste caso, teremos: ts(T1) < ts(T2)
111
Logo,
transao
T2
ser
cancela
(abortada)
escalonamento (schedule) gerado mostrado a seguir.
S1 = rl1(x) r1(x) rl2(x) r2(x) rl1(y) r1(y) wl1(x) a2 w1(x) u1(x) u1(y) c1 rl2(x) r2(x) wl2(x) w2(x) u2(x) c2
Assim, podemos observar que as duas abordagens evitam a formao de deadlocks. Contudo, ambas aumentam de forma significativa a quantidade de aborts.
2.3. Granularidade de Bloqueios Nos protocolos de controle de concorrncia descritos at agora, cada operao de bloqueio era realizada sobre um nico item de dado, de forma individual. Assim, para bloquear uma tabela inteira com 2000 itens de dados sero necessrios no mnimo 2000 bloqueios (uma vez que um determinado item de dado pode estar bloqueado de forma compartilhada, leitura, por mais de uma transao). Logo, a tabela de bloqueios gerenciada pelo escalonador dever ter no mnimo 2000 entradas, o que gera uma sobrecarga (overhead) considervel. Desta forma, h circunstncias em que pode ser vantajoso o agrupamento de diversos itens de dados, a fim de trat-los como uma unidade de sincronizao individual. Por exemplo, para bloquear uma tabela por completo poderia ser utilizada uma nica operao de bloqueio, o que reduziria o overhead de gerenciamento da tabela de bloqueios. Neste caso, a granularidade do bloqueio seria a tabela inteira. Por outro lado, se uma transao Ti precisa acessar somente alguns itens de dados, no necessrio bloquear toda a tabela, porque, deste modo, estaramos limitando a concorrncia.
112
Assim, torna-se necessrio definir um mecanismo que permita ao SGBD utilizar nveis mltiplos de granulao (ou granularidade). O ponto de partida para isso a identificao das diferentes granularidades (figura 2.11).
Figura 2.11. Relacionamento entre as Diferentes Granularidades.
A idia principal consiste em que o bloqueio de um determinado objeto (n) no grafo de granularidades implica que seus descendentes so implicitamente bloqueados (com o mesmo tipo de bloqueio). Alm disso, propagam-se para os seus ascendentes os efeitos do bloqueio. A fim de ilustrao considere a rvore da figura 2.12, a qual consiste em quatro (4) nveis de ns. O nvel mais alto representa o banco de dados (BD) como um todo. Abaixo, h ns do tipo rea; o BD constitudo exatamente dessas reas. Cada rea, por sua vez, possui ns do tipo arquivo/relao/tabela como filhos. Cada rea constituda exatamente daquelas tabelas que so seus ns filhos. Nenhuma tabela est em mais de uma rea. Finalmente, cada tabela possui ns do tipo registro/tupla. Nenhum registro pode estar em mais de um arquivo.
113
Figura 2.12. Estrutura do Banco de Dados.
A partir dessa idia foi concebido o protocolo de bloqueio em duas fases com granularidade mltipla. Neste protocolo, cada n de uma rvore pode ser bloqueado de forma individual. Alm disso, duas novas operaes de bloqueio so adicionadas: Bloqueio intencional de leitura (irl); Bloqueio intencional de escrita (iwl); Desta forma, uma nova tabela de compatibilidade de bloqueios necessita ser definida (figura 2.13).
Figura 2.13. Tabela de Compatibilidade de Bloqueios.
114
Um bloqueio intencional (ou de advertncia) de leitura representa a inteno de obter um bloqueio compartilhado sobre um elemento secundrio. As regras do protocolo so:
a) Para impor um bloqueio de leitura ou escrita sobre um determinado elemento (n), devemos comear pela raiz da hierarquia. b) Se estamos no elemento que queremos bloquear, no precisamos examinar mais nada. Solicitamos o bloqueio desejado sobre esse elemento. c) Se o elemento que desejamos bloquear estiver mais abaixo na hierarquia, devemos inserir uma advertncia (inteno) nesse n; isto , se quisermos obter um bloqueio
compartilhado sobre um elemento secundrio, solicitaremos um bloqueio intencional de leitura sobre esse n e, se quisermos um bloqueio exclusivo sobre um elemento secundrio, solicitaremos um bloqueio intencional de escrita sobre esse n. Quando o bloqueio sobre o n atual for concedido, prosseguiremos at o final apropriado.
A seguir discutimos alguns aspectos do protocolo: Quando solicitamos um bloqueio intencional de leitura sobre um n N, pretendemos ler um descendente de N. O nico momento em que essa inteno poderia criar um problema se alguma outra transao j tivesse reivindicado o direito de gravar uma nova cpia do elemento do BD inteiro representado por N. Observe que, se alguma outra transao tiver inteno de gravar apenas um elemento secundrio, indicado por um bloqueio intencional de escrita em N, ento poderemos ter condies de conceder o bloqueio intencional de leitura em N e permitir que o conflito seja resolvido em um
115
nvel mais baixo, se de fato a inteno de gravao e a inteno de leitura envolverem um elemento comum. Quando se pretende gravar um elemento secundrio do n N, devemos evitar a leitura e gravao do elemento inteiro representado por N. Contudo, um bloqueio intencional de escrita no entrar em conflito com outro bloqueio intencional de escrita em N ou com um bloqueio intencional de leitura em N. A operao de leitura sobre o elemento correspondente ao n N no pode entrar em conflito com outro bloqueio de leitura sobre N ou com um bloqueio de leitura sobre um elemento secundrio de N, representado por um bloqueio intencional de leitura em N. Porm, um bloqueio de escrita ou um bloqueio intencional de escrita implica significa que alguma outra transao gravar pelo menos uma parte do elemento representado por N. Portanto, no poderemos conceder o direito de ler N inteiro. No podemos permitir a gravao de todo o n N, se qualquer outra transao j tiver o direito de ler ou gravar N, ou j tiver adquirido esse direito sobre um elemento secundrio.
Resumindo, o protocolo de bloqueio de granularidade mltipla garante a serializao. Cada transao Ti pode bloquear um n Q, usando as seguintes regras: 1. A funo de compatibilidade precisa ser observada; 2. A raiz da rvore precisa ser bloqueada primeiro, e pode ser bloqueada em qualquer modo 3. Um n Q pode ser bloqueado por Ti no modo leitura ou intencional de leitura somente se o pai de Q for bloqueado por Ti no modo intencional de escrita ou intencional de leitura.
116
4. Um n Q pode ser bloqueado por Ti no modo escrita ou intencional de escrita somente se o pai de Q for bloqueado por Ti no modo intencional de escrita. 5. Ti pode bloquear um n somente se ele no desbloqueou outro n anteriormente (isto , Ti tem duas fases). 6. Ti pode desbloquear um n Q somente se nenhum dos filhos de Q estiver bloqueado por Ti.
Vale destacar que o protocolo 2PL com mltipla granularidade exige que os bloqueios sejam feitos de cima para baixo (top-down da raiz para as folhas), enquanto a liberao deve ser de baixo para cima (bottom-up das folhas para a raiz).
Exemplo 9 Considere a tabela a seguir: FILME(Ttulo, Ano, Durao, Produtora) Agora, considere as seguintes transaes:
T1 :
SELECT * FROM Filme WHERE Ttulo = Filme1;
T2 :
UPDATE Filme SET Ano = 1939 WHERE Ttulo = Filme2;
T1 irl T2 - iwl Filme
Filme1
T1 rl
Filme1
T1 rl
Filme2
T2 wl
Figura 2.14. Exemplo de Bloqueio com Granularidade Mltipla. 117
A transao T1 comea obtendo um bloqueio intencional de leitura sobre a relao inteira. Em seguida, ele se desloca para as tuplas individuais (h 2 filmes com o nome Filme1) e obtm o bloqueio de leitura sobre cada uma delas. Suponha que enquanto a transao T1 est sendo executada, a transao T2, que altera o ano de uma tupla, inicie sua execuo. Neste caso, T2 precisa de um bloqueio intencional de escrita sobre a relao, pois planeja gravar um novo valor para uma das tuplas. O bloqueio intencional de leitura de T1 sobre a relao compatvel, e assim o bloqueio concedido. Quando T2 chega na tupla Filme2, no encontra nenhum bloqueio l, e assim recebe seu bloqueio de escrita e atualiza a tupla. Caso T2 tentasse gravar um novo valor na tupla para um dos filmes Filme1, ela teria de esperar at T1 liberar seu bloqueio de leitura, pois leitura e escrita no so compatveis.
2.4. Bloqueio em Duas Fases com Mltiplas Verses A idia principal dos protocolos baseados em mltiplas verses consiste em reduzir a taxa de bloqueios atravs da utilizao de mais de uma verso de cada item de dado. A seguir descreveremos o protocolo baseado em mltiplas verses mais popular: o protocolo de bloqueio em duas fases com duas verses (two version two phase lock 2V2PL).
2.4.1. Protocolo 2V2PL
118
Princpios de Funcionamento Os princpios gerais que norteiam o protocolo 2V2PL so discutidos a seguir:
Para cada objeto x duas verses so mantidas: x e xi Uma operao de escrita de uma transao Tk sobre um objeto x gera uma nova verso xi de x
Para executar a operao de escrita: Tk obtm primeiro um bloqueio de escrita sobre x para prevenir que nenhuma outra transao Leia xi ou Escreva uma nova verso de x Qualquer outra transao pode ler x
Quando Tk executa seu commit, xi torna-se a nica verso de x A verso anterior torna-se inacessvel
Vantagens Podemos observar que o protocolo 2V2PL apresenta duas vantagens principais, so elas:
Leituras sobre x no so atrasadas devido a uma escrita sobre x
Escritas sobre x no so atrasadas devido a uma leitura sobre x
Implementao do Protocolo 2V2PL
119
A implementao do protocolo 2V2PL baseia na utilizao de um novo tipo de bloqueio: o bloqueio de certificao (ou certify lock), denotado por cli(x). A compatibilidade do bloqueio de certificao em relao aos bloqueios de leitura (compartilhado) e escrita (exclusivo) apresentada na figura 2.15.
Figura 2.15. Tabela de Compatibilidade de Bloqueios do Protocolo 2V2PL.
Para assegurar a gerao de escalonamentos (schedules) precisos, os bloqueios s so liberados aps a operao de commit. A figura 2.16 ilustra um algoritmo que pode ser utilizado para implementar o protocolo 2V2PL.
1. Quando o escalonador recebe uma operao de escrita wj(x) Tenta obter wlj(x) conforme a tabela de compatibilidade de bloqueios Se existe wlI(x) ou clI(x) ento: O escalonador retarda wlj(x) Se no Concede o bloqueio wlj(x) Converte wj(x) em wj(xn) e envia wj(xn) para processamento Fim Se 2. Quando o escalonador recebe uma operao de leitura rj(x) Tenta obter rlj(x) Se rlj(x) for obtido ento: Se Tj j possua wlj(x) e j executou wj(xn) ento: Mapear rj(x) em rj(xn) e enviar rj(xn) para processamento Se no Enviar rj(x) 120 Fim Se Fim Se
Figura 2.16. Algoritmo do Protocolo 2V2PL.
Comentrios O protocolo 2V2PL produz escalonamentos (schedules)
serializveis por conflito e precisos, ou seja, histrias corretas e que evitam aborts em cascata. Alm disso, este protocolo apresenta um grau de paralelismo maior, uma vez que um mesmo item pode ser lido e escrito por transaes diferentes de forma simultnea. Por estes motivos, o protocolo 2V2PL ganhou enorme popularidade e, atualmente, j implementado pelos principais SGBDs (Oracle, PostgreSQL, SQLServer, dentre outros).
Exemplo 10 Considere o seguinte conjunto de transaes: T1 = rl1(x) r1(x) rl1(y) r1(y) wl1(x) w1(x) c1 u1(x) u1(y) T2 = rl2(x) r2(x) rl2(y) r2(y) c2 u2(x) u2(y)
Considere agora a seguinte execuo (schedule): S1 = rl1(x) r1(x) rl2(x) r2(x) rl1(y) r1(y) wl1(x) w1(x) rl2(y) r2(y) c2 u2(x) u2(y) c1 u1(x) u1(y) O Schedule S1 pode ser gerado por um escalonador que utiliza o protocolo 2V2PL. Observe que a operao w1(x) no ser atrasada devido a existncia (execuo prvia) da operao r2(x). 121
Note tambm que quando a transao T1 tentar executar o seu commit, o bloqueio de escrita wl1(x) poder ser convertido em um bloqueio de certificao (certify lock) uma vez que a transao T2 j executou o seu commit e, conseqentemente, j liberou o bloqueio rl2(x). Considere agora o schedule S2. S2 = rl1(x) r1(x) rl2(x) r2(x) rl1(y) r1(y) wl1(x) w1(x) c1 ... Observe que neste exemplo a operao de commit da transao T1 chegou ao escalonador antes do commit da transao T2. Neste caso, o escalonador ir tentar converter o bloqueio de escrita wl1(x) em um bloqueio de certificao cl1(x). Contudo, essa converso no poder ser realizada uma vez que existe um bloqueio, anteriormente obtido pela transao T2 (rl2(x)), o qual incompatvel com cl1(x). Neste caso, a transao T1 ir esperar pelo commit da transao T2. Aps o commit de T2, a transao T1 poder realizar o seu commit, o que resultar no schedule S1. Vale destacar que o schedule S1 no seria gerado por um protocolo 2PL Estrito (apesar de ser um escalonamento correto), uma vez que a operao wl1(x) no seria executada enquanto a transao T2 no executasse o seu commit, liberando o bloqueio rl2(x). No caso de utilizao do protocolo 2PL estrito o schedule gerado seria S3. Assim, podemos concluir que o protocolo 2V2PL permite um grau de concorrncia (entrelaamentos) maior que o protocolo 2PL Estrito.
S3 = rl1(x) r1(x) rl2(x) r2(x) rl1(y) r1(y) rl2(y) r2(y) c2 u2(x) u2(y) wl1(x) w1(x) c1 u1(x) u1(y)
Exemplo 11
122
Considere o seguinte conjunto de transaes: T1 = rl1(x) r1(x) rl1(y) r1(y) wl1(x) w1(x) c1 u1(x) u1(y) T2 = rl2(x) r2(x) rl2(y) r2(y) wl2(y) w2(y) c2 u2(x) u2(y)
Considere agora a seguinte execuo (schedule): S1 = rl1(x) r1(x) rl2(x) r2(x) rl1(y) r1(y) wl1(x) w1(x) rl2(y) r2(y) wl2(y) w2(y) c2 c1 ... Observe que no momento em que a transao T2 solicita a execuo da sua operao de commit, o escalonador ir tentar converter o bloqueio de escrita wl2(y) em um bloqueio de certificao cl2(y). Contudo, essa converso no ser realizada, pois existe um bloqueio incompatvel, neste caso rl1(y). Logo, a transao T2 ir esperar at que a transao T1 libere o bloqueio rl1(y). Em seguida, a transao T1 solicita o seu commit e o escalonador ir tentar converter o bloqueio de escrita wl1(x) em um bloqueio de certificao cl1(x). Porm, essa converso no ser realizada, pois existe um bloqueio incompatvel, neste caso rl2(x). Logo, a transao T1 ir esperar at que a transao T2 libere o bloqueio rl2(x). Desta forma, a situao de impasse (deadlock) est formada. Logo, podemos concluir que o protocolo 2V2PL no est livre da ocorrncia de deadlocks.
Exemplo 12 Considere o seguinte conjunto de transaes: T1 = rl1(x) r1(x) wl1(x) w1(x) c1 u1(x) T2 = rl2(x) r2(x) wl2(x) w2(x) c2 u2(x)
Considere agora a seguinte execuo (schedule): S1 = rl1(x) r1(x) rl2(x) r2(x) wl1(x) w1(x) wl2(y) w2(y) c1 c2
123
Observe que o Schedule S1 no seria gerado pelo protocolo 2V2PL, uma vez que o bloqueio de escrita wl2(y) no seria concedido devido existncia de um bloqueio incompatvel (wl1(x)). Neste caso, a transao T2 seria atrasada at que a transao T1 fosse concluda. Assim, o protocolo 2V2PL iria gerar o schedule S2. S2 = rl1(x) r1(x) rl2(x) r2(x) wl1(x) w1(x) c1 Contudo, a transao T1 ao tentar executar seu commit ficaria esperando pela concluso de T2, uma vez que o escalonador no iria conseguir converter o bloqueio de escrita wl1(x) em bloqueio de certificao cl1(x) devido existncia de um bloqueio incompatvel (rl2(x)). Novamente, temos uma situao de deadlock.
124
2.5. Arquitetura de Gerenciadores de Transaes que Utilizam 2PL O gerenciador de transaes o mdulo do SGBD responsvel por gerenciar as transaes. A figura 2.14 ilustra uma possvel arquitetura para um gerenciador de transaes.
Figura 2.14. Arquitetura de um Gerenciador de Transaes.
A interface de transaes o componente responsvel por gerar o identificador (TRID) de cada transao. O gerenciador de bloqueios (lock manager) tem objetivo garantir que as requisies de bloqueios efetuadas pelos usurios sejam atendidas de forma eficiente, alm de proporcionar alto grau de concorrncia. Todo comando SQL, uma vez preparado para execuo, precisa interagir com o Lock Manager, para informar o recurso que precisa ser bloqueado, caso os recursos necessrios no possam ser bloqueados, o Lock Manager envia uma notificao de espera. Ao final de uma transao, interage-se com o Lock Manager avisando-o que bloqueios podem ser liberados. O Lock Manager tambm gerencia uma estrutura de dados interna onde so armazenadas as informaes sobre os recursos que esto bloqueados (identificador da transao, tipo de bloqueio, 125
identificador do objeto bloqueado, etc) e uma lista de espera, a qual indica que transaes esto esperando por quais recursos.
Assim, o gerenciador de bloqueios executa as operaes de bloqueio e desbloqueio (liberao), alm de gerenciar duas estruturas de dados: Arquivo de Bloqueios: Arquivo que contm as informaes sobre os bloqueios. Cada entrada neste arquivo armazena: o identificador da transao (TRID), o tipo de bloqueio e o identificador do objeto bloqueado (OID). Lista de Espera: Arquivo utilizado para armazenar as informaes das transaes que esto suspensas, esperando pela liberao de algum bloqueio. J o componente gerenciador de recuperao (recovery) responsvel por recuperar o estado consistente do banco de dados aps uma situao de falha. 2.6. Nveis de Isolamento O nvel de isolamento uma propriedade que define quando e como uma mudana feita por uma transao se torna visvel para outras transaes concorrentes. O Isolamento tambm uma das propriedades ACID. A maioria dos SGBDs permite definir o nvel de isolamento das transaes, permitindo assim controlar a relao entre o grau de concorrncia e o nvel de consistncia desejado. Um nvel de isolamento define: Escopo do bloqueio; Durao do bloqueio; Quanto ao escopo um bloqueio pode ser:
126
Bloqueio de objeto: Bloqueia um objeto (tupla, por exemplo) especfico do banco de dados; Bloqueio de predicado: Bloqueia um conjunto de objetos que satisfazem uma determinada condio. Assim, bloqueiam objetos existentes no banco de dados, objetos ainda no existentes no banco de dados, mas que satisfariam o predicado caso fossem includos no banco de dados, e, objetos a serem alterados, que passariam a satisfazer o predicado aps a alterao. Quanto durao um bloqueio pode ser: Bloqueio de curta durao: O bloqueio liberado imediatamente aps a execuo da operao associada ao bloqueio. A seguir mostramos um exemplo de bloqueio de objeto de curta durao: rli(x) ri(x) ui(x) ci O exemplo a seguir ilustra a utilizao de um bloqueio de predicado de curta durao: rli(x in P) ri(x in P) ui(x in P) ci
Bloqueio de longa durao: O bloqueio retido at que a operao de commit ou abort seja executada. A seguir apresentamos um exemplo de objeto de longa durao: rli(x) ri(x) ci ui(x) O exemplo a seguir ilustra a utilizao de um bloqueio de predicado de longa durao: rli(x in P) ri(x in P) ci ui(x in P) Neste ltimo exemplo, nenhuma outra transao TJ pode inserir ou atualizar objetos que satisfaam o predicado P, at que Ti libere o bloqueio de leitura sobre P, o que somente ocorre aps o commit de Ti. 127
Exemplo 13 Agora, observe um exemplo com a utilizao de um cursor onde o bloqueio utilizado de curta durao para objetos e de longa durao para predicados: Select * from Empregado where salario>499 Commit
Note que no momento que o cursor se mover da primeira tupla (05,'Andr', 5000, 1) para a segunda tupla (08, Brbara, 2000, 2), a primeira tupla no estar mais bloqueada, pois o bloqueio utilizado de curta durao para objetos. Contudo, uma nova tupla do tipo (07, Jos,500,1) no poderia ser inserida uma vez que esta nova tupla satisfaz o predicado utilizado no bloqueio (salario>499), o qual de longa durao para predicado. J se a tupla fosse (07, Jos,499,1) a insero seria permitida, uma vez que esta no satisfaz a condio utilizada no bloqueio.
2.6.1. Descrio dos Nveis de Isolamento Existem quatro nveis de isolamento definidos no padro ANSI/ ISO SQL. So eles: Read Uncommitted, Read Committed, Repeatable Read e o Serializable. Estes nveis so classificados de acordo com a possibilidade de ocorrncia de determinados fenmenos indesejados, que podem ser dirty reads, non128
repeatable reads e phantons. A figura a seguir ilustra o relacionamento entre os nveis de isolamento e os fenmenos.
Dirty Read Read Uncommitted Read Committed Repeatable Read Serializable Sim No No No
Non-Repeatable Phantom Read Sim Sim No No Sim Sim Sim No
Figura 2.XX: Nveis de Isolamento ANSI/ISSO SQL
A seguir, descrevemos cada um desses fenmenos: Dirty Read - Ocorre quando uma transao (T1) modifica
determinada informao e, em seguida, outra transao (T2) l a mesma informao antes que T1 realize sua operao de commit ou rollback (abort). Assim, caso a transao T1 seja cancelada (abortada), T2 ter lido uma informao que nunca chegou a existir oficialmente na base de dados. Non-Repeatable Read - Ocorre quando uma transao T1 l um determinado item de dado. Posteriormente, outra transao T2 apaga ou modifica esse item. Em seguida, quando a transao T1 tenta ler novamente o mesmo item de dado lido anteriormente, esta vai observar um valor diferente do valor lido inicialmente. Phantom Ocorre quando uma transao T1 l um conjunto de itens que satisfazem uma determinada condio de seleo. Em seguida, uma transao T2 modifica ou insere itens de dados que satisfazem a condio de seleo utilizada por T1. Depois disso, T1 repete a consulta executada anteriormente, com a mesma condio de seleo, obtendo, porm, um resultado diferente, por exemplo,
129
recuperando itens que no foram recuperados na primeira consulta (leitura). Agora que conhecemos os fenmenos que deseja-se evitar, podemos definir formalmente os diferentes nveis de isolamento do padro ANSI/ISSO SQL. Read Uncommitted Este o primeiro e menos proibitivo nvel de isolamento. Neste nvel podem ocorrer os trs fenmenos
estudados. Por outro lado, possibilita o maior grau de concorrncia, dentre os diferentes nveis de isolamento do padro SQL. Neste nvel de isolamento, temos que: Bloqueios de leitura: No so necessrios. Bloqueio de escrita: So de curta durao tanto para objetos (tuplas de uma tabela, por exemplo) quanto para predicados. Read Commited Este nvel o usado por padro no Oracle, PostgreSQL e SQL Server. Este nvel evita a ocorrncia do fenmeno leitura suja (Dirty Read). Porm, no evita os fenmenos leitura no repetvel (Non-Repeatable
Read) e fantasma (Phantom). Este nvel de isolamento um pouco mais forte que o Read Uncommitted, logo a consistncia dos dados um pouco mais rigorosa enquanto o grau de concorrncia permitido um pouco menor. Neste nvel de isolamento, temos que: Bloqueios de leitura: So de curta durao tanto para objetos (tuplas de uma tabela) quanto para predicados. Bloqueio de escrita: So de longa durao tanto para objetos (tuplas de uma tabela) quanto para predicados. A seguir, exemplificamos algumas anomalias que podem ocorrer no nvel de isolamento Read Commite:
130
- Nonrepeatable read Considere o schedule S1: S1= r2(x) w1(x,2) c1 r2(x) c2 A transao T2 est lendo valores diferentes de x. O que deve ser evitado, apesar de ser improvvel que uma mesma transao execute duas operaes de leitura sobre o mesmo item de dado. - Lost update Considere o schedule S2: S2= r2(x) r1(x) w1(x,x+20) c1 w2(x, x+10) r2(z) c2 Observe que a operao de escrita w1(x) foi sobreposta pela operao w2(x).
Cursor Stability Este nvel de isolamento, apesar de no fazer parte originalmente do padro SQL, passou a ser utilizado pela maioria dos SGBDs. Bloqueios de leitura: So de curta durao objetos (tuplas de uma tabela). Os bloqueios de predicados so de curta durao, contudo o bloqueio no item corrente do cursor mantido at que o cursor seja movido ou o cursor seja fechado. Bloqueio de escrita: So de longa durao tanto para objetos (tuplas de uma tabela) quanto para predicados. O nvel de isolamento Cursor Stability evita o fenmeno atualizao perdida (lost update). Para ilustrar este fato, considere o exemplo a seguir: S3= r2(x) w1(x) c1 w2(x) r2(z) c2 Observe que o Schedule S3 no poderia ser produzido no nvel de isolamento Cursor Stability uma vez que o bloqueio de leitura obtido pela transao T2 sobre o item x somente ser liberado quando o cursor for movimentado para o prximo item de dado, o que s vai 131
ocorrer aps a transao T2 executar sua operao de escrita em x (ou seja, w2(x)). Repeatable Read Este nvel de isolamento evita os fenmenos leitura suja (Dirty Read) e leitura no repetvel (Non-Repeatable Read). Contudo, no evita o fenmeno fantasma (Phantom). Bloqueios de leitura: So de longa durao para objetos (tuplas de uma tabela) e de curta durao para predicados. Bloqueio de escrita: So de longa durao tanto para objetos (tuplas de uma tabela) quanto para predicados. Para ilustrar o funcionamento deste nvel de isolamento, considere novamente o exemplo a seguir: Select * from Empregado where salario>499 Commit
Neste caso, uma nova tupla (07,'Jos',4000,1) pode ser inserida na tabela uma vez que no nvel de isolamento Repeatable Read os bloqueios de leitura so de curta durao para predicados. J a tupla (05,'Andr', 5000, 1) ficar bloqueada at a execuo do commit da transao, uma vez que bloqueios de leitura so de longa durao para objetos.
Serializable Este o nvel de isolamento mais forte. Evita os trs fenmenos estudados. Contudo, apresenta o menor grau de concorrncia. Bloqueios de leitura: So de longa durao tanto para objetos (tuplas de uma tabela) quanto para predicados. 132
Bloqueio de escrita: So de longa durao tanto para objetos (tuplas de uma tabela) quanto para predicados.
2.6.2. Sintaxe SQL 99 A seguir ilustramos a sintaxe SQL utilizada para definir o nvel de isolamento a ser utilizado.
Figura 3.2: Sintaxe SQL 99 Vale destacar que o Oracle e PostGreSQL apenas implementam os nveis de isolamento Read Commited e Serializable. J o MS SQLServer implementa os nveis de isolamento Read Uncommited, Read Commited, Repeatable Read e Serializable. A escolha do nvel de isolamento importante deciso de projeto, que envolve decidir entre: Garantir consistncia dos objetos do banco de dados, ou seja, definir que anomalias devem ser evitadas (Nonrepeatable read, Lost update, etc) Garantir um alto grau de concorrncia.
133
2.9. Exerccios
1 - Sob que condies melhor evitar conflitos do que permitir que eles ocorram para depois detect-los? 2 - Se um protocolo evita deadlock, o enfraquecimento ainda possvel? Justifique. 3 Apresente um incio de escalonamento (schedule) 2PL Bsico que recaia em uma situao de impasse (deadlock). 4 Apresente um escalonamento (schedule) 2PL Bsico que no seja recupervel. 5 Apresente um incio de escalonamento (schedule) 2PL Estrito que recaia em uma situao de impasse (deadlock). 6 - Apresente exemplos de escalonamentos 2PL conservador, 2PL estrito e 2PL rigoroso para as seguintes transaes: T1: r(Y) w(Y) w(Z) T2: r(X) r(T) w(T) T3: r(Z) w(Z) T4: r(X) w(X) 7 - Demonstre que o protocolo de bloqueio em duas fases assegura a serializabilidade em conflito. 8 - Considere o seguinte conjunto de transaes T: T1 : r1(A) r1(B) if A = 0 then B := B + 1; w1(B) T2 : r2(B) r2(A) if B = 0 then A := A + 1; w2(A) Adicione instrues lock e unlock para as transaes T1 e T2 a fim de que eles observem o protocolo de bloqueio em duas fases. A execuo dessas transaes pode resultar em um impasse (deadlock)?
134
9 - Considere um sistema de banco de dados que inclua uma operao atmica increment em adio s operaes write e read. Digamos que V seja o valor do item X. A operao Increment(X) por C ajusta o valor de X para V + C em um passo atmico. O valor de X no est disponvel para a transao, a menos que ele execute um read(x). A Figura abaixo mostra uma matriz de compatibilidade de bloqueios para trs modos de bloqueios: partilhado, exclusivo e incrementado. S S S I S X I falso falso verdadeiro
verdadeiro falso falso falso falso falso
9.1. Mostre que, se todas as transaes bloqueiam dados que elas acessam no modo correspondente ao bloqueio de duas fases, a serializabilidade est assegurada. 9.2. Mostre que a incluso de bloqueios no modo incrementado permite aumentar a concorrncia. 10 - Explique o fenmeno fantasma. Por que este fenmeno leva execuo incorreta apesar do uso de um protocolo que assegura a serializabilidade? 11 - Prove que os protocolos wait-die e wound-wait evitam deadlock e enfraquecimento (livelock). 12 - Por que as operaes lock e unlock devem ser atmicas? 13 - Considere o seguinte schedule S (incompleto) : r1(x) r1(y) w1(x) r2(y) w3(y) w1(x) r2(y) 1) Assumindo que as trs transaes executam suas operaes de commit, mostre o grafo de serializao para o schedule S. 2) Para cada uma das opes baixo modifique o schedule S a fim de criar um novo schedule (completo) T tal que: T evita aborts em cascata e no recupervel. T recupervel. 135
T serializvel por conflito.
Para criar o schedule T voc pode adicionar novas operaes em qualquer posio do schedule S, mas no pode alterar a ordem das operaes j existentes. Caso no seja possvel criar o schedule T como se pede, comente brevemente. 14 - Como o protocolo 2V2PL consegue garantir um maior grau de concorrncia do que o protocolo 2PL. 15 - Em que situao o protocolo 2V2PL pode provocar que uma transao espere indefinidamente para terminar sua execuo? 16 - Mostre que o protocolo 2PL Preciso evita aborts em cascata. 17 - Demonstre que se dois schedules so equivalentes por conflito ento seus grafos de serializao so idnticos. Prove que o inverso no verdade. 18 - Prove ou refute a assertiva a seguir: O protocolo 2V2PL evita a formao de deadlocks. 19 - Verifique se o seguinte schedule pode ser produzido por um escalonador (scheduler) 2V2PL. Justifique sua resposta.
T1=r1(y)r1(x)w1(y)c1 T3=r3(y)r3(x)w3(u)w3(z)c3
T2= w2(u)r2(x)r2(y)w2(x)c2 T4=r4(v)w4(u)c4
S=r4(v)r3(y)r1(y)r1(x)w2(u)r2(x)w1(y)c1r2(y)r3(x)w2(x)c2w4(u)c4w3(u) w3(z)c3 20 - Considere o seguinte cenrio de execuo em um SGBD: T1=r1(y)w1(x) T3=r3(u)r3(v) S=r1(y)w2(u)r2(x) T2= w2(u)r2(x)w2(z)
r3(u)
w2(z)c2 w1(x) r3(v) c1 c3
Considere que o SGBD utilize o protocolo 2PL para controlar concorrncia. Suponha que a operao r3(u) chegou para ser escalonada aps o escalonamento de r2(x). Contudo, devido ao protocolo 2PL, a operao r3(u) teve que ser atrasada e 136
escalonada apenas aps a execuo da operao de commit da transao T2. a) O schedule S poderia ser produzido em um SGBD que utiliza a estratgia wound-wait para prevenir situaes de deadlocks. Justifique sua resposta. b) O schedule S poderia ser produzido em um SGBD que utiliza a estratgia wait-die para prevenir situaes de deadlocks. Justifique sua resposta. 21 - O nvel de isolamento repeatable read sofre do fenmeno de fantasma (phanton). Considere que o DBA de sua empresa definiu o nvel de isolamento repeatable read para todas as transaes. Construa um schedule onde esse fenmeno pode ocorrer no nvel de isolamento repeatable read. Justifique sua resposta.
22 - Uma variante do protocolo 2PL, denominada de 2PL esttico ou conservativo, definida da seguinte forma. Uma transao qualquer T s pode iniciar a execuo de suas operaes, aps terem sido obtidos todos os seus bloqueios. Isto exige que todas as operaes de leitura e de escrita a serem executadas por T devem ser pr-declaradas ao scheduler. Dessa forma, assim que o scheduler receber estas informaes (referentes a transao T), ele tentar obter todos os bloqueios que a transao T necessita, pois o scheduler sabe quais as operaes de leitura e de escrita que sero executadas por T. Esta variante caracteriza-se por evitar deadlocks. Justifique com suas palavras a veracidade desta assertiva.
23 - Identifique se o schedule S, definido sobre T ={T1,T2,T3}, abaixo livre de deadlock. Considere que as operaes das transaes devem ser escalonadas utilizando o protocolo 2PL preciso. Justifique sua resposta. T1=r1(y)r1(x)c1 T2= r2(v)w2(x)r2(z)c2 T3=r3(v)w3(z)w3(y)c3
S=r2(v)r1(y)w2(x)r3(v)r1(x)w3(z)r2(z)w3(y)c3c1c2 24 - Considere os seguintes grficos: 137
O grfico (a) refere-se execuo de transaes longas, onde se pode observar o comportamento do throughput (nmero de transaes executadas em um intervalo de tempo) em relao a uma variao da granularidade de bloqueios. Por sua vez, o grfico (b) representa a execuo de transaes de curta durao. Justifique os comportamentos representados pelas curvas nos grficos (a) e (b).
25 - Pode-se provar que a classe de schedules produzidos por um escalonador 2PL sobre um conjunto de transaes est contida no conjunto de todos os schedules serializaveis por conflito sobre . Formalmente, 2PL CSR. Construa um schedule serializavel por conflito S (S CSR), mas que no possa ter sido produzido por um escalonador que implemente o protocolo 2PL (S 2PL). 26 - Identifique se o seguinte schedule pode ser produzido no nvel de isolamento cursor stability. Justifique sua resposta.
SA= r2(y)r1(x)r1(v)w2(x)w3(y)r3(v)r3(u)w1(v)c3c1c2 27 - O nvel de isolamento read committed sofre do fenmeno da atualizao perdida (lost update). Considere que o DBA de 138
sua empresa definiu o nvel de isolamento read committed para todas as transaes. Construa um schedule onde esse fenmeno pode ocorrer no nvel de isolamento read committed, para mostrar que o DBA pode est sendo responsvel por inconsistncias noo banco de dados. Justifique sua resposta.
28 - Considere o seguinte cenrio de execuo em um SGBD: T1=r1(y)w1(x) T2= w2(u)r2(x)w2(z) T3=r3(u)r3(v)
Considere que o SGBD utilize o protocolo 2PL-preciso para controlar concorrncia. a) Elabore um Schedule S que possa ser produzido em um SGBD que utiliza a estratgia wound-wait para prevenir situaes de deadlocks. Justifique sua resposta. b) Elabore um Schedule S que no possa ser produzido em um SGBD que utiliza a estratgia wound-wait para prevenir situaes de deadlocks. Justifique sua resposta. c) Elabore um Schedule S que possa ser produzido em um SGBD que utiliza a estratgia wait-die para prevenir situaes de deadlocks. Justifique sua resposta. d) Elabore um Schedule S que no possa ser produzido em um SGBD que utiliza a estratgia wait-die para prevenir situaes de deadlocks. Justifique sua resposta. 29 - Considere o seguinte schedule S (incompleto): r1(x) r1(y) w1(x) r2(y) w3(y) w1(x) r2(y) a) Assumindo que as trs transaes executam suas operaes de commit, mostre o grafo de serializao para o schedule S. b) Para cada uma das opes abaixo modifique o schedule S a fim de criar um novo schedule (completo) T tal que: T evita aborts em cascata e no serializvel. T recupervel e no serializvel por conflito. T serializvel por conflito e no evita aborts em cascata.
Para criar o schedule T voc pode adicionar novas operaes em qualquer posio do schedule S, mas no pode alterar a ordem das operaes j existentes. Caso no seja possvel criar 139
o schedule T como se pede, comente brevemente.
30 - Considere a base de dados das Eleies de 2002, a qual descrita a seguir:
candidatos(nr_candidato:integer, nome: string, cargol: integer, partido: string) ce_voto_secao (cd_municipio: integer, nr_zona: integer, nr_secao: integer, cd_cargo: integer, nr_candidato: integer, qtd_votos: integer) PS. : Os campos siblinhados constituem a chave primria de cada relao. Considere ainda a existncia de dois procedimentos, os quais so mostrados a seguir:
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE BEGIN TRAN proc1 SELECT * FROM CANDIDATOS WHERE NR_CANDIDATO = 13 WAITFOR DELAY '000:02:00' UPDATE CANDIDATOS SET NR_CANDIDATO = 128 WHERE NR_CANDIDATO = 13 SET TRANSACTION ISOLATION LEVEL SERIALIZABLE BEGIN TRAN proc2 SELECT * FROM CANDIDATOS WHERE NR_CANDIDATO = 13 WAITFOR DELAY '000:02:00' UPDATE CANDIDATOS WITH (NOLOCK) SET NR_CANDIDATO = 127
140
Assuma que o procedimento proc1 foi executado inicialmente, e, logo em seguida foi executado o procedimento proc2.
Descreva e comente o schedule gerado pela execuo destes dois procedimentos. Dicas: 1. Observe que o comando TransactSQL WAITFOR DELAY '000:02:00' faz com que o procedimento pare sua execuo e espere por 2 minutos. Note que o comando SET TRANSACTION ISOLATION LEVEL seta (ajusta) o nvel de isolamento.
2.
31 - Verifique se o seguinte schedule pode ser produzido por um escalonador (scheduler) 2PL com mltipla granularidade. Justifique sua resposta. Considere que o banco de dados tem a seguinte estrutura:
S=r2(P3)r1(P1)w2(T1)w1(T2) c1 c2
141
32 - Prove ou refute a assertiva a seguir: Todo schedule recupervel evita a ocorrncia de aborts em cascata.
Considere a base de dados apresentada na questo anterior. Considere ainda a existncia de dois procedimentos, os quais so mostrados a seguir:
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED BEGIN TRAN proc1 SELECT * FROM CANDIDATOS WHERE NR_CANDIDATO = 13 WAITFOR DELAY '000:02:00' UPDATE CANDIDATOS SET NR_CANDIDATO = 128 WHERE NR_CANDIDATO = 13 SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED BEGIN TRAN proc2 SELECT * FROM CANDIDATOS WHERE NR_CANDIDATO = 13 WAITFOR DELAY '000:02:00' UPDATE CANDIDATOS SET NR_CANDIDATO = 127 WHERE NR_CANDIDATO = 13
Assuma que o procedimento proc1 foi executado inicialmente, e, logo em seguida foi executado o procedimento proc2.
Descreva e comente o schedule gerado pela execuo destes dois procedimentos.
142
33 - Para cada uma das opes abaixo crie um schedule que satisfaa as propriedades requisitadas: (a) (b) (c) (d) No recupervel e no serializvel. Serializvel e recupervel. Preciso e serializvel. No serializvel e que no evita aborts em cascata.
143
UNIDADE III PROTOCOLOS AGRESSIVOS
7. DESCRIO DOS PROTOCOLOS AGRESSIVOS
Protocolos de controle de concorrncia baseados em bloqueio utilizam uma abordagem conservadora para a resoluo de conflitos entre transaes. Eles assumem que na maioria das transaes ocorrero conflitos, por este motivo eles bloqueiam estas
transaes. Contudo em sistemas onde no h grande acesso de escrita a objetos, esta abordagem acaba sendo prejudicial. Neste contexto, novos protocolos, que no utilizam o conceito de bloqueio, comearam a ser estudados.
3.1. Protocolos Baseados em Marcadores de Tempo (Timestamps) No protocolo de ordenao por marca de tempo (timestamp), o gerenciador de transaes (GT) atribui um timestamp, ts(Ti), a cada transao Ti. Para quaisquer duas transaes Ti e Tj, com (i j), ts(Ti) ts(Tj). O gerenciador de transaes associa o timestamp da transao Ti a todas as operaes pi(x) Ti. Em geral, os valores dos timestamps representam a ordem em que as transaes so submetidas ao sistema. As estratgias mais usadas para gerar os valores dos timestamps baseiam-se na utilizao de nmeros seqenciais (1,2,3...) e da composio Data+Hora. Por convenincia iremos utilizar o termo timestamp de uma operao pi(x), embora este seja nada mais que o timestamp da transao Ti. Um escalonador, baseado na ordenao por timestamp, ordena as operaes em conflito de acordo com os seus timestamps, segundo a regra mostrada a seguir:
144
Regra: Se pi(x) e qj(x) so operaes em conflito, ento a operao pi(x) ser executada antes da operao qj(x) se e somente se ts(Ti) < ts(Tj).
O teorema a seguir mostra que se esta regra for seguida os escalonamentos (schedules) produzidos sero serializveis por conflito. Teorema: Se S um schedule que representa uma execuo concorrente produzida pela regra da ordenao por timestamp ento S serializvel por conflito. Prova: Seja GS(S) o grafo de serializao para o schedule S. Se Ti Tj uma aresta de GS(S), ento devem existir duas operaes pi(x) e qj(x), que esto em conflito em S, tais que pi(x) <s qj(x). Assim, pela regra da ordenao por timestamp, temos que ts(Ti) < ts(Tj). Vamos supor que existe um ciclo T1 T2 .... Tn T1, onde n>1, em GS(S). Usando induo, podemos concluir que ts(T1) < ts(T1), o que uma contradio. Logo, GS(S) acclico, e pelo teorema da serializabilidade, S serializvel por conflito. 3.1.1. Protocolo Bsico de Ordenao por Timestamp O protocolo bsico (Basic Timestamp Ordering, ou simplesmente Basic TO) uma implementao simples e agressiva da regra de ordenao por timestamp (Regra OT). Neste protocolo, o scheduler escalona as operaes de forma imediata, ou seja, na medida em que estas so recebidas do gerenciador de transaes (first-comefirst-served order). Para garantir que o schedule gerado no viole a regra OT, o escalonador rejeita as operaes que chegarem atrasadas. Isto feito reiniciando (abortando) a transao que submeteu a operao atrasada. Uma operao pi(x) dita atrasada se ao chegar ao escalonador este j tenha executado uma operao 145
qj(x), que conflita com pi(x), com ts(Tj) > ts(Ti)$. Neste caso, a operao pi(x) deve ser rejeitada, ou seja, a transao Ti deve ser reiniciada (abortada). Funcionamento O algoritmo associa a cada item de do x do banco de dados (BD) dois timestamps: Read_TS(x): Maior entre todos os timestamps de transaes que leram o item x, e Write_TS(x): Maior entre todos os timestamps de transaes que modificaram o item x. Quando uma transao Ti deseja ler ou escrever sobre o item x, o algoritmo compara o timestamp de Ti com o Read_TS(x) e Write_TS(x), conforme mostra o algoritmo a seguir:
Figura 3.1:Algoritmo do Protocolo de Ordenao por Timestamp.
Principais Caractersticas A ordem de execuo das transaes determinada pela ordem em que as transaes so iniciadas; O schedule produzido equivalente a algum schedule serial, o qual corresponde ordem dos timestamps;
146
As operaes conflitantes sempre so executadas na ordem dos timestamps de suas transaes; No utiliza bloqueios. Logo, est livre de problemas de deadlock; No evita aborts em cascata;
Exemplo 14 Considere o seguinte conjunto de transaes: T1 = r1(x) r1(y) w1(x) c1 T2 = r2(x) r2(y) c2
Considere agora a seguinte execuo (schedule): S1 = r1(x) r2(x) r1(y) w1(x) r2(y) c2 c1
Observe que o schedule S1, apesar de correto (pois se montarmos o grafo de serializao veremos que este no possui ciclo) no ser gerado pelo protocolo da ordenao por timestamp. Note que no momento em que a operao w1(x) chegar ao escalonador este ir verificar que j existe uma operao, anteriormente escalonada, que conflita com w1(x), mais
precisamente r2(x). Neste caso, o escalonador ir testar se Read_TS(x), que neste momento tem valor 2, maior que ts(T1), que estamos assumindo ter valor 1. Como o resultado deste teste ser verdadeiro a transao T1 ser cancelada (abortada), apesar do schedule S1 ser correto.
147
1.2. Teste do Grafo de Serializao
Seja S um schedule sobre um conjunto de transaes T={T1, T2, ... , Tn}. O grafo de serializao para S, representado por GS(S), definido como o grafo direcionado GS(S) = (N,A) no qual cada n em N corresponde a uma transao em T. O conjunto A contm as arestas na forma Ti Tj, se e somente se Ti, Tj N e existem duas operaes p OP(Ti), q OP(Tj), onde p conflita com q e p <S q. Um schedule global S serializvel por conflito se e somente se o grafo de serializao para S acclico. Um schedule S correto se ele for serial ou serializvel por conflito. O protocolo do teste do grafo de serializao baseia-se no monitoramento e gerenciamento do grafo de serializao. A idia bsica do protocolo consiste em manter um grafo de serializao sempre acclico, uma vez que se este grafo for acclico o schedule gerado serializvel por conflito. Vale destacar que existe um algoritmo para verificar se um grafo acclico em tempo polinomial. A seguir descrevemos um possvel algoritmo para implementar este protocolo:
Para cada nova transao Ti, Faa: Incluir um n no grafo de serializao; Fim Para; Garbage Collection Para cada operao pi(x) OP(Ti) recebida Faa: Se o n correspondente a uma transao terminada Ti s Verificar se existe uma operao qj(x) OP(Tj) que possui arestas saindo, ento o n pode ser removido do grafo conflite com pi(x) e que j tenha sido enviada para processamento; Porque?? Caso afirmativo incluir aresta Tj Ti; Se a nova aresta introduzir um ciclo no grafo ento: Abortar Ti; Retirar do grafo o n referente a Ti e todas as arestas que partem ou chegam neste n; Fim Se; Fim Para; 148
Figura 3.Z: Protocolo do Teste do Grafo de Serializao Figura 3.2:Algoritmo do Protocolo TGS. Contudo, razovel esperar que o grafo de serializao cresa substancialmente, uma vez que existe um n no grafo para cada transao. Assim, o tempo necessrio para verificar se o grafo acclico tende a aumentar. Com a finalidade de evitar este problema uma estratgia de coleta de lixo (Garbage Collection) pode ser utilizada: Se o n correspondente a uma transao terminada Ti s possui arestas saindo, ento o n pode ser removido do grafo. Isto se deve ao fato de que se uma transao concluiu sua execuo ento nenhuma nova aresta deve ser inserida no grafo de maneira a chegar no n referente a Ti, uma vez que Ti no executa nenhuma nova operao. Logo, este n jamais se envolver em um ciclo, podendo ser retirado do grafo.
Exemplo 15 Considere o seguinte conjunto de transaes: T1 = r1(x) r1(y) w1(x) c1 T2 = r2(x) r2(y) c2
Considere agora a seguinte execuo (schedule): S1 = r1(x) r2(x) r1(y) w1(x) r2(y) c2 c1
Observe que o schedule S1 ser gerado pelo protocolo TGS, uma vez que o grafo de serializao de S1 no possui ciclo (figura 3.3).
149
Figura 3.3: Grafo de Serializao do Schedule S1. Exemplo 16 Considere o seguinte conjunto de transaes: T1 = r1(x) w1(x) c1 T2 = r2(x) w2(x) c2
Considere agora a seguinte execuo (schedule): S2 = r1(x) r2(x) w1(x) w2(x) c1 c2 Observe que momento em que o escalonador receber a operao w1(x), ser inserido no grafo de serializao uma resta T2 T1. Contudo, a insero desta aresta no introduz um ciclo no grafo de serializao. Logo, a operao w1(x) ser escalonada. J no momento em que o escalonador receber a operao w2(x), ser inserido no grafo de serializao uma resta T1 T2. Como a insero desta nova aresta introduz um ciclo no grafo de serializao (figura 3.4), a operao w2(x) ser rejeitada e a transao T2 abortada. Logo, o schedule S2 (que incorreto) no ser gerado por um escalonador que utiliza o protocolo TGS.
Figura 3.4: Grafo de Serializao do Schedule S2. 150
1.3. Protocolos Otimistas Em todas as tcnicas de controle de concorrncia discutidas at aqui, sempre se faz alguma verificao antes que uma operao, de leitura, escrita ou commit, por exemplo, seja executada. Estas verificaes geram uma sobrecarga (overhead) durante a execuo das transaes, reduzindo assim a velocidade com as transaes so concludas. Os protocolos otimistas partem do pressuposto que a maioria das transaes no iro se envolver em conflitos. Assim, nas tcnicas de controle de concorrncia otimista nenhuma verificao realizada enquanto a transao estiver sendo executada. No momento em que a transao solicitar o seu commit que algum tipo de verificao realizado. Dentre as tcnicas otimistas destacam-se os protocolos baseados em certificadores e os protocolos baseados em validao. Um escalonar que utiliza um protocolo otimista baseado em certificadores funciona da seguinte forma: O escalonador, ao receber uma operao de leitura ou escrita envia imediatamente esta operao para processamento (execuo) e atualiza o escalonamento (schedule) que est sendo gerado. Quando uma transao Ti envia uma solicitao de commit o escalonador verifica se o escalonamento gerado at o presente momento, incluindo a operao ci, serializvel. Em caso afirmativo, o escalonador realiza o commit de Ti. Em caso negativo, o escalonador aborta a transao Ti e retira as operaes de Ti do escalonamento por ele gerenciado. A seguir, descrevemos um segundo protocolo otimista, denominado protocolo baseado em validao. Nestes protocolos, as transaes executam em trs fases: Leitura: Nesta fase a transao l os valores dos itens do banco de dados que necessita e guarda uma cpia 151
desses valores em uma rea local, chamada workspace ou cache; Validao: Nesta fase o SGBD verifica se a transao pode conflitar com alguma outra transao que est executando concorrentemente. Caso exista este risco, a transao abortada, sua cache local esvaziada e, em seguida, a transao reiniciada; e Escrita: Caso a transao passe pela fase de validao, as alteraes feitas nos valores armazenados em sua cpia (cache) local so persistidas no banco de dados. Neste protocolo, as atualizaes de uma determinada transao no so aplicadas diretamente aos itens do banco de dados at que a transao alcance o seu fim. Durante sua execuo, todas as atualizaes so aplicadas em cpias locais dos itens de dados (cache). Ao fim da execuo, uma fase de validao verifica se alguma das atualizaes violou a serializao. Se a serializao no for violada, a transao efetivada, e o banco de dados atualizado com as cpias locais. Caso contrrio, a transao abortada e, mais tarde, reiniciada. A idia do protocolo fazer todas as verificaes de uma s vez. Assim, a execuo de uma transao continua com um mnimo de sobrecarga at que a fase de validao seja alcanada. Importante observar que as abordagens otimistas somente resultaro em um melhor desempenho se houver poucos conflitos e a validao puder ser feita de maneira eficiente. Caso contrrio, o custo de reiniciar as transaes continuamente ser bastante elevado. Os protocolos que no so baseados em bloqueio: Apresentam um maior grau de concorrncia, pois tendem a permitir um nmero maior de entrelaamentos;
152
No sofrem do problema de deadlocks; Em geral, apresentam altas taxas de abort; No evitam aborts em cascata;
153
3.4. Exerccios
1 Mostre que existem schedules que so possveis sob o protocolo de bloqueio em duas fases, mas no so possveis sobre o protocolo baseado em marcador de tempo e vice-versa. 2 Identifique diferenas na utilizao de timestamps na preveno de deadlocks e no controle de concorrncia. 3 Prove ou refute a assertiva a seguir: Todo schedule gerado pelo protocolo de ordenao por timestamp (TO) pode ser gerado pelo protocolo do teste do grafo de serializao (TGS). 4 Prove ou refute. Todo schedule gerado pelo protocolo do TGS tambm pode ser gerado pelo protocolo de Ordenao por Marcador de Tempo (Timestamp). 5 Prove ou refute. Todo schedule gerado pelo protocolo do TGS tambm pode ser gerado pelo protocolo 2V2PL. 6 Identifique se o seguinte schedule pode ser produzido por um escalonador (scheduler) implementando o protocolo de marca de tempo. Justifique sua resposta.
SA= r1(y)r2(u)r2(x)w3(u)r3(v)c3w1(v)c2c1;
154
8. WEBLIOGRAFIA
Universidade Aberta do Piau UAPI www.ufpi.br/uapi
Universidade Aberta do Brasil UAB www.uab.gov.br
Secretaria de Educao Distncia do MEC - SEED www.seed.mec.gov.br
Associao Brasileira de Educao Distncia ABED www.abed.org.br
Uma Introduo Sucinta Teoria dos Grafos http://www.ime.usp.br/~pf/teoriadosgrafos/
Teoria dos Grafos http://www.inf.ufsc.br/grafos/
Algoritmos em grafos http://www.ime.usp.br/~pf/algoritmos_em_grafos/index.html
Applet Busca em Profundidade http://www.cs.mcgill.ca/~cs251/OldCourses/1997/topic26/#java
Applet Busca em Profundidade grafo direcionado com pilha http://www.cs.duke.edu/csed/jawaa/DFSnew.html
155
9. REFERNCIAS BIBLIOGRFICAS
Silberschatz, A., Korth, H., Sudarshan, S. Sistema de Banco de Dados. 5 Edio, Editora Campus, 2006.
Garcia-Molina,
H.,
Ullman,
Jeffrey
D.,
Widom,
Jennifer.
Implementao de Sistemas de Bancos de Dados. 1a. Edio, Editora Campus, 2001.
ONeil,
Patrick.,
ONeil,
Elizabeth.
Database:
Principles,
Programming and Performance. Second Edition, IE-ELSEVIER , 2001.
Elsmari, R., Navathe, Shamkant B. Sistemas de Banco de Dados. 4a. Edio, Addison-Wesley, 2005.
Ramakrishnan, R. Database Management Systems, 3 Edition, McGraw-Hill, 2002.
P. A. Bernstein, V. Hadzilacos, and N. Goodman. Concurrency Control and Recovery in Dabase Systems. Addison-Wesley, 1987.
A. Brayner. Transaction Management in Multidatabase Systems. Shaker Verlag, 1999.
M. A. Casanova. The Concurrency Problem of Database Systems. In Lectures Notes in Computer Science, 116, 1981.
156
K. P. Eswaran, J. Gray, R. A. Lorie, and I. L. Traiger. The Notions of Consistency and Predicate Locks in a Database System.
Communications of the ACM, 9 (11), 1976.
J. N. Gray. The Transaction Concept: Virtues and Limitations. In Proceedings of the 7th International Conference on VLDB, pages 144-154, 1981.
J. N. Gray, R. A. Lorie, G. R. Putzolu, and I. L. Traiger. Granularity of Locks and Degrees of Consistency in a Shared Database. In M. Stonebraker, editor, Readings in Database Systems, pages 94-121. Morgan-Kaufmann, 1988.
V. Hadzilacos. A Theory of Reliability in Database Systems. Journal of the ACM, 25:121-145, 1988.
T. Harder. Observations on Optimistic Concurrency Control Schemes. Informations Systems, 9(2):111-120, 1984.
C. H. Papadimitriou. The Theory of database Concurrency Control. Computer Science Press, 1986.
157
Recuperao de Banco de Dados
Esta unidade discute em detalhes a recuperao de banco de dados. So discutidos os diversos tipos de falhas, detalhando cada uma destas falhas. A estrutura de log apresentada e a recuperao baseada em log discutida. Noes de gerenciamento de buffer so apresentadas de e examinadas. de Tcnicas de so
recuperao,
incluindo
meio
armazenamentos,
apresentados, destacando suas vantagens e desvantagens. Por fim, tcnicas baseada em pginas sombras so discutidas.
158
SUMRIO
SUMRIO
UNIDADE IV RECUPERAO
1. RECUPERAO 1.1. Introduo................................................................... 00 1.2. Tipos de Falhas.......................................................... 00 1.3. Recuperao baseada em log................................... 00 1.4. Gerenciamento de Buffer............................................ 00 1.5. Checkpoints................................................................. 00 1.6. Tcnicas de Recuperao.................................... 00
1.7. Tcnica Recuperao de Meio de Armazenamento... 00 1.8. Recuperao baseada em Pginas Sombras ........... 00 1.9. Exerccios.................................................................... 00
4. WEBLIOGRAFIA ..................................................................... 00
159
UNIDADE IV RECUPERAO
4. RECUPERAO DE BANCO DE DADOS
4.1. Introduo Um sistema de computador, como qualquer outro dispositivo eltrico ou mecnico, est sujeito a falhas. Esta simples observao tem conseqncias de longo alcance para o projeto de sistemas de computadores em geral e de Sistemas Gerenciamento de Banco de Dados (SGBD) em particular. Uma parte essencial do SGBD o Sistema de Recuperao, responsvel pela deteco de falhas e pela restaurao do BD para um estado consistente que existia antes da ocorrncia da falha. O Sistema de Recuperao trata de duas propriedades das transaes: atomicidade e durabilidade. Para tanto, o SGBD deve ser tolerante a falhas, ou seja, ser capaz de conduzir o BD a um estado passado consistente, aps a ocorrncia de uma falha que o deixou em um estado inconsistente. O Sistema de Recuperao baseia-se em redundncia de dados. Entende-se por redundncia a criao de cpias dos dados e operaes ou a replicao destes dados. No caso de falha dos dados principais, podem-se utilizar as cpias para recuperar os dados e ento retornar o BD a um estado consistente. importante lembrar que a redundncia de dados no um mecanismo 100% seguro. Suponha que o SBGD est fazendo cpia 160
dos dados em um disco rgido externo e ocorre uma falha no disco principal. Neste caso, o SGBD vai tentar recuperar os dados do disco externo. Contudo, este disco tambm pode uma falha e assim, o SGBD no poder retornar a um estado consistente. O SGBD executa alguns procedimentos durante seu
funcionamento normal, como manter informaes sobre o que foi atualizado no BD pelas transaes e realizar cpias peridicas do BD. Quando ocorre uma falha, o SGBD deve executar aes para retornar o BD a um estado consistente. As duas aes bsicas so: UNDO: desfazer uma atualizao no BD. REDO: refazer uma atualizao no BD.
4.2. Tipos de Falhas Existem diferentes tipos de falhas que podem afetar a consistncia de um BD. A seguir detalhamos cada uma destas falhas. Falha de Transao A Falha de Transao ocorre quando uma transao ativa termina de forma anormal. As principais causas para este tipo de falha so: violao de uma restrio de integridade, lgica da transao mal definida, deadlock, cancelamento pelo usurio, entre outras. Este tipo de falha no compromete a memria principal nem a memria secundria (disco, em geral). Como as causas so muito comuns, essa falha tem maior probabilidade de ocorrncia. Entretanto, seu tempo de recuperao pequeno, pois no compromete as memrias principais e secundrias.
Falha de Sistema
161
A Falha de Sistema ocorre quando o SGBD encerra a sua execuo de forma anormal. As principais causas para este tipo de falha so: interrupo de energia, falha no sistema operacional erro interno no software do SGBD, falha de hardware, entre outras. Neste caso, as transaes em execuo no podem mais continuar, porm possvel recuper-las. Pode perguntar por que quedas de energia geram perda de estado de uma transao? A resposta simples: porque muitas vezes o contedo que estava na memria principal (memria voltil) no foi passado para o disco (memria estvel). Este tipo de falha compromete a memria principal mas no compromete a memria secundria. Como as causas so mais comuns do que a falha de transao, esse tipo de falha tem probabilidade mdia de ocorrncia. Entretanto, seu tempo de recuperao mdio, pois compromete a memria principal.
Falha de Meio de Armazenamento A Falha de Meio de Armazenamento ocorre quando o BD torna-se total ou parcialmente inacessvel. As principais causas para este tipo de falha esto relacionadas ao disco: setores corrompidos no disco, falha no cabeote de leitura/gravao, entre outras. Este tipo de falha no compromete a memria principal mas compromete a memria secundria. Como as causas no so comuns, essa falha tem menor probabilidade de ocorrncia. Entretanto, seu tempo de recuperao grande, pois compromete a memria secundria.
Falha Catastrfica Na falha de catastrfica esto vrias situaes em que a mdia que contm o BD completamente destruda. Os exemplos incluem
162
exploses ou incndios no local do banco de dados, vandalismo ou vrus. Em todos os casos, os princpios em que se baseia a recuperao so bastante simples e podem ser resumidos em uma nica palavra: redundncia. Isto , o meio de proteger o BD assegurar que qualquer informao nele existente possa ser reconstruda a partir de alguma outra informao armazenada redundantemente. Para evitar ou contornar essas falhas, os seguintes procedimentos so executados: (a) toda vez que feita uma modificao no BD, mantido automaticamente pelo sistema um registro num arquivo especial (b) periodicamente feito um backup de todo o BD (normalmente em fita magntica).
4.3. Recuperao Baseada em Log Registro de Log A estrutura largamente usada para registrar modificaes no banco de dados o log (ou Journal). Um log registra
seqencialmente as operaes feitas por transaes no banco de dados. Este arquivo geralmente consultado em caso de falhas para a realizao de UNDO e/ou REDO de transaes e mantido em uma ou mais cpias em memria secundria, tais como disco e fita.
Tipos de Log Existem alguns tipos de log e estes so usados para recuperao em diversas situaes, de acordo com o tipo de falha ou problema. Os principais tipos de log so: log UNDO: este log mantm apenas o valor antigo do dado (before image).
163
log REDO: este mantm apenas o valor atualizado do dado (after image). log UNDO/REDO: este o log mais comum e mantm os valores antigo e atualizado do dado.
Outros registros especiais de log existem para gravar eventos significativos durante o processamento de transaes, tais como o incio de uma transao e o compromisso ou aborto da transao. Para fins de recuperao de falhas, operaes leitura no precisam ser gravadas e so teis apenas para outros fins, tais como auditoria ou estatstica.
Representao do Log Para diferenciar as transaes, o SGBD atribui a uma destas um identificador nico. Os vrios tipos de registros de log so representados de acordo com a Figura 4.1.
Figura 4.1: Representao do log.
Identificao da transao: identificao nica da transao que executa a operao WRITE. Nome do item de dado: o nome nico do item de dado gravado. Valor antigo: o valor do item de dado anterior gravao. Novo valor: o valor que o item de dado ter depois da gravao. 164
Um exemplo de um log completo pode ser observado na Figura 4.2:
Figura 4.2: Representao do log.
Nesta Figura, a transao T3 inicia a transao e depois altera o item B do valor 15 para o valor 12. Em seguida, a transao T2 inicia e modifica o item B do valor 12 para o valor 18. A transao T1 inicia e modifica o item D do valor 20 para o valor 25. A transao T1 efetivada e o processo de preenchimento do log continua a a efetuao das transaes T2 e T3. importante observar que apenas as operaes de escrita so armazenadas no log. Outra forma de representar o log considerar a operao feita no BD: insert: <write Tx, X, INSERT, afterImage> update: <write Tx, X,UPDATE, beforeImage, afterImage> delete: <write Tx, X,DELETE, beforeImage>
OBS.: Como o log armazena informaes sobre todas as atividades do BD, o volume de dados armazenados no log pode tornar-se 165
excessivamente grande. Existem meios seguros para apagar informaes do log ou para compact-lo.
4.4. Gerenciamento de Buffer O buffer conjunto de blocos da memria principal. O uso do buffer surge da necessidade de evitar acessos freqentes ao meio fsico (LOG e BD). O SGBD responsvel pela gerncia de alguns buffers, tais como buffers para dados, para processamento de transaes e para o Log. Neste caso, o SGBD assume o controle desses buffers, ao invs do Sistema Operacional, requisitando apenas servios de leitura/escrita de blocos ao Sistema Operacional. A Figura 4.3 mostra um exemplo de buffers.
Figura 4.3: Exemplo de buffers.
Buffer do Log Este buffer agrupa um conjunto de registros de log. Estes registros podem ser enviados para o meio fsico, quando um bloco de registros equivalente ao tamanho de um bloco do arquivo de log for completado. 166
Os registros do log devem ser armazenados no arquivo na ordem em que eles foram criados. Por exemplo, antes que o registro <commit Ti> seja armazenado no arquivo, todos os outros registros desta transao j devem estar no arquivo. Uma transao s considerada efetivada quando todos os registros de log desta transao estiverem no meio fsico, ou seja, persistidas em memria secundria.
Buffer do Banco de Dados Este buffer guarda na memria principal alguns blocos do banco de dados fsico. Quando um dado do banco de dados precisa ser lido e o bloco fsico onde este dado est armazenado no est no buffer, ento este bloco recuperado do banco de dados fsico.
Tcnicas para o Gerenciamento de Buffer As tcnicas de recuperao devem sincronizar os buffers de log e de dados. Para tato, estas tcnicas utilizam o seguinte principio bsico: um bloco atualizado na cache s pode ser gravado no banco de dados aps o histrico dos dados atualizados neste bloco ter sido gravado no Log em disco. Este princpio chamado como Write-Ahead-Log (WAL). Neste caso, uma transao Tx s pode passar para o estado efetivada (committed) aps todas as suas atualizaes terem sido gravadas no banco de dados segundo o princpio WAL. O SGBD aplica tcnicas de gerenciamento de buffer estas tcnicas influenciam as tcnicas de recuperao. As principais tcnicas so:
NOT-STEAL
167
Nesta tcnica, um bloco na cache utilizado por uma transao Tx no pode ser gravado antes do commit de Tx. Este bloco possui um bit de status indicando se foi (1) ou no (0) modificado. Com isso, o processo de recuperao mais simples, pois evita dados de transaes inacabadas sendo gravadas no banco de dados.
STEAL Na tcnica STEAL, um bloco na cache utilizado por uma transao Tx pode ser gravado antes do commit de Tx. Assim, necessrio se algum dado requisitado do banco de dados por outra transao e no h blocos disponveis na cache. Ento um bloco a ser eliminado deve ser escolhido atravs de alguma tcnica, como o FIFO, ou seja, primeiro a entrar, primeiro a sair. A vantagem desta tcnica que no h necessidade de manter blocos bloqueados por transaes.
FORCE Com o FORCE, os blocos que mantm dados atualizados por uma transao Tx so imediatamente gravados no BD quando Tx alcana o commit. Para tanto, deve-se saber quais os blocos que Tx atualizou dados. A vantagem com isso garantia da durabilidade de Tx o mais cedo possvel, permitindo o REDO de Tx em caso de falha.
NOT-FORCE Com o NOT-FORCE, os blocos que mantm dados atualizados por Tx no so imediatamente gravados no BD quando Tx alcana o commit. Assim, blocos atualizados podem permanecer na cache e serem utilizados por outras transaes, aps o commit de Tx, o que reduz o custo de acesso a disco.
168
4.5. Checkpoint Na existncia de uma falha, o sistema de recuperao deve, a princpio, percorrer todo o log para saber quais transaes devem ser desfeitas. Contudo, este processo de percorrer o log consome muito tempo, visto que o log pode ser muito grande. Alm disso, muitas das transaes que necessitam ser refeitas j escreveram suas atualizaes no BD e refaz-las se tornar muito oneroso. Para resolver este problema, os SGBDs introduzem o conceito de checkpoints ou pontes de controle. Checkpoints so pontos em que se garante que o contedo dos buffers do log e do banco de dados foram descarregados nos respectivos meios fsicos. Os checkpoints so registros inseridos no log periodicamente e exigem a execuo da seqncia de operaes abaixo: 1. Suspender, temporariamente, a execuo de todas as transaes; 2. Descargar o buffer do log para o arquivo de log; 3. Descargar do buffer do BD para o BD fsico; 4. Gravar de um registro checkpoint no arquivo log; 5. Reassumir a execuo das transaes.
Quando ocorre uma falha de sistema, os seguintes passos devem ser executados: todas as transaes cujos registros <commit Ti> estejam depois do registro de Checkpoint mais recente gravado no log devem ser refeitas (REDO);
169
todas as transaes cujos registros de <start Ti> forem encontrados no log e os seus respectivos <commit Ti> no forem encontrados devem ser desfeitas (UNDO); a tcnica de checkpoints no interfere no processo de UNDO, somente no REDO. O ponto crtico em relao falha de sistema que os contedos da memria principal so perdidos (em particular, os buffers). No possvel prever o estado preciso de qualquer transao que estava em andamento no momento da falha. Tal transao pode nunca terminar com sucesso, logo precisa ser desfeita (rollback) quando o sistema reiniciar. Entretanto, pode tambm ser necessrio refazer algumas transaes que possam ter terminado com sucesso antes da falha ocorrer, mas que no tiveram seus resultados transferidos dos buffers para o banco de dados fsico.
Exemplo: Como o SGBD sabe, no momento do seu reinicio, quais transaes desfazer e quais transaes refazer?
Figura 4.4: Exemplo de Checkponit.
A Figura acima mostrar que ocorreu uma falha de sistema ocorre no tempo tf e o mais recente checkpoint ocorrido antes do tempo tf ocorreu no tempo tc.
170
Em relao s transaes, a transao T1 terminou antes do tempo tc, a transao T2 comeou antes do tempo tc e terminou depois do tempo tc, mas antes do tempo tf , a transao T3 tambm comeou antes do tempo tc, mas no terminou antes do tempo tf, a transao T4 comeou depois do tempo tc e terminou antes do tempo tf e a transao T5 tambm comeou depois do tempo tc, mas no terminaram antes do tempo tf. Deve ficar claro que, quando o sistema reiniciado, as transaes do tipo T3 e T5 devem ser desfeitas (UNDO), e as transaes do tipo T2 e T4 devem ser refeitas (REDO). Entretanto, as transaes T1, no entram no processo de recuperao, porque todos os seus resultados j foram escritos no banco de dados fsico no tempo tc.
4.6. Tcnicas de Recuperao Existem 2 tcnicas para usar o log com vistas a assegurar a atomicidade das transaes apesar das falhas. So elas: (a) Modificao Adiada do BD e (b) Modificao Imediata do BD.
Modificao Imediata Na modificao imediata, todos os dados que foram alterados por transaes efetivadas ou no, so persistidas no arquivo de dados. Por essa razo, algumas transaes precisam ser desfeitas (UNDO) e outras refeitas (REDO) no momento da recuperao. Com a necessidade do UNDO, alguns controles adicionais precisam ser adicionados ao arquivo de log. O SGBD precisa conhecer, alm dos valores alterados, os valores antes da modificao. A idia bsica que a atualizao feita no banco de dados no momento exato em que foi executada, ento, no procedimento de recuperao aps falha, tem que desfazer tudo e refazer.
171
As tcnicas baseadas em modificao imediata consistem em realizar modificaes no banco de dados antes do trmino das transaes, ou seja, permite que as modificaes no banco de dados sejam realizadas enquanto as transaes ainda esto em execuo. Neste sentido, as escritas realizadas por transaes ativas so denominadas de modificaes no efetivadas. Nesta abordagem, o log dever armazenar o valor antigo e o valor novo efetuados pelas aes de modificaes. Diante de uma falha, uma transao recuperada por meio da operaes UNDO, onde os valores antigos sero recuperados para o banco de dados. Se existir, no log, informao sobre o trmino da transao, ento a operao REDO ser executada para que todos os novos valores sejam refletidos no banco de dados. Durante o processo de recuperao pode haver um cenrio onde todos os dados j tenham sido escritos no banco de dados. Mas no haver inconsistncia, pois sero sobrescritos pelos mesmos valores. Esta caracterstica est ligada a propriedade de idempotncia de operaes UNDO e REDO, ou seja, fazer UNDO ou REDO uma vez ou vrias vezes produz o mesmo resultado. Do ponto de vista do Gerenciamento de Buffer, estas tcnicas utilizam a abordagem STEAL. Isso torna o Gerenciamento de buffer bem mais simples, pois na abordagem STEAL no h necessidade de manter blocos bloqueados por transaes, o que minimiza o esforo do gerenciador de buffer ao alocar e desalocar espaos de memria.
TCNICA UNDO/REDO Na tcnica UNDO/REDO gravada a efetivao de uma transao "x" no log depois que todas as modificaes, realizadas por "x", terem sido gravadas no log, e antes dessas modificaes terem sido gravadas no banco de dados. Para isso, esta tcnica requer a existncia de um log UNDO e REDO. 172
Esta abordagem utiliza duas listas, uma lista de REDO e uma lista de UNDO, que contm identificadores de transaes. A lista de REDO exibe os identificadores das transaes que efetivaram, ou seja, possuem indicativo de efetivao gravado no log. J a lista de UNDO ilustram os identificadores das transaes que estavam "ativas". O procedimento de recuperao dada, basicamente, por duas regras. A primeira regra consiste em fazer uma varredura no log do final para o comeo executando UNDO das transao contidas na lista de UNDO, ou seja, as transaes que efetivaram. J a segunda regra faz a varredura do comeo para o final do log realizando REDO das transaes inseridas na lista de REDO, ou seja, as transaes "ativas". Durante a aplicao da primeira regra possvel que, ao percorrer o log do comeo para o final afim de realizar REDO, um dado "x" tenha sido atualizado mais de um vez por transaes efetivadas. Neste caso, por medidas de otimizao, necessrio realizar, somente, o REDO da ltima atualizao do dado "x".
Exemplo: Neste exemplo vamos expor o comportamento da tcnica UNDO/REDO com checkpoint diante do processo de recuperao. Para isso, seguiremos um cenrio com contm cinco transaes dispostas em uma linha do tempo e o momento da falha. Maiores detalhes sobre este cenrio pode ser visualizado na Figura 1.
173
Figura 4.5: Tcnica Undo/Redo com o uso de checkpoint.
Podemos perceber que as transaes T1 e T2 iniciaram e terminaram antes da execuo do checkpoint. A transao T3 iniciou antes do checkpoint e no chegou em sua efetivao. J a transao T4 iniciou antes do checkpoint e efetivou antes da falha. A transao T5 iniciou aps o checkpoint e no consegui efetivar por completo. Seguindo as regras impostas pela tcnica em questo, as transaes T1 e T2 foram efetivadas antes do checkpoint. Portanto, essas transaes no precisam ser desfeitas e nem refeitas. Isso porque o checkpoint faz com que transaes efetivadas contenha suas atualizao persistidas no banco de dados. A transao T4 efetivou antes do momento da falha, mas suas atualizao no foram persistidas no banco de dados. Para este caso vamos supor que a tcnica utiliza a estratgia NOT-FORCE. Com isso necessrio, durante o processo de recuperao, que a transao T4 sobre a operao de REDO. J as transaes T3 e T5 no efetivaram nem antes do checkpoint e nem antes do momento da falha. Neste caso, essas transaes devem sofrer UNDO.
Algoritmo:
174
Procedimento para recuperar RM_Restart ( ) 1. Considere limpas as parties da cache 2. Faa refeito = { } e desfeito = { } 3. Comece com a ltima entrada do log e percorra o arquivo no sentido inverso (em direo ao incio). Repita os passos abaixo at que: (i) refeito U desfeito = Banco de Dados ou (ii) no existam mais entradas no log a) Se x no estiver na cache, leia x. b) Se Ti estiver na lista de transaes efetivadas: i) Atualize a partio de x com o valor ImDp. ii) refeito = refeito U { x } c) Caso contrrio, se: (i) Ti estiver na lista de transaes abortadas ou (ii) na lista de transaes ativas e no estiver na lista de transaes efetivadas: i) Atualize a partio de x com o valor ImAn. ii) desfeito = desfeito U { x } 4. Para cada Ti da lista de transaes efetivadas: a) Se Ti estiver na lista de transaes ativas, remova Ti desta lista. 5. Informe o final do processamento de restaurao ao escalonador
TCNICA UNDO/NO-REDO Na tcnica UNDO/NO-REDO gravada a efetivao de uma transao "x" no log depois que todas as modificaes, realizadas por "x", terem sido gravadas no log, e depois que essas modificaes terem sido gravadas no banco de dados. Neste caso, necessrio a existncia de um log UNDO. Nesta tcnica, se existir um registro de efetivao de uma transao "x" no log, ento "x" est garantidamente efetivada no 175
banco de dados. A principal vantagem desta abordagem que no h a necessidade de realizar REDO. Porm, pode-se fazer UNDO de uma transao que foi gravada com sucesso no banco de dados, mas sua efetivao no foi gravada a tempo no log. O procedimento de recuperao desta tcnica bem mais simples do que a tcnica UNDO/REDO. Nesta abordagem, necessrio realizar uma varredura do final para o comeo do log, executando UNDO das transaes existentes na lista de UNDO, ou seja, desfazendo os efeitos produzidos pelas transaes "ativas".
Exemplo: Para esse exemplo vamos supor um cenrio que existam cinco transaes em uma linha do tempo e momento em que ocorre a falha. Neste cenrio a tcnica UNDO/NO-REDO ser demonstrada sem o uso de checkpoint. Maiores detalhes sobre a disposio das transaes na linha do tempo e o momento da falha pode ser vista da Figura 2.
Figura 4.6: Tcnica Undo/No-Redo sem o uso de checkpoint.
Podemos observar que as transaes T1 e T2 foram efetivadas antes do momento da falha. As transaes T3 e T5 no conseguiram efetivar antes da falha. J a transao T4 efetivou bem 176
prximo do momento da falha. A disposio de T4 na linha do tempo, neste cenrio, nos permite observar uma caracterstica desta tcnica. As transaes T1 e T2 efetivaram antes do momento da falha e possuem suas efetivaes em log. Neste sentido, essas duas transaes no necessitam sofrer REDO durante a recuperao. J as transaes T3 e T5 no chegaram a efetivar por completo. Com isso, devem passar por uma operao de UNDO para que suas modificaes sejam desfeitas. Por ltimo, a transao T4 conseguiu terminar antes do momento da falha. Porm, este momento de efetivao foi bem prximo do momento da falha e, infelizmente, seu registro de efetivao no se encontra no log. Portanto, assim como T3 e T5, a transao T4 precisa passar pela operao de UNDO durante o processo de recuperao aps falha.
Algoritmo: Procedimento para recuperar RM_Restart ( ) 1. Considere limpas as parties da cache 2. Faa desfeito = { } 3. Comece com a ltima entrada do log e percorra o arquivo no sentido inverso (em direo ao incio). Repita os passos abaixo at que: (i) desfeito = Banco de Dados ou (ii) no existam mais entradas no log para examinar. Para cada [ Ti , x , ImAn, ImDp ], faa: a) Se Ti no estiver na lista de transaes efetivadas e x no estiver em desfeito: i) Selecione uma partio da cache para x ii) Atualize a partio de x com o valor ImAn. 177
iii) desfeito = desfeito U { x } 4. Para cada Ti da lista de transaes efetivadas: a) Se Ti estiver na lista de transaes ativas, remova Ti desta lista 5. Informe o final do processamento de restaurao ao escalonador
Modificao Adiada A modificao adiada e a imediata diferem entre si pela estratgia utilizada durante o checkpoint e, por conseqncia, em como esses dados so restaurados no caso de falha. Nessa estratgia, o checkpoint s grava no arquivo de dados as transaes que esto marcadas como efetivadas na memria principal. As operaes de outras transaes so somente feitas no buffer de banco de dados e registradas no arquivo de log. Assim sendo, transaes no efetivadas tm suas operaes ignoradas no momento da recuperao (veja isso como um rollback do sistema), enquanto as transaes que foram efetivadas devem ser refeitas e persistidas no arquivo de dados. O procedimento bsico adiar a execuo de qualquer atualizao sobre o banco de dados at que a transao seja concluda com sucesso e atinja o seu ponto de efetivao. Durante a execuo de uma transao, as operaes so apenas registradas no log e na rea de trabalho da transao. Depois que a transao atinge seu ponto de efetivao e o log escrito em disco, as atualizaes so registradas no banco de dados. As tcnicas baseadas em modificao adiada no log realizam alteraes no banco de dados somente quando todas as transaes, que modificam o banco de dados, so escritas no log. Neste sentido, quando uma transao parcialmente efetivada, as informaes no log associadas quela transao so usadas para executar as escritas adiadas. Com isso, se uma transao for efetivada com sucesso, ento existe um registro no log correspondente a essa 178
transao. Quando todas as modificaes do banco de dados so escritas no log, garante-se a propriedade de atomicidade de transao. A idia desta tcnica que modificaes adiadas, ou melhor, postergadas, adia-se a execuo de todas as operaes de modificao do banco de dados por uma transao at que ela tenha seja parcialmente efetivada, ou seja, tenha executado todas suas aes. Diante de uma falha, uma transao s ser recuperada por meio da operao REDO (refazer), se contiver um registro no log que sinalize o fim da mesma. Nesta abordagem no existe a operao UNDO (desfazer), pois o banco de dados s ficar em um estado inconsistente se o sistema cair durante a recuperao. Caso aconteca uma falha durante o processo de recuperao, a operao REDO deve ser executada novamente. Do ponto de vista do Gerenciamento de Buffer, estas tcnicas utilizam a abordagem NOT-STEAL. Isso torna o Gerenciamento de buffer mais complexo, pois a abordagem NOT-STEAL faz com que os blocos atualizados por uma transao "x" no sejam substitudos enquanto "x" no efetivar. Porm, o processo de recuperao aps falha bem mais simples pois as transaes no precisam realizar UNDO.
Tcnica NO-UNDO/REDO Na tcnica NO-UNDO/REDO fora-se a gravao do log em disco aps uma transao "x" concluir suas modificaes. Com isso, se uma transao "x" falhar antes de alcanar sua efetivao, no necessrio realizar UNDO de "x", pois nenhuma atualizao de "x" foi gravada no banco de dados. Nesta tcnica o processo de recuperao ocorre por meio de uma varredura do comeo do log at o final, realizando REDO nas transao contidas na lista de REDO. Como a gravao do log, em 179
disco, feita aps a efetivao das transaes, o REDO acontece somente nas transao que foram efetivadas. Caso, durante a falha, hajam transaes "ativas", ou seja, transaes que alcanaram a efetivao, estas devem ser recomeadas. Este tipo de tcnica limita a execuo concorrente das transaes porque itens de dados ficam bloqueadas at a efetivao das transaes. Conseqentemente, uma transao no grava as modificaes no BD at sua efetivao. Logo, uma transao nunca desfeita por causa da ocorrncia de falhas. Uma outra caracterstica importante que uma transao nunca vai ler o valor de um item gravado por outra no acabada, porque os itens esto bloqueados. Portanto, no ocorrer UNDO em cascata de transaes.
Exemplo: Neste primeiro exemplo, vamos mostrar um cenrio da tcnica NO-UNDO/REDO sem o uso de checkpoint. Para isso, colocamos em nosso exemplo cinco transaes descritas na linha do tempo e o momento em que ocorre a falha. Maiores detalhes sobre este cenrio pode ser visto na Figura 3.
Figura 4.7: Tnica No-Undo/Redo sem o uso de checkpoint.
180
Podemos perceber que as transaes T1, T2 e T4 efetivaram antes do momento da falha. Neste sentido, essas transaes esto inseridas na lista de REDO. Para esse exemplo vamos supor que as transaes T1 e T2 concluram e atualizaram o banco de dados. J a transao T4 concluiu mas no persistiu suas modificaes no banco de dados. Seguindo as regras da tcnica aqui descrita, as transaes T1 e T2 concluram e atualizaram o banco de dados. Portanto, estas precisam sofrer operaes de REDO no processo de recuperao. J a transao T4 concluiu, mas no chegou a atualizar o banco de dados. Com isso, assim como T1 e T2, a transao T4 deve sofrer operao de REDO durante a recuperao. Analisando, na linha do tempo, as transaes T3 e T5 percebe-se que estas no chegaram em suas efetivao. Portanto, estas no atualizaram, de forma persistente, o banco de dados e no sofrem UNDO. Com isso, as transaes T3 e T5 devem ser resubmetidas pelos usurios ou aplicaes.
Exemplo: Vamos ver um cenrio em que a tcnica NO-UNDO/REDO ser combinada com o uso do recurso de checkpoint. Para isso, disponibilizamos em nosso exemplo cinco transaes descritas na linha do tempo e o momento em que ocorre o checkpoint e a falha. A Figura 4 exibe o cenrio que queremos discutir.
181
Figura 4.8: Tnica No-Undo/Redo com o uso de checkpoint.
Neste exemplo mostrado que as transaes T1 e T2 efetivaram antes da aplicao do checkpoint. J a transao T4 concluiu aps o checkpoint e antes da falha. Enquanto as transaes T3 e T5 no concluram durante a linha do tempo mostrada neste cenrio. Como visto as transaes T1 e T2 efetivaram antes do checkpoint. Com isso, estas duas transaes no sofrem operao de REDO porque o checkpoint garantiu seus efeitos no banco de dados. A transao T4 iniciou antes do checkpoint mas terminou antes da falha. Neste caso, a transao T4 dever sofrer REDO assim como na tcnica sem o uso do checkpoint. Com relao as transaes T3 e T4, assim como na tcnica sem o uso de checkpoint, devem ser re-submetidas pelos usurios ou aplicaes.
Algoritmo: Procedimento para recuperar RM_Restart ( ) 1. Considere limpas as parties da cache 182
2. Faa desfeito = { } 3. Comece com a ltima entrada do log e percorra o arquivo no sentido inverso (em direo ao incio). Repita os passos abaixo at que: (i) desfeito = Banco de Dados ou (ii) no existam mais entradas no log para examinar. Para cada [ Ti , x , ImAn, ImDp ], faa: a) Se Ti no estiver na lista de transaes efetivadas e x no estiver em desfeito: i) Selecione uma partio da cache para x ii) Atualize a partio de x com o valor ImAn. iii) desfeito = desfeito U { x } 4. Para cada Ti da lista de transaes efetivadas: a) Se Ti estiver na lista de transaes ativas, remova Ti desta lista 5. Informe o final do processamento de restaurao ao escalonador.
4.7. Tcnicas de Recuperao de Meio de Armazenamento Esta tcnica utilizada quando ocorre falha do meio de armazenamento. Neste caso, necessita-se de uma cpia do BD atualizada periodicamente. Os seguintes passos so necessrios para a operao de cpia peridica do BD: 1. Concluso de todas as transaes ativas: nenhuma transao pode estar ativa e se existem transaes nesse estado, devese aguardar at elas encerrarem com sucesso. 2. Descarga do buffer do log para o disco; 3. Descarga do buffer do BD para o BD fsico.
No caso de falha, os passos para o procedimento de recuperao so: 183
1. restaurar o BD a partir da ltima cpia; 2. percorrer o arquivo de LOG, realizando o REDO de todas as transaes concludas desde a ltima cpia.
As transaes ativas no momento da falha podem ser resubmetidas execuo pelo SGBD j que no houve perda de dados na memria principal. Quando ocorre a operao de backup, o log corrente descartado (excludo ou mantido associado ao backup anterior do BD) e um novo log, neste caso zerado, iniciado. A Figura 4.8 mostra um exemplo da tcnica de recuperao de meio armazenamento. Nesta Figura, as transaes T1 , T2 e T3 so iniciada e ento, quando nenhuma destas transaes est ativa, ocorre a operao de archive ou backup, ou seja, armazenamento de todas as operaes referentes as transaes. Em seguida, as transaes T4, T5 e T6 so iniciadas e a ocorre uma falha do BD quando a transao ainda est ativa. Neste caso, realizada a operao de recuperao do banco de dados. Como as transaes T1, T2 e T3 j foram armazenadas, no necessrio desfaz-las ou refaz-las. J as transaes T4 e T6, que no estavam no backup, so refeitas. Para a transao T5, esta precisa ser desfeita, para manter a consistncia do banco de dados.
184
Figura 4.8: Exemplo da tcnica de recuperao de meio de armazenamento.
Vale a pena ressaltar as tcnicas baseadas em log requerem um log seguro, isto , redundncia de log, pois o meio de armazenamento onde este salvo pode sofrer falhas. Normalmente os SGBDs provem utilitrios que realizam estas tarefas.
4.8. Recuperao baseada em Pginas Sombras Na tcnica de recuperao baseada em pginas sombras, o BD constitudo de pginas. Existe uma Tabela de Pginas Correntes (TPC) e uma Tabela de Pginas Sombras (TPS), ambas em memria principal.
Princpio de Funcionamento 1. Quando uma transao Ti inicia a execuo, a TPC copiada para TPS, sendo est salva em disco; 2. Durante a execuo, a TPS no muda;
185
3. Quando uma operao de escrita ocorre em uma pgina, uma nova cpia da pgina modificada criada e apontada pela TPC; 4. Para a recuperao de uma falha, ocorre a liberao das pginas modificadas e o descarte das TPC. Assim, a TPS disponibilizar o estado anterior falha. 5. Com a confirmao da transao Ti, ento a TPS descartada.
A Figura 4.9 mostra um exemplo do uso de pginas sombras. No incio da tanto a TPC como a TPS apontam para as mesmas pginas. Com a alterao dos valores dos itens contidos nas pginas, a TPC aponta para novas pginas. Em caso de falha, as TPS passam a ser definidas com TPC, garantindo a consistncia das operaes, j que foi possvel retornar ao estado anterior.
Figura 4.9: Tcnica de recuperao de baseada em pginas sombras.
As vantagens da tcnica de recuperao de pginas sombras que est no necessita realizar as operaes de UNDO nem REDO. Contudo, est tcnica apresenta muitas desvantagens, a saber: (a) gerenciamento complexo dos dados, j que ocorre mudanas constantes nas pginas no disco (b) requer coleta de 186
lixo, pois quando uma transao encerra, existem pginas obsoletas (c) no suporta SGBD multiusurios, visto que apenas uma transao executada por vez. Por esses motivos, est tcnica no utilizada em SGBD atuais.
187
4.9. Exerccios 1. Quais so os objetivos do sistema de recuperao de um SGBD? 2. Quais so as duas aes bsicas realizadas quando ocorre uma falha em um banco de dados? 3. Qual o funo do buffer de banco de dados? 4. Discuta os diferentes tipos de falhas de transao. 5. Por que necessrio usar um arquivo de log? 6. Quais so os tipos de entradas em um log do sistema? 7. O que so checkpoints e por que eles so importantes? 8. Que tipos de tcnicas de recuperao de falhas no requerem o rollback? 9. Em quais tcnicas de recuperao de falhas so necessrias operaes de UNDO e REDO? Explique. 10. Qual a principal vantagem das tcnicas de atualizao adiada? Por que so chamadas de mtodo NO-UNDO/REDO? 11. Quais as vantagens e desvantagens das tcnicas de atualizao imediata? 12. Descreve as tcnicas de recuperao de meio de
armazenamento. 13. Explique o funcionamento da tcnica de pginas sombras.
14. (QUESTO DESAFIO) Na exemplo da Figura 4.8, suponha que a operao de checkpoint correu antes do final da transao T2. Assim sendo, quais operaes devem sofrer REDO. Justifique.
188
UNIDADE IV RECUPERAO DE BANCO DE DADOS
1. REFERNCIAS BIBLIOGRFICAS
Silberschatz, A., Korth, H., Sudarshan, S. Sistema de Banco de Dados. 5 Edio, Editora Campus, 2006.
Garcia-Molina,
H.,
Ullman,
Jeffrey
D.,
Widom,
Jennifer.
Implementao de Sistemas de Bancos de Dados. 1a. Edio, Editora Campus, 2001.
ONeil,
Patrick.,
ONeil,
Elizabeth.
Database:
Principles,
Programming and Performance. Second Edition, IE-ELSEVIER , 2001.
Elsmari, R., Navathe, Shamkant B. Sistemas de Banco de Dados. 4a. Edio, Addison-Wesley, 2005.
Ramakrishnan, R. Database Management Systems, 3 Edition, McGraw-Hill, 2002.
P. A. Bernstein, V. Hadzilacos, and N. Goodman. Concurrency Control and Recovery in Dabase Systems. Addison-Wesley, 1987.
A. Brayner. Transaction Management in Multidatabase Systems. Shaker Verlag, 1999.
M. A. Casanova. The Concurrency Problem of Database Systems. In 189
Lectures Notes in Computer Science, 116, 1981.
K. P. Eswaran, J. Gray, R. A. Lorie, and I. L. Traiger. The Notions of Consistency and Predicate Locks in a Database System.
Communications of the ACM, 9 (11), 1976.
J. N. Gray. The Transaction Concept: Virtues and Limitations. In Proceedings of the 7th International Conference on VLDB, pages 144-154, 1981.
J. N. Gray, R. A. Lorie, G. R. Putzolu, and I. L. Traiger. Granularity of Locks and Degrees of Consistency in a Shared Database. In M. Stonebraker, editor, Readings in Database Systems, pages 94-121. Morgan-Kaufmann, 1988.
V. Hadzilacos. A Theory of Reliability in Database Systems. Journal of the ACM, 25:121-145, 1988.
T. Harder. Observations on Optimistic Concurrency Control Schemes. Informations Systems, 9(2):111-120, 1984.
C. H. Papadimitriou. The Theory of database Concurrency Control. Computer Science Press, 1986.
190
Autores
Flvio Rubens de Carvalho Sousa

CV. http://lattes.cnpq.br/ 0771942436828005
Mestre em Cincia da Computao pela Universidade Federal do Cear UFC, Fortaleza-CE Brasil (2007). Graduado em Cincia da Computao pela Universidade Federal do Piau UFPI, Teresina-PI Brasil (2004). Atualmente Professor Assistente da UFC em Quixad e doutorando do Programa de Mestrado e Doutorado em Cincia da Computao da UFC. Atua principalmente nos seguintes temas: Gerenciamento de Dados Distribudos, Cloud Computing, XML.
191

Livro Banco de Dados

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Livro Banco de Dados

Uploaded by

Copyright:

Available Formats

Projeto Fsico de Banco de Dados

UNIDADE I PROJETO FSICO DE BANCOS DE DADOS

6. REFERNCIAS BIBLIOGRFICAS ........................................ 65

UNIDADE I PROJETO FSICO DE BANCOS DE DADOS

Figura 1.1: Possvel Arquitetura de um SGBD

Compilador DML Analisa sintaticamente e semanticamente os comandos DML

Gerenciador de Transaes Responsvel pelo controle de concorrncia e pela

armazenados (stored procedures) e gatilhos (triggers).

entre clientes e servidor em ambientes de computao mvel.

1.4. Exerccios 1. Descreva os componentes funcionais de um SGBD.

UNIDADE I PROJETO FSICO DE BANCOS DE DADOS

de armazenamento formam uma hierarquia de armazenamento que inclui as seguintes categorias:

Memria Interna do Processador Compreende pequeno conjunto de registradores de alta

Figura 2.1. Hierarquia de Meios de Armazenamento

2.1.1. Caractersticas dos Meios Fsicos de Armazenamento Custo

armazenamento definido por:

capacidade de permitir a alterao do contedo de

armazenamento apresentam a seguinte caracterstica: Um 1 armazenado torna-se um 0 devido a algum 15

(implementada atravs de replicao).

UNIDADE I PROJETO FSICO DE BANCOS DE DADOS

TA2 = TB + TA1 Assim, substituindo (2) em (1), temos:

UNIDADE II PROCESSAMENTO DE TRANSAES

UNIDADE II PROCESSAMENTO DE TRANSAES

Figura 1. Mudana de estados do BD

Display (Valor1, Valor2) inconsistente retrieval

Figura2. Transies Incorretas

Figura 3. Cdigo de uma transao

1.3 Estados de uma transao

UNIDADE II PROCESSAMENTO DE TRANSAES

Figura 4. Lost update

ciclos da CPU, o tempo mdio de resposta ser reduzido.

Figura 5. Entrelaamento de operaes.

Problemas de um escalonamento no-serial mal definido (invlido): atualizao perdida (lost-update)

Uma transao Ty grava em um dado atualizado por uma transao Tx

leitura suja (dirty-read)

TX atualiza um dado X, outras transaes posteriormente lem X, e depois TX falha

UNIDADE II PROCESSAMENTO DE TRANSAES

Figura 6. execuo serial de transaes

Figura 7. Execuo serial e execuo no-serial de schedules.

conceito de estados inicial e final.

operaes de leitura e escrita.

Operaes em conflito (conflitantes) Operaes de transaes distintas 66

Operaes em conflito do Schedule S

Operaes em conflito do Schedule S

r1(x) <S w2(x) w1(y) <S r2(y)

r1(x) <S w2(x) w1(y) <S r2(y)

verificamos que os dois schedules so equivalentes em conflito.

Operaes em conflito do Schedule S

Operaes em conflito do Schedule SS

T3=r3(y)r3(x)w3(u)w3(z) T4= r4(v)w4(u)

UNIDADE II PROCESSAMENTO DE TRANSAES

T2= r2(u)r2(x)w2(y, x+3)c2

S1= r2(u)w1(x,2)r2(x)r1(z)w2(y, x+3)c1c2

Confiveis 4.5 Exerccios:

UNIDADE III CONTROLE DE CONCORRNCIA

5. REFERNCIAS BIBLIOGRFICAS ........................................ 00

UNIDADE III INTRODUO AO CONTROLE DE CONCORRNCIA

1.1. Conceitos Iniciais Os modelos de processamento de transaes so

UNIDADE III PROTOCOLOS CONSERVADORES

6. DESCRIO DOS PROTOCOLOS CONSERVADORES

Figura 2.2. Grafo de Serializao do Schedule S1.

Bloqueio Compartilhado e Exclusivo O protocolo de bloqueio bsico pode ser melhorado

A figura 2.4 ilustra o grafo de serializao para o schedule S1.