Bancos de Dados - UNIVERSIDADE ABERTA

Universidade Federal do Piau
Centro de Educao Aberta e a Distncia
Construo de Sistemas de
Gerenciamento de
Banco de Dados
Flvio Rubens de Carvalho Sousa

Jos Maria da Silva Monteiro Filho
Ministrio da Educao - MEC
Universidade Aberta do Brasil - UAB
Universidade Federal do Piau - UFPI
Universidade Aberta do Piau - UAPI
Centro de Educao Aberta e a Distncia - CEAD
Construo de Sistemas de
Gerenciamento de
Banco de Dados

PRESIDENTE DA REPBLICA Dilma Vana Rousseff Linhares
MINISTRO DA EDUCAO Aloizio Mercadante
GOVERNADOR DO ESTADO Wilson Nunes Martins
REITOR DA UNIVERSIDADE FEDERAL DO PIAU Jos Arimatia Dantas Lopes
PRESIDENTE DA CAPES Jorge Almeida Guimares
COORDENADOR GERAL DA UNIVERSIDADE ABERTA DO BRASIL Joo Carlos Teatini de S. Clmaco
DIRETOR DO CENTRO DE EDUCAO ABERTA E A DISTNCIA DA UFPI Gildsio Guedes Fernandes
COORDENADORES DE CURSOS
ADMINISTRAO Antonella Maria das Chagas Sousa
ADMINISTRAO PBLICA Fabiana Rodrigues de Almeida Castro
CINCIAS BIOLGICAS Maria da Conceio Prado de Oliveira
FILOSOFIA Zoraida Maria Lopes Feitosa
FSICA Miguel Arcanjo Costa
LETRAS PORTUGUS Jos Vanderlei Carneiro
LETRAS INGLS Lvia Fernanda Nery da Silva
MATEMTICA Jos Ribamar Lopes Batista
PEDAGOGIA Vera Lcia Costa Oliveira
QUMICA Milton Batista da Silva
SISTEMAS DE INFORMAO Leonardo Ramon Nunes de Sousa
EQUIPE DE DESENVOLVIMENTO CONSELHO EDITORIAL DA EDUFPI

TCNICOS EM ASSUNTOS EDUCACIONAIS Djane Oliveira de Brito Prof. Dr. Ricardo Alaggio Ribeiro (Presidente)
Ubirajara Santana Assuno Des. Tomaz Gomes Campelo
Zilda Vieira Chaves Prof. Dr. Jos Renato de Arajo Sousa
EDIO Roberto Denes Quaresma Rgo Prof. Dr. Teresinha de Jesus Mesquita Queiroz
PROJETO GRFICO Samuel Falco Silva Prof. Francisca Maria Soares Mendes
DIAGRAMAO Antonio F. de Carvalho Filho Prof. Iracildes Maria de Moura F Lima
REVISO ORTOGRFICA Georgea Vale de Queiroz Siqueira Prof. Dr. Joo Renr Ferreira de Carvalho
REVISO GRFICA Georgea Vale de Queiroz Siqueira
S725c Sousa, Flvio Rubens de Carvalho.

Construo de sistemas de gerenciamento de banco de dados /
Flvio Rubens de Carvalho Sousa, Jos Maria da Silva Monteiro Filho. -
Teresina: EDUFPI/CEAD, 2013.
162 p.
ISBN:
1. Banco de Dados - Gerncia. 2. Armazenamento de Dados.

3. Recuperao de Banco de Dados. 4. Educao a Distncia. I. Monteiro Filho,
Jos Maria da Silva. II. Ttulo.
CDD: 005.74
2013. Universidade Federal do Piau - UFPI. Todos os direitos reservados.
A responsabilidade pelo texto e imagens desta obra do autor. O contedo desta obra foi licenciado, temporria e
gratuitamente, para utilizao no mbito do Sistema Universidade Aberta do Brasil, atravs da UFPI. O leitor se compromete
a utilizar o contedo desta obra para aprendizado pessoal, sendo que a reproduo e distribuio ficaro limitadas ao mbito
interno dos cursos. A citao desta obra em trabalhos acadmicos e/ou profissionais poder ser feita, com indicao da fonte.
A cpia desta obra sem autorizao expressa, ou com intuito de lucro, constitui crime contra a propriedade intelectual, com
sanes previstas no Cdigo Penal.
proibida a venda deste material.
Um Sistema de Gerenciamento de Banco de Dados, ou SGBD, um
software projetado para auxiliar o armazenamento, a recuperao e a utilizao
de vastos conjuntos de dados. O gerenciamento dessas informaes envolve
definir as estruturas que sero utilizadas para o armazenamento dos dados e
os mecanismos que sero responsveis pela manipulao desses dados. Como
as informaes precisam ser compartilhadas entre vrios usurios, o SGBD
necessita evitar possveis resultados anmalos. Alm disso, o SGBD necessita
garantir a segurana das informaes armazenadas, apesar das falhas que por
ventura possam ocorrer, ou das tentativas de acesso no autorizado.
Os SGBDs so, atualmente, ferramenta indispensvel para o
armazenamento e o gerenciamento de informaes. A disciplina que aborda
as tcnicas, os algoritmos e a teoria utilizada na construo de sistemas de
gerenciamento de banco de dados tornou-se parte integrante do currculo dos
cursos de Sistemas de Informao, Cincia da Computao e Engenharia da
Computao.
O objetivo deste livro proporcionar ao leitor entendimento da Construo
de Sistemas de Gerenciamento de Banco de Dados. O texto foi escrito de forma
simples e objetiva. Cada captulo acompanhado de embasamento terico
e prtico, bem como de implementaes e de exerccios. A bibliografia e a
webliografia ao fim das notas so mais do que suficientes para que o leitor se
aprofunde na teoria apresentada em cada unidade. Assim, esperamos prover ao
leitor um sentido de investigao nesta disciplina rica e vibrante.
Na Unidade I so discutidos os principais aspectos relacionados ao

projeto fsico de sistemas de bancos de dados, envolvendo principalmente o
armazenamento de dados, o gerenciamento de buffer e a indexao de dados.
Na Unidade II apresentado o problema do processamento de
transaes em bancos de dados e a teoria relacionada a esta importante questo.
Na Unidade III se discute o problema do controle de concorrncia em

bancos de dados e as principais tcnicas utilizadas para solucion-lo.
Por fim, na Unidade IV so apresentados conceitos sobre a recuperao

de banco de dados, destacando as principais tcnicas utilizadas.
Introduo
Atualmente, os Sistemas de Gerenciamento de Bancos de

Dados (SGBDs) desempenham um papel de fundamental importncia
em praticamente todas as atividades econmicas. Nesse sentido, difcil
encontrar uma atividade econmica que no utilize um SGBD. Assim, os
SGBDs so usados nas mais diferentes aplicaes comerciais, tais como nos
Sistemas de Gesto de Relacionamento com o Cliente (Customer Relationship
Management CRM), nos Sistemas de Gesto Empresarial (Enterprise
Resource Planning- ERP), nos Sistemas de Inteligncia do Negcio (Business
Intelligence BI), na Minerao de Dados (Data Mining), dentre outras.
Alm disso, os SGBDs podem ser encontrados em diversas plataformas
de hardware, desde servidores, computadores pessoais, equipamentos
portteis, tablets, dispositivos celulares, e, mais recentemente, na nuvem (ou
seja, nos ambientes de Computao em Nuvem Cloud Computing). Assim,
os SGBDs se tornaram fundamentais para a tomada de decises estratgicas
e, consequentemente, para a prpria sobrevivncia das corporaes. Alm
disso, os SGBDs esto presentes nas aplicaes de diversas reas, como
por exemplo, a medicina, as engenharias, os transportes, a biologia etc.
Esses sistemas tambm so utilizados pelo Governo para fornecer suporte
s implementaes das polticas pblicas, fazendo parte de diferentes
aplicaes, tais como: cadastro nico de pacientes, Bolsa Famlia, fila para
transplantes, cadastro de doadores de rgos, declarao de imposto de
renda etc.
Para ter ideia da importncia dos SGBDs, imagine as consequncias
caso uma empresa administradora de cartes de crdito perdesse os dados
armazenados sobre seus clientes e as operaes por eles realizadas, ou
um grande banco ou instituio financeira tivesse as informaes de seus
clientes corrompidas, ou a Receita Federal do Brasil perdesse os dados dos
contribuintes, ou ainda se a relao de famlias cadastradas no programa
Bolsa Famlia fosse perdida. Quais seriam as consequncias?
Adicionalmente, os SGBDs so encontrados no ncleo de diversas
pesquisas cientficas. Eles armazenam os dados coletados por astrnomos
(fotos de satlites, por exemplo), gelogos (movimentaes ssmicas ou
localizaes de reservas petrolferas, por exemplo), bilogos que buscam
decifrar o genoma humano ou pesquisam doenas genticas, bioqumicos
que procuram descobrir novos medicamentos, dentre outros.
O sucesso da utilizao dos Sistemas de Bancos de Dados advm de
um corpo de conhecimento e de tecnologia que se desenvolveu paulatinamente
ao longo de vrias dcadas. Em um Sistema de Banco de Dados, o conjunto
dos dados armazenados (denominado Banco de Dados) gerenciado por
um software especializado chamado de Sistema de Gerenciamento de Banco
de dados (SGBD). Um SGBD uma coleo de programas que permite ao
usurio definir, construir e manipular Bases de Dados para as mais diversas
finalidades. Um SGBD uma ferramenta poderosa, concebida para armazenar
e gerenciar grandes quantidades de dados de forma eficiente e segura.
Os SGBDs esto entre os sistemas de software mais complexos
da atualidade. Os principais recursos proporcionados por um SGBD so:
armazenamento persistente de grandes volumes de dados, recuperao
eficiente dos dados armazenados, interface para execuo de consultas,
interface para acesso via programas aplicativos, recuperao automtica
aps a ocorrncia falhas, gerenciamento do acesso concorrente dos vrios
usurios, mecanismos para autenticao e autorizao, dentre outros.
Dessa forma, compreender como os SGBDs so construdos e como
funcionam internamente se torna de fundamental importncia para: construir
novos SGBDs, adaptar os SGBDs existentes a necessidades especficas,
obter o mximo desempenho durante a execuo de suas tarefas, realizar
ajustes de desempenho (tuning) etc.
Este livro tem por objetivo proporcionar ao leitor os conhecimentos
necessrios para compreender como os SGBDs so construdos, como
executam suas tarefas internamente e como podem ser ajustados para
melhorar seu desempenho. Ao longo dos captulos iremos estudar os mdulos
que compem um SGBD, suas funcionalidades, como so implementados e
como podem ser ajustados. Esperamos que esta leitura fornea os subsdios
necessrios para iniciar a formao de novos profissionais (Administradores
de Bancos de Dados, Administradores de Dados etc) e despertar o interesse
na fascinante e dinmica rea de Banco de Dados.
Boa Leitura!!
UNIDADE 1
09 PROJETO FSICO DE BANCOS DE DADOS
1 SISTEMAS DE GERENCIAMENTO DE BANCOS DE DADOS

1.1 Introduo ............................................................15
1.2 Arquitetura ...........................................................16
1.3 Classificao dos Sistemas de Banco de Dados.....19
Exerccios ....................................................................20
2 ARMAZENAMENTO DE DADOS
2.1 Introduo ............................................................21
2.2 Discos Magnticos ............................................... 27
2.3 Tcnicas de RAID .................................................. 31
Exerccios ................................................................... 34
3 GERENCIAMENTO DE BUFFER
3.1 Sistema de Memria Virtual ................................ 38
3.2 O Gerenciador de Buffer ...................................... 40
3.3 Mecanismo de Paginao de SGBDs .................... 41
3.4 Polticas de Alocao de Pginas ......................... 42
Exerccios ....................................................................48
UNIDADE 2
41 PROCESSAMENTO DE TRANSAES
1 INTRODUO
1.1 O Problema da Concorrncia em BDs .................. 51
1.2 Conceito de Transao ......................................... 53
1.3 Estados de uma transao ....................................55
1.4. Propriedades da transao ..................................56
Exerccios ....................................................................57
2 EXECUES CONCORRENTES
2.1 Acessos Concorrentes ...........................................57
2.2 Controle de Concorrncia ................................................. 58
Exerccios ................................................................................ 61
3 ISOLAMENTO DE TRANSAES
3.1 Transaes Sequenciais .................................................... 62
3.2 Execuo Correta de Transaes Concorrentes ................ 63
3.3 Serializabilidade ................................................................ 66
3.4 Grafo de serializao de um Schedule .............................. 68
3.5 Prefixo de um Schedule S ..................................................69
Exerccios .................................................................................70
4 CONFIABILIDADE DE SCHEDULES
4.1 Corretude x Confiabilidade ............................................... 72
4.2 Schedule Recupervel .......................................................73
4.3 Schedule que Evita Abort em Cascata ...............................73
4.4 Schedule Preciso (Strict) ................................................... 74
Exerccios ...................................................................75
UNIDADE 3
69 CONTROLE DE CONCORRNCIA
1 INTRODUO
1.1 Conceitos iniciais ...............................................................79
1.2 Classificao dos Protocolos de Concorrncia .................. 79
Exerccios ................................................................................ 80
2. DESCRIO DOS PROTOCOLOS CONSERVADORES
2.1 Protocolos Baseados em Bloqueios .................................. 81
2.2 Tratamento de impasse .....................................................95
2.3 Granularidade de Bloqueios ............................................. 100
2.4 Bloqueio de duas fases com mltiplas verses .................105
2.5 Arquitetura de GTs que utilizam 2PL .................................109
2.6 Nveis de isolamento .........................................................110
Exerccios ................................................................................ 117
3. DESCRIO DOS PROTOCOLOS AGRESSIVOS
3.1 Protocolos baseados em Marcadores de Tempo
(timestamp) ............................................................................ 126
3.2 Teste do grafo de serializao ........................................... 128
3.3 Protocolos otimistas ..........................................................131
Exerccios ................................................................................ 132
UNIDADE 4
41 RECUPERAO DE BANCO DE DADOS

1.1 Introduo .................................................................137
1.2 Tipos de Falhas ..........................................................138
1.3 Recuperao baseada em log ....................................139
1.4 Gerenciamento de Buffer ..........................................141
1.5 Checkpoint ................................................................ 143
1.6 Tcnicas de Recuperao ...........................................145
1.7 Tcnica Recuperao de Meio de Armazenamento... 153
1.8 Recuperao baseada em Pginas Sombras ..............155
Exerccios .........................................................................156
WEBLIOGRAFIA ..........................................................................158
REFERNCIAS .............................................................................159
UNIDADE 1
PROJETO FSICO DE
BANCOS DE DADOS
Resumindo
Esta unidade discute, em detalhes, os principais aspectos relacionados ao projeto
fsico de sistemas de bancos de dados. Inicialmente, define-se o que um Sistema
de Gerenciamento de Banco de Dados (SGBD). Em seguida, discute-se a arquitetura
para um SGBD e uma classificao com as diferentes arquiteturas apresentada.
Posteriormente, examinamos os conceitos, as tcnicas e as estratgias relacionadas ao
armazenamento de dados, ao gerenciamento de buffer e indexao de dados.
PROJETO FSICO DE
BANCOS DE DADOS
1. SISTEMAS DE BANCOS DE DADOS
A finalidade de um sistema de bancos de dados simplificar e facilitar o

acesso aos dados armazenados. Assim, os usurios do sistema no devem se
preocupar desnecessariamente com os detalhes fsicos da implementao do
sistema, tampouco com detalhes acerca do armazenamento dos dados. 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 (consulta) muito
longo, o usurio ficar insatisfeito e pode at deixar de utilizar o sistema. Porm,
o desempenho de um sistema de banco de dados depende de diversos fatores,
dentre eles destacam-se: a eficincia das estruturas de dados internas usadas
para representar os dados no banco de dados; as tcnicas utilizadas para a troca
de dados entre o disco rgido e a memria principal do sistema; bem como as
estruturas de ndices utilizadas para recuperar dados de forma mais eficiente.
1.1 Introduo
Um Banco de Dados (BD) uma coleo de dados inter-

relacionados, 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, a manipulao e a
organizao dos dados. O SGBD disponibiliza uma interface para que os seus
clientes possam incluir, alterar ou consultar dados. Um Sistema de Banco de
Construo de Sistemas de Gerenciamento de Banco de Dados 15

Dados (SBD) consiste em uma coleo de dados inter-relacionados (BD) e uma
coleo de programas para prover o acesso aos dados 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 na recuperao
de informaes.
1.2 Arquitetura
Um SGBD dividido em mdulos, onde cada mdulo trata um aspecto

particular, e tem uma responsabilidade especfica. Na maioria dos casos,
o sistema operacional (SO) do computador fornece apenas os servios mais
bsicos (tais como acesso aos dados armazenados no disco rgido etc) 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 (ou seja, sobre a comunicao e interao) entre o sistema de banco
de dados e o sistema operacional.
Figura 1.1 Arquitetura de um SBD
16 UNIDADE 1
A Figura 1 ilustra os principais componentes funcionais de um sistema
de banco de dados. Nessa 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. Dessa forma, busca-se encontrar
uma boa estratgia para executar a consulta fornecida pelo usurio (ou pela
aplicao). 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 esses comandos
para uma das formas de representao interna de consultas (como por exemplo,
a lgebra relacional). Exemplos de comandos DML so: SELECT, INSERT,
UPDATE e DELETE.
Pr-Compilador DML
Traduz comandos DML, embutidos em programas aplicativos (aplicaes
Java, por exemplo) que acessam o sistema de banco de dados (por meio de
JDBC ou SQLJ, por exemplo), em chamadas a procedimentos (rotinas) em uma
linguagem hospedeira. O pr-compilador precisa interagir com o processador de
consultas para gerar o cdigo apropriado.
Interpretador DDL
Interpreta comandos DDL (Data Definition Language) e os armazena
no catlogo (log ou metabase). Um catlogo uma tabela que armazena
metadados. J os metadados descrevem o banco de dados, ou seja, o esquema
do banco de dados. Exemplos de comandos DDL so: CREATE TABLE, ALTER
TABLE, DROP TABLE, dentre outros.
Mecanismo de Consultas
Responsvel pela otimizao e pela gerao de planos de execuo de
consultas.
O Sistema de Armazenamento fornece a interface entre os dados

armazenados no disco (como conjuntos de bytes armazenados em trilhas e
setores do disco rgido) e os programas aplicativos e de consulta que necessitam
acessar esses dados. Para isso, o sistema de armazenamento interage
diretamente com o sistema operacional. O Sistema de Armazenamento dividido
nos seguintes mdulos:
Gerenciador de Transaes
Responsvel pelo controle de concorrncia e pela recuperao do banco
de dados aps a ocorrncia de falhas (falta de energia durante o funcionamento
do SBD, por exemplo).
Gerenciador de Buffer
Responsvel por recuperar dados armazenados em um disco rgido e
carreg-los na memria principal, em forma de pginas.
Gerenciador de Arquivo (File System)
Responsvel pelo armazenamento fsico dos dados 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. Logo,
esse componente define se ser utilizada uma alocao sequencial, sequencial
indexada ou indexada, por exemplo.
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. Esses 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 bastante frequncia.
Assim, deve-se dar grande ateno tanto ao projeto quanto
implementao do dicionrio. Nesse sentido, deve-se buscar um projeto
adequado e uma implementao eficiente do catlogo.
ndices, estruturas que fornecem acesso rpido aos dados armazenados
em disco. Isso possvel guardando-se determinados valores (chaves
de busca e ponteiros). O funcionamento das estruturas de ndices
assemelha-se utilizao de um ndice de um livro, de um catlogo
telefnico ou da agenda de um telefone celular. No caso da agenda
telefnica, por exemplo, quando fornecemos a letra e iremos obter
todos os contatos cujo nome inicia-se pela letra e, tornando o acesso a
18 UNIDADE 1
esses dados mais rpido.
Fragmentos de Cdigo, tais como procedimentos armazenados (stored
procedures) e gatilhos (triggers).
1.3 Classificao dos Sistemas de Bancos de Dados
Os primeiros SGBDs eram hospedados (instalados) em mainframes

(computadores de grande porte). Todos os mdulos que compem o SBD eram
executados no mainframe. Todas as funes do SBD eram executadas pelo
mainframe. Alm disso, todos os programas aplicativos que utilizavam o SBD
tambm eram executados no mainframe. Assim, a maioria dos usurios fazia
acesso aos SBDs via terminais que no possuam poder de processamento,
apenas a capacidade para entrada e sada (visualizao) de dados. Todos os
processamentos, tanto do SBD quanto dos programas aplicativos, eram realizados
remotamente, no mainframe. Apenas as informaes a serem visualizadas e
os controles eram enviados do mainframe para os terminais de visualizao
(denominados tambm de terminais burros), conectados ao mainframe por meio
de redes de comunicao. medida que os preos dos dispositivos de hardware
foram decrescendo, muitos usurios trocaram seus terminais por computadores
pessoais (Personal Computer PC) e por 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 (denominada servidor).
Gradualmente, os SGBDs comearam a explorar a disponibilidade do poder de
processamento no lado do usurio (ou cliente), o que levou arquitetura cliente-
servidor. Atualmente, existem vrias tendncias para arquitetura de Sistemas
de Bancos 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. Nesse 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 de dados do SGBD entre
clientes e servidor em ambientes de computao mvel.
Exerccios
1. Diferencie Banco de Dados, Sistema de Gerenciamento de Banco de Dados

e Sistema de Banco de Dados?
2. Descreva os componentes funcionais de um SGBD.
3. Como podemos classificar os Sistemas de Bancos de Dados?
4. Quais os componentes do SGBD que interagem diretamente com o Sistema

Operacional?
5. Quais os componentes do SGBD que interagem com o usurio?
20 UNIDADE 1
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, esses dados, em ltima
instncia, precisam ser armazenados como bits, em trilhas e setores, em um ou
mais dispositivos de armazenamento. Atualmente, 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. Logicamente, aps os dados armazenados na
memria principal do computador serem atualizados (alterados), esses precisam
ser copiados novamente para o disco rgido. Essas operaes so denominadas
operaes de entrada e sada (E/S ou I/O) de dados. Em geral, as leituras e as
escritas de dados so realizadas por meio de unidade denominada pgina de
dados. Assim, o SBD l ou grava uma ou mais pginas de dados por vez.
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 armazenamentos

de dados. Esses meios fsicos de armazenamento podem ser classificados de
acordo com diferentes fatores, como por exemplo: a velocidade com que os
dados podem ser acessados, o custo e a confiabilidade. A seguir, destacamos
os principais tipos de meios fsicos de armazenamento. Esses meios de
armazenamento formam uma hierarquia de armazenamento que inclui as
seguintes categorias:

Memria Interna do Processador
Compreende um pequeno conjunto de registradores de alta
velocidade. Esses registradores so utilizados como memria de trabalho para
armazenamento temporrio de instrues e dados. Alguns desses registradores
so: registrador acumulador, registrador B, registrador contador etc.
Memria Cache
Dispositivo de memria que funciona como dispositivo de armazenamento
temporrio e intermedirio entre registradores e memria principal. Como
exemplo desses dispositivos, podemos citar: Cache L1 (pequena poro de
memria esttica presente dentro do processador) e Cache L2 (poro de
memria bem maior que a Cache L1, embora, em geral, mais lenta. Alguns
processadores colocam essa cache fora do processador).
Memria Principal (ou Memria Primria)
Utilizada no armazenamento de programas e dados que esto sendo
manipulados 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 (in-memory database).
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 flash que j foi escrito anteriormente,
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 nmero limitado de ciclos de apagamento/escrita, variando de 10.000 a
1 milho. A memria flash um tipo de memria EEPROM (Electrically-Erasable
Programmable Read-Only Memory).
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). Contudo, atualmente, a memria flash comea a ser utilizada para substituir
22 UNIDADE 1
os discos rgidos em computadores portteis (notebooks).
Memria Secundria (Armazenamento em Discos Magnticos)
O principal meio para armazenamento de dados em longo prazo o
disco magntico. Esse dispositivo apresenta 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
armazenamento no voltil, ou seja, os dados armazenados sobrevivem a faltas
de energia e a 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. Dessa forma, dados podem ser perdidos. Contudo, essas
falhas normalmente ocorrem com muito menos frequncia do que as falhas do
sistema (tais como falta de energia e crash).
Memria Terciria
A memria terciria 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 (backup).
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 de leitura/gravao e vrios discos que podem ser carregados em uma
das unidades automaticamente (por um brao mecnico).
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 sequencialmente desde o incio. Assim, o armazenado em fita
chamado de armazenamento de acesso sequencial, enquanto o armazenamento
em disco chamado de armazenamento de acesso direto ou aleatrio. As fitas
possuem alta capacidade de armazenamento, alm disso, podem ser removidas
das unidades (leitoras/gravadoras) de fita e transportadas. Logo, so bastante
adequadas para o 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), de acordo com sua velocidade (tempo de acesso)
e seu custo. Os nveis mais altos so caros, mas so rpidos. Ao descermos na
hierarquia, o custo por bit diminui, a capacidade de armazenamento aumenta e
a velocidade diminui (ou seja, o tempo de aceso tambm cresce).
A seguir iremos descrever as principais caractersticas dos meios fsicos
de armazenamento.
2.1.1 Caractersticas dos Meios Fsicos de Armazenamento
Custo (c): O custo de um meio fsico de armazenamento

definido por:
c=CT/CA (dollars/bit)
em que 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 (desempenho) para dispositivos
de 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.
24 UNIDADE 1
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. Esse mtodo de acesso
utilizado na memria principal e na memria flash, por exemplo.
Figura 2.2
(ii) Serial-access memory (memria de acesso sequencial):

Dispositivos cujas posies s podem ser acessadas em
sequncias pr-definidas. Esse tipo de memria apresenta um
nico mecanismo de acesso (leitura/gravao) compartilhado
por vrias posies de memria. Esse mtodo de acesso
utilizado nas fitas magnticas, por exemplo.
Alterabilidade: Caracterstica que representa a capacidade de

permitir a alterao do contedo de memria.
(i) Read-only memory (ROM). Memria somente de leitura.
Esse tipo de memria utilizado no BIOS (Basic Input/
Output System ou Sistema Bsico de Entrada/Sada).
O BIOS um programa de computador previamente
gravado em uma memria ROM. Esse programa
executado automaticamente quando um computador
ligado. O BIOS responsvel pelo teste automtico de
alguns dispositivos de hardware, bem como por iniciar a
carga do sistema operacional.

(ii) Read-write memory (RWM). Memria de leitura e de escrita.
Como exemplo desse tipo de memria, podemos citar a memria
principal e os discos rgidos, dentre outros.
Persistncia de Armazenamento: Os processos fsicos
envolvidos no armazenamento de dados 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 a informao armazenada.
(i) Destructive read-out DRO (leitura destrutiva): Em alguns
dispositivos de armazenamento, o mtodo de leitura destri a
informao armazenada. Em 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 processo de decaimento. Por
exemplo, muitos dispositivos armazenam um 1 por meio de
uma carga eltrica em um capacitor. Com o passar do tempo, a
carga armazenada no capacitor 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. Nas memrias volteis, o seu contedo
perdido quando o fornecimento de energia interrompido. As
memrias no volteis conservam o seu contedo mesmo aps
a interrupo do fornecimento de energia.
2.1.2 Armazenamento de Bancos de Dados

Em geral, os bancos de dados envolvem grandes volumes de dados,
os quais devem ser armazenados por longos perodos de tempo. Alm disso,
os dados necessitam ser acessados e processados diversas vezes. Nesse
sentido, os bancos de dados, geralmente, necessitam ser armazenados de
forma permanente (ou persistente) em memria secundria, ou seja, em discos
magnticos. A seguir, discutimos, em detalhes, os motivos pelos quais os bancos
26 UNIDADE 1
de dados necessitam ser armazenados em discos rgidos (ou seja, em meios de
armazenamento secundrio):
Frequentemente os bancos de dados so muito grandes (ou
seja, envolvem grandes volumes de dados) para caberem
inteiramente na memria principal;
As circunstncias que causam a perda permanente de
dados armazenados so menos frequentes nos meios de
armazenamento secundrio (discos magnticos, por exemplo)
do que nos meios de armazenamento primrio (memria
principal, por exemplo).
O custo de armazenamento por unidade de dados menor nos
discos magnticos do que nos dispositivos de armazenamento
primrio;
Por esses motivos, espera-se que os discos magnticos continuem a ser
a mdia mais utilizada para armazenar grandes bancos de dados nos prximos
anos. Contudo, atualmente, o armazenamento de bancos de dados tanto em
memria flash quanto inteiramente em memria principal (in-memory database)
comeam a ser investigados.
Vale destacar ainda que as tcnicas utilizadas para armazenar grandes
volumes de dados em discos magnticos so importantes tanto para os
administradores de bancos de dados e DBAs (Database Administrators) quanto
para desenvolvedores de SGBDs. Os DBAs devem conhecer as vantagens e as
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 adquem 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, ou disco duro, (popularmente conhecido como winchester)

ou ainda HD (do ingls Hard Disk), a parte do computador onde so armazenadas
as informaes, ou seja, a "memria permanente" propriamente dita. O disco

rgido memria fsica e no voltil. Logo, as informaes armazenadas no
disco rgido no so perdidas quando o computador desligado.
O disco rgido um sistema lacrado contendo discos de metal recobertos
por um material magntico onde os dados so gravados por meio de cabeotes
de leitura/gravao. O disco rgido revestido externamente por uma proteo
metlica que presa ao gabinete do computador por parafusos. So nos discos
rgidos que, normalmente, gravamos dados (informaes) e programas, os quais
devem ser carregados para a memria principal do computador a fim de que
sejam utilizados ou executados, respectivamente.
A utilizao de discos rgidos necessria porque o contedo da
memria principal (RAM) apagado (perdido) quando o computador desligado.
Dessa forma, na prxima vez em que o computador for ligado, temos um meio
de executar novamente os programas e carregar, na memria principal, arquivos
contendo os dados. O disco rgido tambm denominado 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 (que possuem o mesmo centro). Em geral, existem de 20 a 1500
trilhas por superfcie. Cada trilha est subdividida em setores, conforme mostra
a Figura 2.3.. Um setor representa a menor unidade de informao que pode
ser lida ou escrita (gravada) no disco. O tamanho de um setor pode variar de 32
bytes at 4096 bytes, dependendo da tecnologia utilizada. Contudo, tipicamente,
um setor possui 512 bytes e existem de quatro a 32 setores por trilha. Um cilindro
definido como sendo um conjunto de trilhas verticalmente alinhadas e com
mesmo raio (e, consequentemente com o mesmo dimetro).
As superfcies de um disco magntico so recobertas por uma camada
magntica extremamente fina. Na verdade, quanto mais fina for essa camada
de gravao, maior ser sua sensibilidade, e consequentemente maior ser a
densidade de gravao permitida por ela. A densidade de gravao indica a
quantidade de dados que pode ser armazenada em uma determinada rea da
superfcie.
28 UNIDADE 1
Figura 2.3 Viso geral de um disco rgido
Assim, discos com um mesmo tamanho podem apresentar capacidades
de armazenamento diferentes (uma vez que as densidades de gravao desses
discos podem ser diferentes).
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 mecnico denominado 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 superfcies de
discos de uma unidade movimentam-se em conjunto (simultaneamente) e so
acionadas pelo suporte do brao. Assim, quando o cabeote de leitura/gravao
da superfcie 1 est posicionado na trilha 10, por exemplo, todos os cabeotes
de leitura/gravao de todas as demais superfcies tambm esto posicionados
sobre a trilha 10 (de suas respectivas superfcies).
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 esse motivo, procura-se
otimizar o acesso ao disco armazenando-se os dados de um mesmo arquivo em
um mesmo cilindro.
A superfcie de gravao dos discos (ou pratos) composta de materiais
sensveis ao magnetismo (geralmente, xido de ferro). O cabeote de leitura/
gravao manipula as molculas desse material por meio de seus polos. Para
isso, a polaridade dos cabeotes muda numa frequncia muito elevada: quando
est positiva, atrai o polo negativo das molculas e vice-versa. Assim, 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 com a finalidade de determinar os bits que
esto sendo lidos (0 ou 1).
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 do disco sobre a trilha
correta (desejada). Como a movimentao do brao do disco
um processo mecnico, o tempo de procura tende a ser elevado,
em comparao com os demais tempos envolvidos na leitura de
um setor (menor unidade de leitura).
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.
30 UNIDADE 1
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 (em 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, nos SGBD atuais, o
custo de acesso a disco domina (ou seja, o principal componente) o custo de
execuo das consultas. Assim, em relao execuo de uma determinada
consulta SQL pelo SGBD, o custo de acesso a disco maior que o custo de
processamento (custo de utilizao do processador), por exemplo.
2.3 Tcnicas RAID
RAID a sigla para Redundant Array of Independent Disks. Sua definio

em portugus seria "Matriz Redundante de Discos Independentes". A tecnologia
RAID combina vrios discos rgidos (HDs) para formar uma nica unidade lgica.
Em outras palavras, um conjunto de HDs que funciona como se fossem um nico
HD. Essa estratgia permite ter uma alta tolerncia contra falhas, pois se um
disco tiver problemas, os demais podem continuam funcionando. Atualmente, o
RAID uma tecnologia consolidada. Essa tcnica foi proposta por pesquisadores
da Universidade de Berkesley, na Califrnia (EUA) no final da dcada de 1980.
Para que tenhamos um dispositivo RAID, preciso utilizar pelo menos
dois HDs. O sistema operacional, nesse caso, enxergar os discos como uma
unidade lgica nica. Quando h gravao de dados, os mesmos se repartem
entre os discos do RAID (dependendo do nvel de RAID utilizado). 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" (hot spots).
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 de distribuio de dados e de
redundncia.
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 Esse nvel tambm conhecido como "Striping" ou
"Fracionamento". O RAID Nvel 0 utiliza uma distribuio paralela e no
redundante dos blocos que compem um arquivo. Nele, os dados so divididos
em pequenos segmentos e distribudos entre os discos. Esse 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 (desempenho) do computador, uma
vez que a distribuio dos dados entre os discos proporciona grande velocidade
na gravao e leitura de informaes, uma vez que agora dois setores podem
ser lidos simultaneamente (em paralelo), um em cada disco. Assim, quanto
mais discos houver, mais velocidade obtida. Isso porque, se os dados fossem
gravados em um nico disco, esse processo seria feito de forma sequencial.
RAID nvel 1 Tambm conhecido como "Mirroring" ou "Espelhamento".
O RAID 1 funciona adicionando HDs paralelos (espelhos) aos HDs principais
existentes no computador. Assim, se, por exemplo, um computador possui dois
discos, pode-se aplicar mais um HD para cada um, totalizando quatro. Os discos
que foram adicionados trabalham como uma cpia do primeiro. Assim, se uma
informao gravada em dos discos principais, essa informao tambm
gravada em seu disco espelho. Da o nome de "espelhamento. Dessa forma,
se um dos HDs principais apresentar falha, o seu disco espelho pode assumir
imediatamente a funo do primeiro, possibilitando que o sistema continue
funcionando. Contudo, no RAID Nvel 1 a gravao de dados mais lenta,
pois agora cada operao de escrita realizada duas vezes, no disco principal
e no seu disco espelho. No entanto, a leitura dessas informaes pode ser
rpida, uma vez que se pode acessar o disco principal e sua cpia espelho
simultaneamente (em paralelo). O RAID 1 utiliza uma organizao de discos
com distribuio paralela (baseada em blocos) e redundncia (implementada
atravs de replicao).
32 UNIDADE 1
RAID nvel 2 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 por meio de bits de
paridade. Vale destacar que se pode utilizar tanto paridade par quanto paridade
mpar.
RAID nvel 3 Nesse nvel, os dados so divididos entre os discos que
compem a matriz (RAID), exceto um, que armazena informaes de paridade.
Assim, se cinco discos compem o dispositivo RAID, quatro discos sero utilizados
para armazenar dados, enquanto um disco ser utilizado para armazenar os
bits de paridade. O RAID 3 consegue oferecer altas taxas de transferncia e
confiabilidade das informaes armazenadas. Para usar o RAID 3, pelo menos
trs discos so necessrios (dois discos de dados e um de paridade).
RAID nvel 4 O RAID 4 no apresenta distribuio, ou seja, os
blocos so armazenados da mesma forma que em discos comuns. Assim, uma
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. Nesse disco, o bloco i
armazena bit de paridade dos blocos i de todos os discos de dados.
RAID nvel 5 O RAID Nvel 5 bastante semelhante ao RAID Nvel
4, exceto pelo fato de que os bits de paridade no ficam armazenados em um
nico disco, mas em todos os discos que compem a matriz. Isso faz com que
a gravao de dados seja mais rpida, pois no necessrio acessar um disco
de paridade em cada gravao. Assim, o disco de paridade no se torna um
gargalo (hot spot). Apesar disso, como a paridade distribuda entre os
discos, o nvel 5 tende a ter um menor desempenho que o RAID 4 nas operaes
de leitura. O RAID 5 o nvel mais utilizado atualmente.
RAID nvel 6 O RAID Nvel 6 semelhante ao RAID Nvel 5. Contudo.
O RAID Nvel 6 utiliza redundncia P + Q, ou seja, armazena informaes
adicionais para recuperar dados no caso de falha em mais de um disco. Assim,
o RAID Nvel 6 garante um maior grau de confiabilidade que o RAID 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, em seguida, para cada espelho h a segmentao (distribuio)
sobre vrios discos.
RAID 0 + 1 O RAID 0 + 1 uma combinao dos nveis 0 (Striping)
e 1 (Mirroring), onde os dados so primeiramente distribudos (segmentados)

entre os discos, para melhorar o desempenho, e, em seguida, os dados so
espelhados, para garantir a redundncia (melhorando a disponibilidade dos
dados). Assim, possvel unir os ganhos de desempenho proporcionados pelo
nvel 0 com a redundncia do nvel 1. No entanto, so necessrios pelo menos
quatro 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.
2.3.2 Tipos de RAID

Existem dois tipos de RAID, sendo um baseado em hardware e o outro
baseado em software. Cada um desses dois modelos possui vantagens e
desvantagens. O RAID baseado em hardware o modelo mais utilizado, pois no
depende de sistema operacional uma vez que, nesse caso, os SOs enxergam
o RAID como um nico disco, de grande capacidade e so bastante rpidos, o
que possibilita explorar integralmente seus recursos. Sua principal desvantagem
o alto custo. O RAID baseado em hardware utiliza 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
na prtica, pois apesar de apresentar custo menor, apresenta um desempenho
menor (sendo mais lento), sua instalao/configurao mais complexa e sua
utilizao depende do sistema operacional. O RAID implementado por software
depende tambm dos recursos computacionais do computador em que
utilizado. Logo, seu desempenho fica atrelado capacidade de processamento e
armazenamento do computador (hardware) no qual est instalado/configurado.
Exerccios
1. Tanto a memria principal quanto o disco possibilitam o acesso direto a

uma determinada localizao (pgina). Entretanto, em mdia, o acesso
memria principal mais rpido. Qual a outra diferena fundamental entre
esses dispositivos (do ponto de vista do tempo necessrio para acessar
uma determinada pgina)?
O tempo de acesso memria principal independente da localizao a

ser acessada.
2. Caso voc tenha um arquivo que frequentemente percorrido

sequencialmente, qual a melhor maneira de armazenar as pginas desse
arquivo em um disco?
34 UNIDADE 1
O ideal seria armazenar as pginas desse arquivo em blocos contguos no
disco e preferivelmente em um mesmo cilindro, pois o acesso ficaria mais
rpido devido menor necessidade de movimentao dos cabeotes de
leitura/gravao.
3. Considere um disco com setores de 512 bytes (tamanho), 2.000 trilhas por
superfcie, 50 setores por trilha, cinco pratos (discos fsicos) de dupla face
e tempo de busca de 10 ms.
- Qual a capacidade de uma trilha em bytes?
tamanho do setor x nmero de setores por trilha =
512 x 50 bytes = 25.600 bytes.
- Qual a capacidade de uma superfcie?
tamanho do setor x nmero de setores por trilha x nmero de
trilhas =
512 x 50 x 2000 bytes = 51.200.000 bytes
- Qual a capacidade de um disco (prato)?
tamanho do setor x nmero de setores por trilha x nmero de
trilhas x nmero de faces =
512 x 50 x 2000 x 2 bytes = 102.400.000 bytes
- Quantos cilindros existem em um disco?
Cilindro o conjunto de trilhas pertencentes a diferentes
superfcies e discos de uma mesma unidade, mas que apresentam a
mesma posio relativa. No disco considerado na questo, cada cilindro
possui 10 trilhas (cinco pratos x duas faces). No entanto, a quantidade
de cilindros do disco igual ao nmero de trilhas existentes em cada
superfcie. Logo, o disco possui 2.000 cilindros.
- Fornea exemplos de tamanhos de blocos vlidos. Pode existir
um bloco de 256 bytes?
Como pelo enunciado os setores do disco possuem 512 bytes,
temos como exemplos de tamanhos de blocos vlidos: 512, 1024, 2048
ou 4096 bytes por bloco. Como o setor a menor unidade de informao
que pode ser escrita no disco (Slide 36) e o setor do disco tem 512 bytes,
ento no possvel existir bloco menor que 512 bytes. Logo, NO pode
existir um bloco de 256 bytes para o disco da questo.
- Podemos ter blocos de 2048 bytes? e de 51.200?
Como pelo enunciado os setores possuem 512 bytes, podemos
ter blocos de 2048 bytes ou mesmo de 51.200, uma vez que 2048 e

51.200 so mltiplos de 512. Nesse caso, um bloco de 2048 bytes seria
formado por 4 setores e um bloco de 51.200 bytes seria formado por 100
setores.
- Se a taxa de rotao for de 5.400 rpm (rotaes por minuto),
qual o tempo mximo de espera?
Ta = Tp + Tl + Tt (Slide 41), onde:
Ta Tempo de acesso a um setor
Tp Tempo de procura = 10 ms = 1 / 100 s
Tl Tempo de Latncia = (2r), onde r a taxa de rotaes/
segundo
Tt Tempo de transferncia = n(rN), onde n o tamanho de
um setor e N a capacidades das trilhas.
r = 5400 rpm = 90 rotaes/segundo
n = 512 bytes
N = (512 x 50) bytes
Assim, temos:
Ta = Tp + (2r) + n(rN)
Ta = 1 / 100 + (2 x 90) + 512 x (90 x 512 x 50)
Ta = 1 / 100 + 1 / 180 + 512 / (90 x 512 x 50)
Ta = 1 / 100 + 1 / 180 + 1 / 4500
Ta = (45 + 25 + 1) / 4500
Ta = 71 / 4500 = 0,015777778 s = 15,777777778 ms
- Assumindo-se que uma trilha de dados pode ser transferida a
cada rotao, qual a taxa de transferncia?
TTr = rN
N = (512 x 50) bytes
Assim:
TTr = 90 x 512 x 50 = 2.304.000 bytes/s (aprox. 2,2 MB/s)
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?
Tamanho do bloco = 1.024 bytes
36 UNIDADE 1
Tamanho do registo = 100 bytes
Assim, at 10 registros (1.024 / 100) podem ser armazenados
em um bloco, sendo que 24 bytes do bloco ficam ociosos por
no serem capazes de armazenar um registro inteiro.
- Quantos blocos so necessrios para armazenar o arquivo por
inteiro?
100.000 blocos so necessrios para armazenar 1.000.000 de
registros
- Quantos registros de 100 bytes cada podem ser armazenados
usando esse disco?
Capacidade total do disco = (512 x 50 x 2000 x 2 x 5) bytes
Quantidade total de blocos no disco = (512 x 50 x 2000 x 2 x 5)
/ 1024 = 50 x 2000 x 5
Como podemos ter 10 registros em cada bloco, o total de
registros :
10 x qtd. blocos = 10 x (50 x 2000 x 5) = 5.000.000
Logo, 5.000.000 de registros podem ser armazenados usando
esse disco.
- Qual o tempo necessrio para ler um arquivo contendo 100.000
registros de 100 bytes cada sequencialmente?
Ta = Tp + Tl + Tt (Slide 41), onde:
Ta Tempo de acesso a um setor
Tp Tempo de procura = 10 ms = 1 / 100 s
Tl Tempo de Latncia = (2r), onde r a taxa de rotaes/
segundo
Tt Tempo de transferncia = n(rN), onde n o tamanho de
um setor e N a capacidades das trilhas.
n = 512 bytes
N = (512 x 50) bytes
Em cada bloco cabem 10 registros de 100 bytes. 10.000 o n
de blocos que precisam ser percorridos para a leitura de 100.000
registros. Como cada bloco (1024 bytes) tem dois setores (2 x
512 bytes), precisamos percorrer 20.000 setores para a leitura
de 100.000 registros.
Assim temos:
T = Tp + (2r) + qtd. setores x n(rN)

T = 1 / 100 + (2 x 90) + 20.000 x 512 x (90 x 512 x 50)
T = 1 / 100 + (1 / (2 x 90)) + 20.000 x 512 x (1 / (90 x 512 x 50))
T = 1 / 100 + 1 / (2 x 90) + 20.000 / (90 x 50)
T = (45 + 25 + 20.000) / 4500 = 4,46 s
- Qual o tempo necessrio para ler um arquivo contendo 100.000
registros de 100 bytes cada em uma determinada ordem
randmica?
Ta = 71 / 4500 [ver questo 3 item g]
T = qtd. registros x Ta
T = 100.000 x 71 / 4500 = 1.577,777777778 s
3. GERENCIAMENTO DE BUFFER
O gerenciador de buffer o subsistema do SGBD responsvel pela

alocao da poro 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). Do ponto de vista do desempenho
do SGBD, o ideal seria que todas as informaes que um SGBD manipula
estivessem na memria principal do computador. Como isso no possvel, uma
vez que a memria principal um recurso limitado (pequena capacidade de
armazenamento) e caro (de elevado custo financeiro), 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 (alocada) para o
armazenamento de cpias dos blocos (pginas) de um banco de dados. H
sempre uma cpia de cada bloco (pgina) que mantida no disco rgido. Isso
necessrio devido ao fato da memria principal ser voltil, enquanto a memria
secundria no voltil. Contudo, para que 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 constituir-se em uma verso mais antiga do que a
verso da cpia do mesmo bloco armazenada no buffer, uma vez que todas as
atualizaes sobre os dados ocorrem na memria principal (ou seja, nas cpias
dos blocos armazenadas no buffer).
3.1 Sistema de Memria Virtual
Quando uma aplicao solicita uma informao do banco e dados, o
38 UNIDADE 1
SGBD antes de busc-la no disco, verifica se essa j se encontra em algum
bloco (pgina) no buffer. Vale lembrar que todos os dados de um banco de
dados so armazenados em blocos (pginas) e que a menor unidade de leitura e
gravao em um disco rgido uma pgina (bloco). Caso a informao desejada
j se encontre em um determinado bloco do buffer, o SGBD envia aplicao o
endereo desse bloco, para que esse seja lido/acessado pela aplicao. Caso
a informao desejada no se encontre em nenhum dos blocos presentes no
buffer, a cpia do bloco que contm essa informao e que est armazenada
no disco rgido (memria secundria) dever ser copiada para o buffer, criando-
se uma cpia desse bloco na memria principal. Nesse momento, o bloco que
contm a informao requisitada pela aplicao ter duas cpias: uma em disco
e outra no buffer.
Para que isto seja possvel, o gerenciador de buffer precisa alocar
(reservar) um espao no buffer para armazenar a cpia do bloco requisitado
(que est em disco). Caso haja espao no buffer, essa alocao realizada
sem nenhuma dificuldade. Porm, caso todo o espao do buffer esteja ocupado,
ser necessrio retirar algum dos blocos correntemente armazenados no
buffer para liberar espao. Nesse caso, o gerenciador de buffer deve verificar
se o bloco eleito (escolhido) para ser retirado do buffer foi alterado. Em caso
afirmativo, ele dever ser reescrito (gravado) no disco. Caso contrrio, ele pode
ser simplesmente descartado. Em seguida, uma cpia do bloco requisitado
pela aplicao (armazenado em disco) armazenada no espao (bloco) que
foi liberado no buffer. Por fim, o endereo desse bloco (endereo no buffer)
enviado para a aplicao, a fim de que essa possa ler (acessar) a informao
desejada.
O gerenciador de buffer funciona de maneira anloga (semelhante)
ao gerenciador de memria virtual de um sistema operacional. Uma diferena
importante 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 implementa 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 principal de um sistema de memria virtual dar a iluso
ao usurio do SGBD que existe uma nica memria principal com capacidade
ilimitada. Alm disso, sistema de memria virtual busca obter 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. Assim, existe
apenas uma cpia carregada na memria. Logicamente, esse cdigo no pode
ser alterado e cada usurio pode estar em um ponto distinto 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 carrega de M2 para M1 a informao
requerida. Dessa forma, um gerenciador de buffer eficiente aquele em que a
Informao desejada deve ser encontrada em M1 com uma taxa de frequncia
tima.
O desempenho (performance) de um gerenciador de buffer medida
com base na sua taxa de acerto (H) (ou buffer cache hit ratio). 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
40 UNIDADE 1
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.
Na prtica, os SGBDs buscam atingir taxas de acertos maiores que 95%.
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 (2)
Assim, substituindo (2) em (1), temos:
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.
3.3 Mecanismo de Paginao em SGBDs
A operao mais importante em qualquer sistema de memria virtual

a troca (transferncia) de blocos de informao entre os nveis de memria.
Essa operao denominada paginao (ou swapping). Essa troca ocorre de
acordo com a demanda de processamento, ou seja, de acordo com a ordem e
frequncia com que as informaes so solicitadas.
Por Demanda de Paginao entende-se a propriedade que indica
quando uma operao de paginao deve ocorrer, ou seja, quando a paginao
necessria.

A Poltica de Alocao diz respeito ao mtodo utilizado para determinar o
local (endereo) da memria principal (mais precisamente, do buffer) onde uma
cpia de uma determinada pgina do disco deve ser carregada.
Existem dois tipos de alocao: Alocao Esttica e Alocao Dinmica.
Na alocao esttica, cada pgina de dados est ligada (associada) a uma regio
fixa da memria principal (buffer). J na alocao dinmica, a regio de memria
principal (buffer) na qual uma pgina K carregada pode variar. A alocao
dinmica pode ser ainda classificada em preemptiva e no preemptiva.
Na alocao dinmica no preemptiva, a pgina K 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 J. Nesse caso, a pgina J deve ser
realocada 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:
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 (ou seja, h mais 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
(requisitados). Por isso, tais sistemas, em geral, utilizam o padro de referncias
(requisies) 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. Em geral,
42 UNIDADE 1
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 requisitados 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 possuir e utilizar
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:
Departamento Empregado
Considere que a tabela Departamento possui os atributos DEP_CODIGO
e DEP_NOME. Assuma ainda que a tabela Empregado possui os atributos
EMP_CPF, EMP_NOME e DEP_CODIGO (chave estrangeira utilizada para
representar em que departamento um empregado trabalha).
Suponha que o algoritmo de juno a ser utilizado o Nested-Loop Join
(mostrado a seguir). Assuma tambm que as duas relaes desse exemplo
sejam armazenadas em arquivos separados.
Para cada tupla d de departamento faa
Para cada tupla e de empregado faa
Se d[EMP_CODIGO] = e[EMP_CODIGO] ento
Incio
Seja x definida da seguinte forma:
x[DEP_CODIGO]:= d[DEP_CODIGO]
x[DEP_NOME]:= d[DEP_NOME]
x[EMP_CPF]:= e[EMP_CPF]
x[EMP_NOME]:= e[EMP_NOME]
Inclua a tupla x como parte do resultado de departamento
x empregado
Fim
Fim
Fim

Vamos mostrar a seguir que as polticas 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 esse fato ocorre
quando vrios usurios requisitam uma leitura sequencial (scan) de um conjunto
de dados (uma tabela, por exemplo).
Considere, inicialmente, a seguinte situao. Suponha que o buffer pool
possua 10 pginas, e que o arquivo a ser lido (tabela empregado, por exemplo)
contm nove pginas. Assuma, por simplicidade, que no existe concorrncia na
requisio das pginas. Assim, 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 subsequentes iro sempre encontrar a pgina desejada
no buffer. Nesse caso, o SGBD ter uma taxa de acerto de 0% na primeira
operao de varredura (scan) e uma taxa de acerto de 100% nas varreduras
subsequentes.
Por outro lado, suponha que o arquivo (tabela empregado, por exemplo),
a ser lido sequencialmente, possui 11 pginas. Nesse caso, o nmero de
pginas do arquivo a ser lido maior que o nmero de pginas disponveis no
buffer (ou seja, maior que o tamanho total do buffer). Logo, o arquivo no poder
ser carregado integralmente na memria. Dessa forma, observe que durante
a execuo da primeira operao de varredura (scan), quando a pgina 10 do
arquivo for transferida para o buffer, esse ficar com todas as suas pginas
ocupadas (uma vez que o tamanho do buffer de 10 pginas ou blocos), ou seja,
o buffer estar completamente preenchido (sem nenhum espao livre). Logo,
quando a pgina 11 do arquivo for requisitada, uma das pginas presentes no
buffer dever ser escolhida para sair do buffer, a fim de liberar espao para que
a pgina 11 seja copiada do disco para o buffer. Que pgina ser escolhida
para sair do buffer? Pelo algoritmo LRU a pgina escolhida ser aquela menos
recentemente utilizada, que nesse caso ser a pgina 1 (primeira pgina a ser
carregada na memria, ou seja, no buffer). Assim, a pgina 1 ser retirada da
memria. Em seguida, uma cpia da pgina 11 ser alocada no espao do
buffer anteriormente ocupado pela pgina 1. Consequentemente, o buffer ficar
preenchido com as pginas de 2 a 11 do arquivo lido (tabela empregado).
Agora, considere que ter incio a segunda execuo da varredura (scan)
sobre a tabela empregado. Nesse caso, qual a primeira pgina a ser requisitada
por essa operao de varredura (scan)? Como a operao de varredura uma
operao sequencial, a primeira pgina requisitada ser a pgina 1 (do arquivo
que contm as tuplas da tabela empregado). Porm, a pgina 1 no est no
44 UNIDADE 1
buffer. Logo, uma das pginas presentes no buffer deve ser selecionada para sair
do buffer, liberando espao para que a pgina 1 possa ser copiada para o buffer.
Que pgina ser escolhida para deixar o buffer? Segundo o algoritmo LRU, a
pgina menos recentemente utilizada. Ora, no buffer esto as pginas de 2 a 11
do arquivo lido (tabela empregado). A pgina menos recentemente utilizada a
pgina 2. Logo, a pgina 2 ser escolhida para deixar o buffer. Em seu lugar ser
carregada uma cpia da pgina 1. Nesse instante esto no buffer as pginas: 1,
3, 4, 5, 6, 7, 8, 9, 10 e 11. Qual prxima pgina a ser requisitada pela operao
de varredura? A prxima pgina requisitada ser a pgina 2. Porm, a pgina
2 no se encontra no buffer. Qual a pgina que ser escolhida para deixar o
buffer pelo algoritmo LRU? A pgina 3. Qual a prxima pgina a requisitada
pela operao de varredura? A pgina 3. Observe que esse comportamento se
mantm at a leitura da ltima pgina (pgina 11) pela operao de varredura.
Portanto, nesse exemplo, todas as execues da operao de varredura iro
apresentar uma taxa de acerto de 0%.
Assim, usando LRU, todas as operaes de scan (sobre o arquivo) tero
que ler todas as pginas do arquivo do disco e levar para o buffer pool (operao
de I/O). Nessa situao, chamada sequential flooding, LRU a pior estratgia
para substituio de pginas.
Podemos observar, para esse exemplo, que uma vez que uma tupla
de empregado tenha sido processada, a tupla no ser necessria novamente.
Portanto, uma vez que o processamento de um bloco inteiro de tuplas de
empregado seja completado, esse 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 empregado assim que a ltima tupla
tenha sido processada. Essa estratgia de gerenciamento de buffer chamada
de arremesso imediato.
Agora considere o algoritmo de juno Nested Loop Join. Cada bloco
de tuplas de empregado precisa ser lido uma vez para cada tupla da relao
departamento. Assim, quando o processamento de um bloco de tuplas de
empregado concludo, esse no ser mais necessrio at o processamento
da prxima tupla de departamento, antes disso todos os demais blocos de
empregado devero ser lidos novamente. Entretanto, como esse bloco foi usado
recentemente ele ainda permanecer no buffer por certo perodo de tempo, o
que inteiramente desnecessrio.

Na verdade, a estratgia tima (melhor alternativa) para a substituio
de pginas nesse exemplo a MRU.
Nesse caso, o sistema deve fixar um bloco do arquivo contendo as
tuplas da relao empregado sendo correntemente processado. Assim que a
ltima tupla desse 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, esse mecanismo se aplica aos blocos da relao
departamento. Surpreendentemente, a estratgia mais utilizada em sistemas de
banco de dados a LRU.
A poltica FIFO tambm possui situaes nas quais no proporciona
bons resultados. Considere um determinado bloco r usado repetidamente, por
exemplo, o bloco raiz de um ndice i de uma rvore B+. Assuma que uma busca
na rvore esteja sendo realizada. O primeiro bloco da rvore a ser lido ser a
raiz da rvore, bloco r. Assuma agora, que ao percorrer a rvore, os blocos que
representam os ns da rvore que foram lidos so transferidos para o buffer.
Assuma tambm que durante essa operao o buffer seja completamente
ocupado (cheio). Considere agora que necessrio ler mais um n da rvore, ou
seja, o bloco que representa esse n da rvore precisa ser copiado do disco para
o buffer. Nesse caso, um dos blocos presentes no buffer dever ser escolhido
para deixar o buffer. Que bloco ser selecionado para deixar o buffer? Segundo
o algoritmo FIFO, o primeiro a ser carregado. Nesse caso, a raiz da rvore, bloco
r.
Entretanto, estruturas de ndices so usadas com bastante frequncia.
Considere que uma nova busca precise ser realizada sobre a estrutura de ndices
i. Nesse caso, qual a primeira pgina (bloco) do ndice i (rvore B+) a ser lida?
A raiz da rvore, bloco r. Porm, o bloco r no se encontra mais no buffer, e sim
em disco. Logo, o bloco r dever ser novamente copiado do disco para o buffer.
Uma soluo para esse problema fixar a raiz, ou seja, indicar que o
bloco r no pode ser removido do buffer. Esses blocos so ditos fixados. Essa
soluo comumente aplicada para blocos que se constituem em hot spots, ou
seja, blocos acessados frequentemente.
A estratgia ideal de substituio de pginas em bancos de dados
requer o conhecimento das operaes de banco de dados em processamento.
Na prtica, no se conhece uma nica estratgia que manipule bem todos os
possveis cenrios. De fato, um grande nmero de SGBDs utiliza o LRU, apesar
das situaes em que essa estratgia no proporciona bons resultados.
46 UNIDADE 1
Vale destacar que a estratgia utilizada por um gerenciador de buffer
para a substituio de blocos influenciada por outros fatores alm do tempo no
qual o bloco foi carregado para o buffer (como no caso do FIFO) ou referenciado
(como no caso do LRU e MRU). 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 essas informaes para alterar sua estratgia
de substituio de blocos. Especificamente, os blocos necessrios para as
solicitaes ativas (no atrasadas) podem ser retidos no buffer, enquanto os
blocos relacionados s solicitaes atrasadas podem ser bons candidatos para
deixar o buffer.
O subsistema de recuperao de falhas tambm impe restries
rigorosas substituio de blocos. Se um determinado bloco b tiver sido
modificado (alterado), o gerenciador de buffer no tem permisso de escrever
de volta no disco a nova verso do bloco b (presente no buffer), uma vez que
isso destruiria a verso antiga do bloco b (armazenada em disco). Em vez disso,
o gerenciador de buffer deve obter permisso do subsistema de recuperao
de falhas antes de escrever o bloco b de volta no disco. O subsistema de
recuperao de falhas pode exigir (para garantir a consistncia dos dados) que
determinados blocos (por exemplo, os blocos x e y) tenham que sair do buffer
antes da sada do bloco b. Assim, o subsistema de recuperao de falhas s
dar a permisso para que o bloco b saia do buffer aps a sada dos blocos x e y.
O gerenciador de buffer, alm de utilizar os conhecimentos acerca
da solicitao que est sendo processada, pode utilizar tambm informaes
estatsticas relativas probabilidade de acesso a determinadas pginas
(blocos). O dicionrio de dados, por exemplo, uma das partes do sistema de
banco de dados mais frequentemente acessadas. Logo, o gerenciador de buffer
no deveria tentar remover blocos do dicionrio de dados do buffer (ou seja,
da memria principal) a no ser que outros fatores determinem que isso seja
feito. De forma similar, como as estruturas de ndice podem ser acessadas mais
frequentemente que as prprias pginas de dados (blocos que armazenam as
tuplas das relaes), o gerenciador de buffer, em geral, no deveria remover os
blocos de ndices da memria principal (buffer), a menos que no hajam outras
alternativas.

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 esse valor est prximo
ou no do valor ideal. Justifique sua resposta.
48 UNIDADE 1
UNIDADE 2
Processamento de
Transaes
Resumindo
Esta unidade discute em detalhes o problema do processamento de transaes em
bancos de dados. Define, precisamente, os conceitos do modelo convencional de
transaes. Discute e examina noes de transao e schedules. O critrio de corretude
convencional, denominado de serializabilidade, descrito. Vantagens e desvantagens
desse modelo so apontadas e discutidas. Aborda tambm a relao entre corretude e
confiabilidade de schedules.
PROCESSAMENTO DE TRANSAES
1. INTRODUO
Aps o acompanhamento desta 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

SGBDs so sistemas multiusurios. Dessa forma, a informao contida
nele pode ser acessada e modificada de maneira concorrente. Essa situao pode
levar o banco de dados a um estado inconsistente (por exemplo, redundncia
de dados).
Para que possamos entender melhor essa 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 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 voos.
dessa 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 multiusurio considera que operaes
de um programa podem ser executadas entre duas operaes de outro programa.
Como vimos, essas operaes causam transies de estado no BD e caso essas
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. Essas transies so realizadas pelos programas aplicativos que contm
operaes de leitura e de 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, nesse instante o programa 1 ainda
no alterou o valor do saldo da conta 13. Dessa 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.
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.
52 UNIDADE 2
Programa-1 Programa-2
Select saldo into: valor1
From t_conta
where num_conta = 12
Select saldo into: valor2

From t_conta
valor1 = valor1 + 500
update t_conta
set saldo = :valor1
Valor2 = valor2 +300 Select saldo into :valor1
From t_conta
Select saldo into :valor2

From t_conta
update t_conta
set saldo = :valor2
where num_conta = 13 Tempo
Display (Valor1, Valor2)
inconsistente retrieval
Figura 2. Transies Incorretas
Esse um problema comum em SGBDs. No decorrer desse captulo,
veremos mais exemplos como esse, bem como a forma existente para trat-lo.
Para entender o conceito de concorrncia em banco de dados, faz-se
necessrio entender, primeiramente, o conceito de transao.
1.2 Conceito de transao
Transao pode ser entendida como uma abstrao que representa a

sequncia de operaes de bancos de dados resultantes da execuo de um
programa. 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
essa transao, apenas os acessos ao Banco de Dados sero contabilizados.

Programa-1
From t_conta
update t_conta
set saldo = :valor1
Figura 3. Cdigo de uma transao
Dessa 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, nesse 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 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.
Esse conjunto de operaes compreendidos dentro da transao

considerado uma unidade lgica de trabalho, desde que possua um conjunto
de propriedades conhecido pelo acrnimo de ACID, descrito mais frente neste
captulo.
54 UNIDADE 2
1.3 Estados de uma transao
Uma transao possui diferentes estados, conforme mostra a Figura 4.
Figura 4. Estados de uma transao

Ativa
Estado inicial de toda transao selecionada para execuo;
Enquanto ativa, uma transao executa uma ou mais operaes
leitura e escrita.
Em processo de efetivao
Entra nesse estado aps executar sua ltima operao (solicitao
de COMMIT);
Nesse 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.
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 feitas, dados manipulados, buffers utilizados;
Se a transao no concluiu com sucesso, ela pode ser
reiniciada automaticamente.
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), essencial que sejam
respeitadas as propriedades de ACID (Atomicidade, Consistncia, Isolamento,
Durabilidade), 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 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
56 UNIDADE 2
efetuada)
A atomicidade garante que todas as operaes sero efetuadas
ou nenhuma delas ser. Para essa suposta falha, a operao de
retirada desfeita retornando o saldo da conta X para R$ 1.000
Consistncia
Se os dados estiverem consistentes antes da transao, elas
devem permanecer 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
Quando uma transao executou com sucesso, preciso garantir
que nenhuma falha resulte na perda dos dados j armazenados.
Exerccios
1. Conceitue transao em um banco de dados?
2. Quais os estados de uma transao?
3. Defina as propriedades ACID.
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 esse problema o banco
de dados possui diferentes mecanismos, possibilitando ao desenvolvedor a
escolha da melhor forma para a aplicao tratar acessos concorrentes mesma
informao.

Programa-1 Programa-2
Select saldo into :valor
From tab_conta
Select saldo into :valor
valor = valor +500 From tab_conta
update tab_conta valor = valor 100

set saldo = :valor
update tab_conta
set saldo = :valor
Saldo inicial (conta 12) = 400 Saldo final correto = 800
Saldo produzido no BD = 300 Tempo
Figura 5. Perda de atualizao
Na Figura 5 apresentado um erro provocado pelo acesso concorrente
ao banco de dados, a perda de atualizao ou lost update. Esse problema
ocorre com bastante frequncia e se no for tratado devidamente pode trazer
srios problemas de inconsistncia para os dados. Nesse caso, ocorreu 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 inicial 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 das transaes executadas concorrentemente. Permite que vrios
usurios acessem simultaneamente os dados compartilhados. Esses usurios
entram em concorrncia quando tentam acessar os mesmos dados ao mesmo
tempo.
Porque fazer o controle de concorrncia:
Melhor vazo (throughput) e utilizao dos recursos
58 UNIDADE 2
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 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 sequncia 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
(Figura 6).
Soluo ineficiente!!!
Vrias transaes podem esperar muito tempo para serem
executadas.
A CPU pode ficar muito tempo ociosa.
Enquanto uma transao faz I/O, por exemplo, outras
transaes poderiam ser executadas.
T1 T2
read (X)
X = X - 20
write (X)
execuo read (Y)
serial Y = Y + 20
write (Y)
read (Y)
X = X + 10
write (X)
Figura 6. Escalonador serializvel

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.
T1 T2
read (X)
X = X - 20
write (X)
execuo
read (X)
no-serial
X = X + 10
ou concorrente
write (X)
read (Y)
Y = Y + 20
write (Y)
Figura 7. Escalonador no serializvel
O objetivo da capacidade de serializao de encontrar escalonadores

no seriais que permitam uma execuo concorrente, sem interferir uma
transao na outra e consequentemente, sem gerar um estado inconsistente.
Execuo concorrente de transaes implica em um entrelaamento
das operaes dessas transaes. Sendo assim, uma execuo correta das
transaes depende do entrelaamento correto de suas operaes (Figura 6).
Figura 8. 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)
60 UNIDADE 2
Uma transao Ty grava em um dado atualizado por uma transao Tx
T1 T2
read (X)
X = X - 20
read (Z)
X = Z + 10
write (X)
read (Y)
write (X) a atualizao de X
Y = Y + 30 por T1 foi perdida!
write (Y)
Figura 7. Escalonador no serializvel
leitura suja (dirty-read)
TX atualiza um dado X, outras transaes posteriormente leem X, e
depois TX falha (Figura 8).
T1 T2
read (X)
X = X - 20
write (X)
read (X) T2 leu um valor
X = X + 10 de X que no ser
write (X) mais vlido!
read (Y)
abort (Y)
Figura 8. Exemplo leitura suja
Exerccios
1. O que uma transao?

Uma sequncia de aes que so consideradas uma unidade atmica
(indivisvel) de trabalho.
2. O que conflito entre transaes?

O conflito entre transaes ocorre quando mais de uma transao tenta
acessar o mesmo item de dado.
3. O que mecanismo de controle de concorrncia?

um mecanismo que garante a consistncia e o isolamento dos dados,
dada a atomicidade das transaes.

4. Por que estudar mecanismos de controle de concorrncia?
Trabalhamos em ambientes multitarefas;
necessrio compartilhar dados;
necessrio manter a consistncia dos dados.
3. ISOLAMENTO DE TRANSAES
3.1 Transaes Sequenciais

Conforme vimos anteriormente, transaes executadas de forma
sequencial uma seguida da outra so ditas transaes corretas. Entretanto,
a execuo de schedules seriais limita o acesso concorrente aos dados e, por
consequncia, 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, que temos:
Premissa
- A execuo de uma transao correta, se executada
isoladamente. Pois, produz sempre um estado consistente.
Teorema
- Toda execuo serial de transaes correta
S=T1 T2 T3 ... Tn-1 Tn
Este o padro (conceito bsico) para corretude de schedules!!!
A Figura 9 apresenta o exemplo da execuo serial de transaes.
Primeiramente executada toda a transao T1 e s depois executada a
transao T2.
62 UNIDADE 2
T1 T2
From t_conta

From t_conta
update t_conta
set saldo = :valor1
Valor2 = valor2 +300
update t_conta
set saldo = :valor2
From t_conta

From t_conta
Figura 9 Execuo serial das transaes T1 e T2

Como vimos, apesar de correto esse mtodo no o desejvel para um
ambiente multiusurio. Precisamos de um critrio de corretude (ou correo) que
garanta mais paralelismo. Nesse 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 dessas transaes.
Logo:
Seja um schedule S
- 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 10).

entrada: T1 T2 entrada: T1 T2
X = 50 read (X) X = 50 read (X)
Y = 40 X = X - 20 Y = 40 X = X - 20
write (X) write (X)
execuo execuo
read (Y) read (X)
serial no-serial
Y = Y+ 20 serializvel X = X + 10
write (Y) write (X)
read (X) read (Y)
sada: sada:
X = X + 10 Y = Y+ 20
X = 40 X = 40
Y = 60 write (X) Y = 60 write (Y)
Figura 10 Execuo serial e concorrente das transaes T1 e T2.
Logo, escalonamento serializvel equivalente execuo serial das
mesmas transaes.
Dessa 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 .
Dessa 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 de 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 de escrita uma
transao Ti dever conter aps todas as operaes de leitura e de escrita uma
operao commit (ci) ou abort (ai), mas no ambas.
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).
64 UNIDADE 2
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 de escrita.
Para entendermos o prximo tipo de equivalncia (equivalncia em
conflito), precisamos entender primeiro o conceito de operaes em conflito.
o Operaes em conflito (conflitantes): Duas operaes esto em
conflito se e somente se:
1. So operaes de transaes distintas
2. So executadas sobre um mesmo objeto e
3. Pelo menos uma das duas operaes uma operao de
escrita (write)
Considere o exemplo mostrado a seguir.
T1=r1(x)w1(x)
T2=r2(x)w2(y)
S= r2(x)r1(x)w2(y)w1(x)
OBS: Observe que as operaes r2(x) e w1(x) esto em conflito, uma vez que
pertencem a transaes diferentes (a primeira operao, r2(x), pertence
transao T2, enquanto a segunda operao, w1(x), pertence
transao T1; as duas operaes atuam sobre o mesmo objeto (objeto
ou item x) e pelo menos uma das operaes uma operao de escrita
(no caso desse exemplo, a segunda operao uma operao de
escrita).

3.2.3 Equivalncia de conflito
o Dois Schedules S e S, definidos sobre um conjunto de transaes

={T1, T2, ..., Tn}, so equivalentes de conflito ou por conflito (S C
S) se, e somente se,
(i) S e S tm as mesmas operaes pertencentes s transaes
de e
(ii) S e S ordenam (sequenciam) as operaes em conflito da
mesma forma (ou seja, dada duas operaes que estejam em
conflito no Schedule S essas operaes devem aparecer na mesma
ordem no Schedule S. Assim:
Para qualquer duas operaes em conflito pi OP(Ti) e qj
OP(Tj), com ij, se pi <S qj, ento pi <S qj
Considere o exemplo mostrado a seguir:
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)
Observe que:
Operaes em conflito do Operaes em conflito do

Schedule S Schedule S
r1(x) <S w2(x) r1(x) <S w2(x)

w1(y) <S r2(y) w1(y) <S r2(y)
Analisando as operaes em conflito dos dois Schedules, verificamos

que os dois schedules so equivalentes em conflito.
3.3 Serializabilidade
As trs diferentes noes de equivalncia de Schedules estudadas

anteriormente (equivalncia por estado final, por viso e por conflito) implicam
(do origem) a trs diferentes noes de corretude (correo) de Schedules
(Figura 10), as quais so detalhadas a seguir.
Serializabilidade por estado final (FSR)
Um schedule S serializvel por estado final, se ele equivalente
de estado final a algum Schedule serial.
Serializabilidade por viso (VSR)
Um schedule S serializvel por viso, se ele equivalente de
viso a algum Schedule serial.
66 UNIDADE 2
Serializabilidade por conflito (CSR)
Um schedule S serializvel por conflito, se ele equivalente de
conflito a algum Schedule serial.
Os trs critrios de corretude podem ser utilizados para produzir
Schedules corretos. Ento, surge uma pergunta: Qual critrio a adotar?
Vale destacar que os trs critrios de corretude apresentam
diferentes graus de paralelismo, uma vez que permitem
diferentes nveis de entrelaamento.
Para ilustrar, considere o seguinte exemplo:
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)
- Observe que S1 produz o mesmo estado final que

SS, ento S1 serializvel por estado final. Logo, S1
correto.
- Porm, note que S1 no serializvel por viso
(uma vez que o valor lido por r1(x) diferente nos dois
schedules) e nem por conflito.
Assim, os trs critrios de corretude relacionam-se da seguinte forma:
FSR VSR CSR
Figura 10 Equivalncia de schedules
Alm disso, os trs critrios de corretude apresentam diferentes graus

de complexidade. Dessa forma, os critrios de corretude (correo) FSR
e VSR podem ser classificados como um problema NP completo, tendo
no pior caso complexidade assinttica de n!, onde n o nmero de
transaes.

Por outro lado, identificar se um schedule CSR poder ser realizado em
tempo polinomial. Por esse motivo, o critrio comumente adotado pelos
SGBDs o da serializabilidade por conflito.
Agora, podemos definir mais formalmente a serializabilidade por conflito:
Serializabilidade por conflito
S serializvel por conflito, se S equivalente por conflito a algum
schedule serial SS sobre o mesmo conjunto de transaes
Para ilustrar a serializabilidade por conflito, considere o exemplo a seguir:

Exemplo:
T1=r1(y)r1(x)w1(y) T2=r2(x)r2(y)w2(x)
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) Schedule original

SS=r3(y)r3(x)w3(z)r1(y)r1(x)w1(y)r2(x)r2(y)w2(x) Schedule serial (T3,T1,T2)
Operaes em conflito do Operaes em conflito do

Schedule S Schedule SS
r3(y) <S w1(y) r3(y) <S w1(y)
r1(x) <S w2(x) r3(x) <S w2(x)
w1(y) <S r2(y) r1(x) <S w2(x)
r3(x) <S w2(x) w1(y) <S r2(y)
Figura 11 Serializabilidade por conflito
Como verificamos (Figura 11) por meio da forma como os dois Schedules
ordenam suas operaes em conflito, podemos dizer que o Schedule S
serializvel por conflito. Essa uma das formas de verificao da serializabilidade
por conflito de um Schedule.
Porm, essa no a nica forma. Podemos verificar se um Schedule
serializvel por conflito por meio do seu Grafo de Serializao, onde no
precisamos comparar um dado Schedule com outro schedule serial.
3.4 Grafo de serializao de um schedule S
Considere que S um schedule definido para um conjunto de

transaes ={T1, T2, ..., Tn}
Assuma que SG(S) representa o grafo de serializao para o
schedule S. Como todo grafo, SG(S) pode ser definido como um
conjunto de vrtices (V) e arestas (E)
68 UNIDADE 2
Assim, SG(S)=(V,E) tal que:

- SG(S) um 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). Um exemplo desse grafo pode ser
observada na Figura 12.
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 (Transaes): T1, T2, T3
r3(y) < w1(y) aresta de 3 para 1
Arestas (operaes em r1(x) < w2(x) aresta de 1 para 2

conflito): w1(y) < r2(y) aresta de 1 para 2
r3(x) < w2(x) aresta de 3 para 2
Figura 12 Grafo de serializao
Teorema
Um schedule S serializvel por conflito o grafo de serializao
de S no contm ciclos
- Para verificar existncia de ciclos em grafos existem
algoritmos que podem ser executados em tempo polinomial,
ou seja, cuja complexidade assinttica 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)
Propriedade P de Schedule fechada por prefixo

Se P vlida para o Schedule completo S, P tambm vlida para
qualquer prefixo de S
Esse conceito, na verdade, mostra que a Serializabilidade por conflito

uma propriedade fechada por prefixo:
Se algum prefixo no serializvel por conflito, o schedule completo

tambm no ser! Schedule incorreto.
Dessa 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.
Exerccios
1. Verifique se o seguinte Schedule serializvel 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 serializvel 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)
4. Prove que se dois Schedules so equivalentes, ento seus grafos de

serializao so iguais. Prove tambm que o inverso no verdade.
70 UNIDADE 2
5. Suponha duas transaesT1eT2:
BEGIN TRANSACTION T1
UPDATEBanco
SETSaldo= ((SELECTSaldoFROMBancoWHEREConta= 10)
100)
WHERE Conta = 10
UPDATE Banco
SETSaldo= ((SELECTSaldoFROMBancoWHEREConta= 20) +
100)
WHEREConta= 20
COMMIT TRANSACTION T1

BEGIN TRANSACTION T2
UPDATEBanco
SETSaldo= ((SELECTSaldoFROMBancoWHEREConta= 20)
200)
WHERE Conta = 20
UPDATE Banco
SETSaldo= ((SELECTSaldoFROMBancoWHEREConta= 30) +
200)
WHEREConta= 30
COMMIT TRANSACTION T2
a) As instrues de leitura e de escrita dos dados da transaoT1, obtidas a

partir da SQL, so as seguintes:
READ Conta 10
WRITE Conta 10
READ Conta 20
WRITE Conta 20
Seguindo o exemplo acima, obtenha as instrues de leitura e de escrita dos
dados da transaoT2.
b) Determine as possveis escalas de execuo concorrenteserializveisem

conflitoe/ouem viso.

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 essa 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 vice-versa. Contudo, do ponto de vista
prtico os schedules devem ser corretos (serializveis) e confiveis. Vejamos o
exemplo da Figura 13:
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
Figura 13 Exemplo de escalonamento
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
72 UNIDADE 2
transao pode ser abortada aps ter realizado Commit)
Execuo de S correta (serializvel), porm
o 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), a operao commit da transao Ti precede a operao
de commit da transao Tj, isto , ci <S cj.
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. Esse fenmeno chamado de abort
em cascata. A fim de evitar a ocorrncia desses 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)
Nesse caso, o abort de T1 fora o abort de T2.

Exemplo 2:
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
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 esse 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. Esse 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. Essa 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 se deve 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)
Exemplo 2:
S4= w1(x,2)c1w2(x,5)c2
- Se wi(x) <S opj(x) ci<S opj(x) ou ai<S opj(x), onde opj {rj, wj}
- S4 preciso
E como funcionam os DBMSs existentes?
Os atuais DBMSs produzem schedules:

Corretos Serializveis por conflito
Confiveis Precisos (grau de confiabilidade)
74 UNIDADE 2
Exerccios
1. Classifique os schedules abaixo de acordo com as seguintes classes de

Schedules: serializveis por conflito, recuperveis, que evitam aborts em
cascata, e estritos (strict).
a) r1(x) r2(y) r3(x) w3(x) r2(x) r1(y) w1(x) c1 c2 c3
b) r1(x) r1(y) w1(x) r2(y) w3(y) w1(x) r2(y) c1 c2 c3
c) 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
d) 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.

UNIDADE 3
Controle de Concorrncia
Resumindo
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 desses protocolos tambm apresentada e discutida.
Controle de Concorrncia
1. INTRODUO
1.1 Conceitos Iniciais

Os modelos de processamento de transaes so implementados atravs
dos protocolos de controle de concorrncia. Esses 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 sequncia corretamente entrelaada dessas 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 como
agressivos ou conservativos (ou conservadores). Um protocolo agressivo tenta
escalonar as operaes imediatamente. Dessa forma, um protocolo agressivo
evita adiar a execuo das operaes de uma transao. Entretanto, essa
estratgia pode levar a situaes onde no possvel produzir uma execuo
correta de todas as transaes ativas. Nesse caso, um protocolo agressivo
rejeita operaes de uma ou mais transaes, levando essas transaes ao
estado aborted. Assim, os protocolos agressivos podem gerar taxas 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 essa 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 essa classe de protocolos so
os certificadores.
Por sua vez, um protocolo conservativo tende a adiar a execuo de
determinadas operaes com a finalidade de escalon-las corretamente. Dessa
forma, esses protocolos, apesar de no induzir o abort de transaes, podem
levar as aplicaes a tempos de espera inaceitveis, principalmente se essas
forem transaes de longa durao A Figura 1.1 mostra uma viso geral dessa
classificao.
Fn
Figura 1.1 Classificao dos Protocolos de Controle de Concorrncia
Exerccios
1. Quais as principais caractersticas de um protocolo agressivo?

2. Quais as principais caractersticas de um protocolo conservativo?
3. Quais as principais caractersticas de um protocolo otimista?
4. Quais as principais caractersticas de um protocolo pessimista?
80 UNIDADE 3
2. DESCRIO DOS PROTOCOLOS CONSERVADORES
Este captulo discute os protocolos baseados em bloqueios, os quais
so utilizados no controle de concorrncia em SGBDs relacionais. Inicialmente
os problemas de gerncia de bloqueios e de tratamento de impasses (deadlocks)
so abordados. Em seguida, um mtodo que utiliza o conceito de bloqueio
para assegurar a gerao de schedules (execues) serializveis, denominado
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
esse 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. Dessa forma, o scheduler garante que somente uma transao pode
acessar um determinado item de dado por vez.
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, esse
item de dado ainda no pode ser acessado por nenhuma transao, uma vez que
para acessar um determinado item de dado uma transao precisa inicialmente
obter um bloqueio sobre esse item.
Nesse 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. Essa 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 ideia 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,
por meio 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.
ii) caso contrrio, acrescente Ti ao final da fila de espera para x na tripla
encontrada.
Passo 3: Ao receber solicitao da transao Ti por meio da operao 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 esse 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:
82 UNIDADE 3
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:
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 essa 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 consequentemente r2(x), no pode ser
executada at que a transao T1 libere o bloqueio obtido sobre o item x atravs
da operao u1(x).
Nesse 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).
T1 T2
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 esse 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.
T1 T2
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, a qual indica quando
duas transaes pode 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, anteriormente definidas,
simples. Duas ou mais transaes podero ler o item x 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, essa
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 operaes de uma mesma transao.
Assim, se uma transao Ti 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.
Nesse 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;
84 UNIDADE 3
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.
Agora, o protocolo de bloqueio bsico, utilizando bloqueios de leitura e
de 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,
por meio 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. Nesse 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:
1) em caso afirmativo, bloqueie x para Ti, no modo requisitado,
atualizando a tupla (x, modo, T, F) tabela, ou seja, insira
Ti em T.
2) 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 por meio da operao 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.
- 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 esse 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
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
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 que essa 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.
T1 T2
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
86 UNIDADE 3
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

T1 T2
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
Figura 2.5 Execuo Concorrente S1 (Exemplo 3).

Esse 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.
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
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

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, consequentemente, 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 esse apresenta um ciclo, o que indica
que a execuo S1 no serializvel por conflito. Logo, nesse caso, o protocolo
de bloqueio bsico considerou correta uma execuo incorreta (ou seja, que
no serializvel por conflito). Esse 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 esse protocolo podem
apresentar os fenmenos leitura suja e perda de atualizao.
Figura 2.6 Grafo de Serializao do Schedule S1 no Exemplo 4.
88 UNIDADE 3
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).
T3 T4
rl1(B)
r1(B)
wl1(B)
w1(B, B-50)
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)), esse 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)), esse 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. Nesse momento, chega-se a uma situao de impasse (deadlock), ou seja,
nenhuma das duas transaes prossegue sua execuo. A transao T4 est
esperando pela transao T3 e a transao T3 est esperando pela transao T4.
Para solucionar alguns desses problemas, surgiu a ideia 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 nessa 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.

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
90 UNIDADE 3
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 essa 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. Essa 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
Observe que essa 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, essas 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. Dessa 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.
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, essa 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. Consequentemente, 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.
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
92 UNIDADE 3
de commit ou abort.
Figura 2.7 Fases do protocolo 2PL Preciso.
A grande vantagem do protocolo 2PL Preciso que esse gera execues

serializveis e confiveis (estritas). Contudo, esse 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
Observe que esse schedule no seria gerado pelo protocolo 2PL Preciso,
pois a operao u1(x) s poderia ser realizada aps o commit ou abort de T1.
Consequentemente, 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

Esse 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

desse 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

Nesse 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.
Nesse caso, a transao deve esperar e tentar novamente em um momento
futuro.
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 desse 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.
94 UNIDADE 3
2.2 Tratamento de Impasse (deadlock)
O 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 esse 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).
Nesse sentido, duas abordagens so possveis:
Deteco e Resoluo: Essa 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.
Preveno: Essa abordagem utiliza tcnicas que asseguram
que uma situao de impasse (deadlock) nunca ir ocorrer.
2.2.1 Deteco e Resoluo
1. Deteco por Timeout

Nessa 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.
Uma vez que o escalonar supe que uma transao Ti esteja envolvida
em uma situao de impasse, ele precisa solucionar (resolver) essa situao. A
soluo consiste em abortar a transao Ti.
Essa estratgia apresenta dois problemas principais:
Pode ser que a transao Ti no estivesse envolvida em um
deadlock;
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)

Nessa 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,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.
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

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. Nesse 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, essa 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, consequentemente, ser
abortada.
Figura 2.9 Grafo Wait-For para o Schedule S1 no Exemplo 7.
96 UNIDADE 3
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 ideia bsica
dessa 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 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
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, nesse 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 essa estratgia evita a formao de deadlocks.
Contudo, reduz substancialmente o grau de concorrncia.
1. Soluo por Timestamp

A ideia dessa abordagem para evitar a formao de deadlocks baseia-
se na utilizao de marcadores de tempo (timestamps). A seguir descreveremos
mais detalhadamente essa 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. Dessa forma:
Se Ti inicia sua execuo antes de Tj ento:
- ts(Ti) < ts(Tj)
Ou seja, nesse caso, Ti uma transao mais antiga que Tj.
Quando uma transao Ti solicitar um bloqueio sobre um item de dado j
bloqueado por Tj, duas estratgias so possveis:
2.2.2.1 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
Nessa 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 canceladas. Assim, medida que uma transao
fica mais antiga, ela tende a esperar pelas transaes mais jovens.
2.2.2.2 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
Nessa estratgia, as transaes mais recentes podem esperar por uma

transao mais antiga. J as transaes mais antigas no esperam por uma
transao mais nova, nesse caso, as transaes mais antigas provocam o abort
das transaes mais jovens.
Vale destacar que nas duas estratgias sempre a transao mais
recente escolhida como vtima. Assim, as transaes mais antigas so
98 UNIDADE 3
priorizadas. Essa 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, essa 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 essa situao consiste em ao reiniciar uma transao
Tj no reiniciar o seu timestamp (ts(Tj)), ou seja, manter um nico timestamp
para cada transao. Dessa 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

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
Vamos assumir que:
ts(T1) = 1
ts(T2) = 2
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 ...
Nesse exemplo, vale destacar que quando uma transao T1 solicita um
bloqueio de escrita sobre o item de dado x (wl1(x)), esse j est bloqueado por T2
(rl2(x)) em um modo incompatvel. Nesse 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)), esse j est bloqueado por T1 (rl1(x)) em um modo incompatvel.
Nesse 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.
Nesse caso, quando uma transao T1 solicita um bloqueio de escrita
sobre o item de dado x (wl1(x)), esse j est bloqueado por T2 (rl2(x)) em um
modo incompatvel. Nesse caso, teremos:
ts(T1) < ts(T2)
Logo, a transao T2 ser cancela (abortada) e o 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.
Dessa 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. Nesse 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, desse modo, estaramos limitando a concorrncia.
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).
100 UNIDADE 3
Figura 2.11 Relacionamento entre as Diferentes Granularidades.
A ideia 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.

Figura 2.12 Estrutura do Banco de Dados.
A partir dessa ideia foi concebido o protocolo de bloqueio em duas
fases com granularidade mltipla. Nesse 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);
Dessa forma, uma nova tabela de compatibilidade de bloqueios necessita
ser definida (figura 2.13).
Figura 2.13 Tabela de Compatibilidade de Bloqueios.
102 UNIDADE 3
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:
1) Para impor um bloqueio de leitura ou escrita sobre um determinado

elemento (n) N (por exemplo, a relao R2.1), devemos comear pela
raiz da hierarquia (por exemplo, BD1).
2) Se estamos no elemento N que queremos bloquear (por exemplo, a
relao R2.1), no precisamos examinar mais nada. Solicitamos o
bloqueio desejado sobre esse elemento.
3) Se o elemento que desejamos bloquear estiver mais abaixo na
hierarquia, devemos inserir uma advertncia (inteno) no n corrente.
Isto , se estamos no n raiz, representado por BD1, e quisermos obter
um bloqueio compartilhado sobre um elemento que est mais abaixo na
hierarquia (por exemplo, R2.1), deve-se solicitar um bloqueio intencional
de leitura sobre o n BD1 e, se quisermos um bloqueio exclusivo sobre
R2.1, solicitaremos um bloqueio intencional de escrita sobre BD1. Quando
o bloqueio sobre o corrente (BD1) for concedido, prosseguiremos at
chegar ao elemento desejado, no nosso exemplo R2.1. Vale observar
que para que seja concedido um bloqueio compartilhado sobre o
elemento R2.1 ser necessrio obter bloqueios intencionais de leitura
sobre os ns BD1, A1 e F2.
A seguir discutimos alguns aspectos do protocolo:
Quando solicitamos um bloqueio intencional de leitura sobre um n N

(por exemplo, BD1), pretendemos ler um dos ns descendentes de N (ou
seja, abaixo de N na hierarquia), por exemplo R2.1. O nico momento
em que essa inteno de leitura (bloqueio intencional de leitura sobre
BD1) poderia criar um problema (de incompatibilidade de bloqueios)
se alguma outra transao j tivesse reivindicado o direito de gravar
uma nova cpia do elemento do BD1 inteiro, uma vez que um bloqueio
intencional de leitura s incompatvel com um bloqueio de escrita
sobre o mesmo elemento. Observe que, se alguma outra transao
tiver a inteno de gravar apenas um elemento secundrio na hierarquia
(por exemplo, R2.2), indicado por um bloqueio intencional de escrita em
BD1, ento poderemos ter condies de conceder o bloqueio intencional
de leitura em BD1 e permitir que o conflito seja resolvido em um 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 na hierarquia 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 que alguma outra
transao gravar pelo menos uma parte do elemento representado por
N. Portanto, no poderemos conceder o direito de ler N inteiro. Assim,
tanto bloqueios de escrita quanto bloqueios intencionais de escrita so
incompatveis com bloqueios de leitura.
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 (abaixo de N na hierarquia).
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.
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. A liberao de bloqueios comea de baixo para cima
na hierarquia.
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).
104 UNIDADE 3
Exemplo 9
Considere a tabela a seguir:
FILME (Ttulo, Ano, Durao, Produtora)
Agora, considere as seguintes transaes:

T1: T2:
SELECT * UPDATE Filme
FROM Filme SET Ano = 1939
WHERE Ttulo = Filme1; WHERE Ttulo = Filme2;
T1 irl
Filme
T2 iwl
Filme1 Filme1 Filme2

T1 rl T1 rl T2 wl
Figura 2.14 Exemplo de Bloqueio com Granularidade Mltipla.

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. Nesse 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 ideia 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
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

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
106 UNIDADE 3
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)
Fim Se
Fim Se
3. Quando o escalonador recebe uma operao de commit (cj)

Tenta converter (upgrade) todos os wlj em clj segundo a tabela de
compatibilidade
Se existe rlk(x), com 0 < K n e k j, ento:
Atrasar clj(x) at rlk(x) seja liberado por Tk
Fim Se
Comentrios
O protocolo 2V2PL produz escalonamentos (schedules) serializveis por
conflito e precisos, ou seja, histrias corretas e que evitam aborts em cascata.
Alm disso, esse 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 esses motivos, o protocolo 2V2PL ganhou enorme popularidade
e, atualmente, j implementado pelos principais SGBDs (Oracle, PostgreSQL,
SQLServer, dentre outros).
Exemplo 10

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)
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). 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, consequentemente, 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 nesse exemplo a operao de commit da transao
T1 chegou ao escalonador antes do commit da transao T2. Nesse 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). Nesse 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

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)
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, nesse 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
108 UNIDADE 3
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,
nesse caso rl2(x). Logo, a transao T1 ir esperar at que a transao T2 libere
o bloqueio rl2(x). Dessa forma, a situao de impasse (deadlock) est formada.
Logo, podemos concluir que o protocolo 2V2PL no est livre da ocorrncia de
deadlocks.
Exemplo 12

T1 = rl1(x) r1(x) wl1(x) w1(x) c1 u1(x)
T2 = rl2(x) r2(x) wl2(x) w2(x) c2 u2(x)
S1 = rl1(x) r1(x) rl2(x) r2(x) wl1(x) w1(x) wl2(y) w2(y) c1 c2
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)). Nesse 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.
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.
A interface de transaes o componente responsvel por gerar o
identificador (TRID) de cada transao.
O gerenciador de bloqueios (lock manager) tem objetivo de 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.

Figura 2.16 Arquitetura de um Gerenciador de Transaes.
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, 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
de desbloqueio (liberao), alm de gerenciar duas estruturas de dados:
- Arquivo de Bloqueios: Arquivo que contm as informaes
sobre os bloqueios. Cada entrada nesse 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 (alterao) 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
110 UNIDADE 3
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:
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)
Nesse 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.


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 essa 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 essa 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. Esses nveis so classificados de acordo com a possibilidade de
ocorrncia de determinados fenmenos indesejados, que podem ser dirty reads,
non-repeatable reads e phantons. A figura a seguir ilustra o relacionamento
entre os nveis de isolamento e os fenmenos.
112 UNIDADE 3
Non-Repeatable
Dirty Read Phantom
Read
Read Uncommitted Sim Sim Sim
Read Committed No Sim Sim
Repeatable Read No No Sim
Serializable No No No
Figura 2.17 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, essa 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, 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 Esse o primeiro e menos restritivo nvel de isolamento.
Nesse 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. Nesse 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 Esse nvel o usado por padro no Oracle, PostgreSQL
e SQL Server. Esse nvel evita a ocorrncia do fenmeno leitura suja (Dirty
Read). Porm, no evita os fenmenos leitura no repetvel (Non-Repeatable

Read) e fantasma (Phantom). Esse 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. Nesse
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

A seguir, exemplificamos algumas anomalias que podem ocorrer no nvel
de isolamento Read Commited:
- 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 Esse 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.
O nvel de isolamento Cursor Stability evita o fenmeno atualizao
perdida (lost update). Para ilustrar esse fato, considere o exemplo a seguir:
S3= r2(x) w1(x) c1 w2(x) r2(z) c2
114 UNIDADE 3
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 ocorrer aps a transao T2 executar sua
operao de escrita em x (ou seja, w2(x)).
Repeatable Read Esse 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.

Para ilustrar o funcionamento desse nvel de isolamento, considere

novamente o exemplo a seguir:
Select *
from Empregado
where salario>499
Commit
Nesse 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.

Nesse caso, se executarmos novamente a consulta:
Select *
from Empregado
where salario>499
iremos observar uma tupla fantasma (ou seja, que no existia antes):
(07,'Jos',4000,1).
Serializable Esse 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


2.6.2 Sintaxe SQL 99
A seguir ilustramos a sintaxe SQL utilizada para definir o nvel de isolamento a

ser utilizado.
Figura 2.18 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.
116 UNIDADE 3
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)?

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 X I
S verdadeiro falso falso
S falso falso falso
I falso falso verdadeiro
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 esse 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.
Soluo:
118 UNIDADE 3
2. Para cada uma das opes baixo modifique o schedule S a fim
de criar um novo schedule (completo) T tal que:
a) T evita aborts em cascata e no recupervel.

b) T recupervel.
c) 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.
Soluo:
a) T evita aborts em cascata e no recupervel.
Lembrando (Definies):
Recupervel: Se wi(x) < rj(x), ento ci < cj.

Evita abort em cascata: Se wi(x) < rj(x), ento ci < rj(x).
Vamos provar por contradio que no possvel criar o Schedule

pedido:
Suponha que T evita aborts em cascata. (1)

Suponha que T no recupervel. (2)
Por (1), se wi(x) < rj(x), ento ci < rj(x).
Suponha que wi(x) < rj(x). (3)
Por (1) e (3), ci < rj(x).
Consequentemente, ci < cj, pois, por definio, qualquer operao de

leitura ou escrita antecede seu commit.
Logo, T recupervel.
Chegamos, portanto, em uma contradio.
Podemos concluir que no possvel T evitar aborts em cascada e no

ser recupervel.
b) T recupervel.
r1(x) r1(y) w1(x) r2(y) w3(y) w1(x) r2(y) c1 c3 c2
c) T serializvel por conflito.

No possvel criar o Schedule T, pois o prefixo exposto na questo no

serializvel por conflito. Como o prefixo no serializvel por conflito, ento o
Schedule completo tambm no ser.
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, ou seja,

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.
Soluo:
Vamos refutar a assertiva dada por meio de um contraexemplo.
Dessa forma, vamos mostrar um exemplo de um schedule que seria

gerado pelo protocolo 2V2PL e que possui um deadlock.
O Schedule incompleto a seguir serve como prova de que a assertiva em

questo falsa:
wl1(y) w1(y) wl2(x) w2(x) wl1(x) wl2(y)
Como podemos observar, dado um bloqueio de escrita sobre y para T1.

Em seguida, concedido um bloqueio de escrita sobre x para T2. Logo
aps, T1 solicita um bloqueio sobre x e T2 sobre y. Ambas as transaes
so retardadas, causando, consequentemente, um deadlock.
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 T2= w2(u)r2(x)r2(y)w2(x)c2

T3=r3(y)r3(x)w3(u)w3(z)c3 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 O nvel de isolamento repeatable read sofre do fenmeno de fantasma
(phanton). Considere que o DBA de sua empresa definiu o nvel de
120 UNIDADE 3
isolamento repeatable read para todas as transaes. Construa um
schedule onde esse fenmeno pode ocorrer no nvel de isolamento
repeatable read. Justifique sua resposta.
21 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
22 Considere os seguintes grficos:
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).
23 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 serializveis por conflito sobre . Formalmente, 2PL CSR.
Construa um schedule serializvel por conflito S (S CSR), mas que no

possa ter sido produzido por um escalonador que implemente o protocolo
2PL (S 2PL).
24 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
25 O nvel de isolamento read committed sofre do fenmeno da atualizao

perdida (lost update). Considere que o DBA de 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 no banco de dados. Justifique sua resposta.

26. 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
d) Elabore um Schedule S que no possa ser produzido em um
SGBD que utiliza a estratgia wait-die para prevenir situaes de
27. 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.
122 UNIDADE 3
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 o schedule T como se pede, comente
brevemente.
28. 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 sublinhados 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
COMMIT TRAN proc1

SET TRANSACTION ISOLATION LEVEL
SERIALIZABLE
BEGIN TRAN proc2

UPDATE CANDIDATOS WITH (NOLOCK)

COMMIT TRAN proc2

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 desses 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.
2. Note que o comando SET TRANSACTION ISOLATION LEVEL seta
(ajusta) o nvel de isolamento.
29. 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:
124 UNIDADE 3
SET TRANSACTION ISOLATION LEVEL READ
UNCOMMITTED
BEGIN TRAN proc1

UPDATE CANDIDATOS
COMMIT TRAN proc1
SET TRANSACTION ISOLATION LEVEL

READ UNCOMMITTED
BEGIN TRAN proc2

UPDATE CANDIDATOS
COMMIT TRAN proc2
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 desses dois
procedimentos.
30. Para cada uma das opes abaixo crie um Schedule que satisfaa as
propriedades requisitadas:
a) No recupervel e no serializvel.
b) Serializvel e recupervel.
c) Preciso e serializvel.
d) No serializvel e que no evita aborts em cascata.

3. 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 esse
motivo eles bloqueiam essas transaes. Contudo em sistemas onde no h
grande acesso de escrita a objetos, essa abordagem acaba sendo prejudicial.
Nesse 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 sequenciais
(1,2,3...) e da composio Data+Hora. Por convenincia iremos utilizar o termo
timestamp de uma operao pi(x), embora esse 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:
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 essa 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, S serializvel por conflito.
Prova: Seja GS(S) o grafo de serializao para o schedule S. Se Ti Tj uma
aresta de GS(S), 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.
126 UNIDADE 3
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). Nesse protocolo, o scheduler escalona as operaes de
forma imediata, ou seja, na medida em que essas so recebidas do gerenciador
de transaes (first-come-first-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 esse j tenha executado uma operao qj(x), que conflita com pi(x),
com ts(Tj) > ts(Ti)$. Nesse 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;
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
T1 = r1(x) r1(y) w1(x) c1
T2 = r2(x) r2(y) c2
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 esse 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 esse ir verificar que j existe uma
operao, anteriormente escalonada, que conflita com w1(x), mais precisamente
r2(x). Nesse caso, o escalonador ir testar se Read_TS(x), que nesse momento
tem valor 2, maior que ts(T1), que estamos assumindo ter valor 1. Como o
resultado desse teste ser verdadeiro a transao T1 ser cancelada (abortada),
apesar do schedule S1 ser correto.
3.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 ideia bsica do protocolo consiste
em manter um grafo de serializao sempre acclico, uma vez que se esse grafo
128 UNIDADE 3
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 esse

protocolo:
Para cada nova transao Ti, Faa:
Incluir um n no grafo de serializao;

Fim Para;
Para cada operao pi(x) OP(Ti) recebida Faa:
Verificar se existe uma operao qj(x) OP(Tj) que

conflite com pi(x) e que j tenha sido enviada para
processamento;
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 nesse n;
Fim Se;
Fim Para;
Garbage Collection
Se o n correspondente a uma transao terminada Ti s possui arestas

saindo, ento o n pode ser removido do grafo
Porque??
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 esse 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, esse n jamais se envolver em um
ciclo, podendo ser retirado do grafo.

Exemplo 15
T1 = r1(x) r1(y) w1(x) c1
T2 = r2(x) r2(y) c2
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).
T1 T2
Exemplo 16
T1 = r1(x) w1(x) c1
T2 = r2(x) w2(x) c2
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
dessa 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 dessa 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.
130 UNIDADE 3
3.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. Essas 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 essa 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. Nesses protocolos, as transaes executam
em trs fases:
Leitura: Nessa fase a transao l os valores dos itens do banco de
dados que necessita e guarda uma cpia desses valores em uma
rea local, chamada workspace ou cache;
Validao: Nessa fase, o SGBD verifica se a transao pode
conflitar com alguma outra transao que est executando
concorrentemente. Caso exista esse 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 realizadas nos valores armazenados em sua cpia
(cache) local so persistidas (gravadas) no banco de dados.

Nesse protocolo, as atualizaes realizadas por uma determinada
transao Ti no so aplicadas diretamente aos itens do banco de dados at
que a transao Ti seja concluda (ou seja, execute sua operao de commit).
Durante a execuo de Ti, todas as atualizaes (alteraes) realizadas por Ti
so aplicadas em cpias locais dos itens de dados (cache). Ao final da execuo
de Ti, uma fase de validao iniciada. Durante essa fase, verificado se alguma
das atualizaes realizadas por Ti violou a serializao. Se a serializao no
for violada, a transao Ti efetivada, e o banco de dados atualizado com
as cpias locais de Ti. Caso contrrio, a transao Ti abortada e, mais tarde,
reiniciada. A ideia do protocolo fazer todas as verificaes de uma s vez.
Assim, a execuo de uma transao Ti 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
executada 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;
No sofrem do problema de deadlocks;
Em geral, apresentam altas taxas de abort;
No evitam aborts em cascata;
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.
132 UNIDADE 3
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;

UNIDADE 4
RECUPERAO DE
BANCO DE DADOS
Resumindo
Esta unidade discute em detalhes a recuperao de banco de dados. So discutidos e
detalhados os diversos tipos de falhas. A estrutura de log apresentada e a recuperao
baseada em log discutida. Noes de gerenciamento de buffer so apresentadas e
examinadas. Tcnicas de recuperao, incluindo os meios de armazenamentos so
apresentadas, destacando suas vantagens e desvantagens. Por fim, tcnicas baseadas
em pginas sombras so discutidas.
RECUPERAO DE BANCO DE
DADOS
1.1 Introduo
Um sistema de computador, como qualquer outro dispositivo eltrico ou
mecnico, est sujeito a falhas. Essa simples observao tem consequncias
de longo alcance para o projeto de sistemas de computadores em geral e de
Sistemas de 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 desses 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 dos dados em um disco
rgido externo e ocorre uma falha no disco principal. Nesse caso, o SGBD vai
tentar recuperar os dados do disco externo. Contudo, esse disco tambm pode
sofrer 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.
1.2 Tipos de Falhas

Existem diferentes tipos de falhas que podem afetar a consistncia de
um BD. A seguir detalhamos cada uma dessas falhas.
Falha de Transao
A falha de transao ocorre quando uma transao ativa termina
de forma anormal. As principais causas para esse tipo de falha so: violao
de uma restrio de integridade, lgica da transao mal definida, deadlock,
cancelamento pelo usurio, entre outras.
Esse 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
A falha de sistema ocorre quando o SGBD encerra a sua execuo de
forma anormal. As principais causas para esse tipo de falha so: interrupo de
energia, falha no sistema operacional erro interno no software do SGBD, falha
de hardware, entre outras.
Nesse 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).
Esse 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 esse tipo de falha esto
relacionadas ao disco: setores corrompidos no disco, falha no cabeote de
leitura/gravao, entre outras.
138 UNIDADE 4
Esse 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 catastrfica esto vrias situaes em que a mdia que contm
o BD completamente destruda. Os exemplos incluem 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).
1.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 sequencialmente as operaes
feitas por transaes no banco de dados. Esse 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 esses so usados para recuperao em
diversas situaes, de acordo com o tipo de falha ou problema. Os principais
tipos de log so:
log UNDO: esse log mantm apenas o valor antigo do dado (before
image).
log REDO: esse mantm apenas o valor atualizado do dado (after
image).
log UNDO/REDO: esse 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 dessas um
identificador nico. Os vrios tipos de registros de log so representados de
acordo com a Figura 1.
Figura 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.
Um exemplo de um log completo pode ser observado na Figura 2:
Figura 2 Representao do log.
140 UNIDADE 4
Nessa 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 excessivamente
grande. Existem meios seguros para apagar informaes do log ou para
compact-lo.
1.4 Gerenciamento de Buffer

O buffer um conjunto de blocos da memria principal. O uso do buffer
surge da necessidade de evitar acessos frequentes 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. Nesse 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 3
mostra um exemplo de buffers.
Figura 3 Exemplo de buffers.

Buffer do Log
Esse buffer agrupa um conjunto de registros de log. Esses 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.
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 dessa transao j devem
estar no arquivo.
Uma transao s considerada efetivada quando todos os registros de
log dessa transao estiverem no meio fsico, ou seja, persistidas em memria
secundria.
Buffer do Banco de Dados

Esse 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 esse dado est armazenado no est no buffer, ento esse 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, essas 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 nesse bloco ter sido gravado no Log em disco. Esse
princpio chamado Write-Ahead-Log (WAL).
Nesse 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 e essas tcnicas
influenciam as tcnicas de recuperao. As principais tcnicas so:
NOT-STEAL
Nessa tcnica, um bloco na cache utilizado por uma transao Tx no
pode ser gravado antes do commit de Tx. Esse 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
142 UNIDADE 4
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
dessa 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.
1.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,
esse 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 esse 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 sequncia 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);
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 checkpoint 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 Exemplo de checkpoint.
A Figura 4 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.
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.
144 UNIDADE 4
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.
1.6 Tcnicas de Recuperao

Existem duas 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 persistidos 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 ideia 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.
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. Nesse sentido, as escritas realizadas
por transaes ativas so denominadas de modificaes no efetivadas. Nessa
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 operao
UNDO, onde os valores antigos sero recuperados para o banco de dados. Se
existir, no log, informao sobre o trmino da transao, 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. Essa caracterstica est ligada
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, essas 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, essa tcnica requer a existncia de um log UNDO e REDO.
Essa 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 dado, basicamente, por duas regras.
A primeira regra consiste em fazer uma varredura no log do final para o comeo,
executando UNDO das transaes 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 para realizar REDO, um dado "x" tenha sido atualizado
mais de uma vez por transaes efetivadas. Nesse caso, por medidas de
otimizao, necessrio realizar, somente, o REDO da ltima atualizao do
dado "x".
Exemplo:
Nesse exemplo, vamos expor o comportamento da tcnica UNDO/REDO
com checkpoint diante do processo de recuperao. Para isso, seguiremos um
cenrio que contm cinco transaes dispostas em uma linha do tempo e o
momento da falha. Maiores detalhes sobre esse cenrio podem ser visualizados
na Figura 5.
Figura 5. Tcnica Undo/Redo com o uso de checkpoint.
146 UNIDADE 4
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 a 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 contenham suas atualizaes persistidas no banco de
dados.
A transao T4 efetivou antes do momento da falha, mas suas
atualizaes no foram persistidas no banco de dados. Para esse 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. Nesse caso, essas transaes devem sofrer UNDO.
Algoritmo: 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. Nesse caso, necessrio a existncia de um log UNDO.
Nessa tcnica, se existir um registro de efetivao de uma transao "x"
no log, ento "x" est garantidamente efetivada no banco de dados. A principal
vantagem dessa 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 dessa tcnica bem mais simples do
que a tcnica UNDO/REDO. Nessa abordagem, necessrio realizar 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. Nesse 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 podem ser encontradas na Figura 6.
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 prximo do momento da falha. A disposio
de T4 na linha do tempo, nesse cenrio, permite-nos observar uma caracterstica
dessa tcnica.
As transaes T1 e T2 efetivaram antes do momento da falha e possuem
suas efetivaes em log. Nesse 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, esse 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.
148 UNIDADE 4
Figura 6 Tcnica Undo/Redo sem o uso de checkpoint.
RM_Restart ( )
2. Faa desfeito = { }

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 }
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 consequncia, em como esses dados so
restaurados no caso de falha. Nessa estratgia, o checkpoint s grava no arquivo
de dados s 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. Nesse 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
transao. Quando todas as modificaes do banco de dados so escritas no
log, garante-se a propriedade de atomicidade de transao.
A ideia dessa 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. Nessa 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 acontea uma falha durante o processo de recuperao, a
operao REDO deve ser executada novamente.
Do ponto de vista do gerenciamento de buffer, essas 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.
150 UNIDADE 4
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.
Nessa tcnica o processo de recuperao ocorre por meio de uma
varredura do comeo do log at o final, realizando REDO nas transaes
contidas na lista de REDO. Como a gravao do log, em disco, feita aps a
efetivao das transaes, o REDO acontece somente nas transaes que foram
efetivadas. Caso, durante a falha, haja transaes "ativas", ou seja, transaes
que alcanaram a efetivao, essas devem ser recomeadas.
Esse tipo de tcnica limita a execuo concorrente das transaes
porque itens de dados ficam bloqueados at a efetivao das transaes.
Consequentemente, uma transao no grava as modificaes no BD at sua
efetivao. Logo, uma transao nunca desfeita por causa da ocorrncia de
falhas. 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:
Nesse 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 esse cenrio pode ser visto na Figura 7.
Figura 7 Tcnica No-Undo/Redo sem o uso de checkpoint.

Podemos perceber que as transaes T1, T2 e T4 efetivaram antes do
momento da falha. Nesse 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, essas 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
essas no chegaram as suas efetivaes. Portanto, essas no atualizaram,
de forma persistente, o banco de dados e no sofrem UNDO. Com isso, as
transaes T3 e T5 devem ser ressubmetidas 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 8 exibe o cenrio que queremos
discutir.
Figura 8 Tcnica No-Undo/Redo com o uso de checkpoint.

Nesse 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 nesse cenrio.
Como visto, as transaes T1 e T2 efetivaram antes do checkpoint.
Com isso, essas duas transaes no sofrem operao de REDO porque o
checkpoint garantiu seus efeitos no banco de dados. A transao T4 iniciou antes
152 UNIDADE 4
do checkpoint, mas terminou antes da falha. Nesse caso, a transao T4 dever
sofrer REDO, assim como na tcnica sem o uso do checkpoint. Com relao s
transaes T3 e T4, assim como na tcnica sem o uso de checkpoint, devem ser
ressubmetidas pelos usurios ou aplicaes.
RM_Restart ( )
2. Faa desfeito = { }

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 }
a) Se Ti estiver na lista de transaes ativas, remova Ti desta lista
5. Informe o final do processamento de restaurao ao escalonador.
1.7 Tcnicas de Recuperao de Meio de Armazenamento

Essa tcnica utilizada quando ocorre falha do meio de armazenamento.
Nesse 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, deve-se 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:
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 ressubmetidas

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, nesse caso
zerado, iniciado.
A Figura 9 mostra um exemplo da tcnica de recuperao de meio
armazenamento. Nessa 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. Nesse 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, essa precisa ser desfeita, para manter a consistncia do banco de dados.
Figura 9. T 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 esse
salvo pode sofrer falhas. Normalmente os SGBDs provem utilitrios que realizam
154 UNIDADE 4
essas tarefas.
1.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;
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 10 mostra um exemplo do uso de pginas sombras. No incio,

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 10 Tcnica de recuperao de baseada em pginas sombras.

As vantagens da tcnica de recuperao de pginas sombras que
essa no necessita realizar as operaes de UNDO nem REDO. Contudo, essa
tcnica apresenta muitas desvantagens, a saber: (a) gerenciamento complexo
dos dados, j que ocorrem mudanas constantes nas pginas no disco; (b)
requer coleta de 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, essa tcnica no utilizada em SGBD
atuais.
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? Apresente um

exemplo da sua utilizao.
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 as desvantagens das tcnicas de atualizao

imediata?
12. Assinale V (verdadeiro) ou F (falso) nas afirmativas abaixo:
( ) As tcnicas de recuperao de falhas garantem a atomicidade,

durabilidade e integridade das transaes.
( ) Os tipos de falhas so: de transaes, de sistema e de meio de
156 UNIDADE 4
armazenamento.
( ) A tcnica UNDO/REDO usada na recuperao do meio de
armazenamento.
( ) O log uma arquivo aleatrio utilizada na recuperao do BD que
armazena operaes de escrita.
( ) Uma das vantagens da utilizao do checkpoint que as transaes
committed antes do checkpoint no precisam sofrer UNDO em caso de
falha.
13. Considere as seguintes sentenas e assinale a resposta abaixo:
i) A tcnica ARCHIVE ocorre durante o funcionamento normal do SGBD.

ii) As operaes DUMP/REDO realizam uma varredura forward do Log,
realizando UNDO das transaes committed.
iii) A tcnica Shadow Pages no adequada a SGBD monousurio.
a) Apenas iii est correta.

b) ii e iii esto incorretas.
c) i e iii esto incorretas.
e) Todas esto erradas.
d) i e ii esto corretas.
14. Descreve as tcnicas de recuperao de meio de armazenamento.
15. Explique o funcionamento da tcnica de pginas sombras.
16. (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.

Webliografia
Pgina da Universidade Aberta do Piau UAPI
http://www.ufpi.br/uapi
Pgina da Universidade Aberta do Brasil UAB

http://www.uab.gov.br
Pgina da Secretaria de Educao a Distncia do MEC SEED

http://www.seed.mec.gov.br
Pgina da Associao Brasileira de Educao a Distncia ABED

http://www.abed.org.br
Curso de Banco de Dados UFSC

Professor Ronaldo Mello
http://www.inf.ufsc.br/~ronaldo/
Curso de Banco de Dados UFSC

Professor Frank Siqueira
http://www.inf.ufsc.br/~frank/
Curso de Banco de Dados PUC-RIO

Professor Casa Nova
http://www.inf.puc-rio.br/~casanova/
Curso de Banco de Dados PUC-RIO

Professora Karin Breitman
http://www-di.inf.puc-rio.br/~karin/
158 UNIDADE 4
SILBERSCHATZ, A.; KORTH, H.; SUDARSHAN, S. Sistema de Banco de
Dados. 5. ed., Editora Campus, 2006.
GARCIA-MOLINA, H.; ULLMAN, Jeffrey D.; WIDOM, Jennifer. Implementao

de Sistemas de Bancos de Dados. 1. ed. Lugar: 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. 4. ed.,

Addison-Wesley, 2005.
RAMAKRISHNAN, R. Database Management Systems, 3 ed., McGraw-Hill,

2002.
BERNSTEIN, P. A., V.; HADZILACOS; GOODMAN, N. Concurrency Control

and Recovery in Dabase Systems. Addison-Wesley, 1987.
BRAYNER, A.. Transaction Management in Multidatabase Systems. Shaker

Verlag, 1999.
CASANOVA, M. A. The Concurrency Problem of Database Systems. In:

Lectures Notes in Computer Science, 116, 1981.
ESWARAN, K. P.; GRAY, J. R.; LORIE, A.; TRAIGER, I. L. The Notions of

Consistency and Predicate Locks in a Database System. Communications
of the ACM, 9 (11), 1976.
GRAY, J. N. The Transaction Concept: Virtues and Limitations. Proceedings of

the 7th International Conference on VLDB, pages 144-154, 1981.
GRAY, J. N.; LORIE, R. A.; PUTZOLU, G. R.; TRAIGER, I. L.. Granularity of

Locks and Degrees of Consistency in a Shared Database. In: STONEBRAKER,
M. 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.
HRDER, T. Observations on Optimistic Concurrency Control Schemes.

Informations Systems, 9(2):111-120, 1984.
PAPADIMITRIOU, C. H. The Theory of database Concurrency Control.

Computer Science Press, 1986.
Autores
Doutor em Cincia da Computao pela Universidade Federal
do Cear (UFC), Fortaleza-CE Brasil (2013). Mestre em
Cincia da Computao pela UFC e Graduado em Cincia
da Computao pela Universidade Federal do Piau (UFPI),
Teresina-PI Brasil (2004). Atualmente Professor Assistente
da UFC em Quixad. Atua principalmente nos seguintes
temas: Gerenciamento de Dados Distribudos, Big Data e Cloud Computing.

Possui graduao em Bacharelado em Cincia da Computao
pela Universidade Federal do Cear UFC (1998), mestrado
em Cincia da Computao pela Universidade Federal
do Cear UFC (2001) e doutorado em Informtica pela
Pontifcia Universidade Catlica do Rio de Janeiro PUC-Rio
(2008). Atualmente Professor Adjunto do Departamento de
Computao da Universidade Federal do Cear. Tem experincia na rea de
Cincia da Computao, com nfase em Banco de Dados, atuando principalmente
nos seguintes temas: bancos de dados autogerenciados e autnomos, bancos
de dados mveis e bancos de dados em nuvem.

Bancos de Dados - UNIVERSIDADE ABERTA

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Bancos de Dados - UNIVERSIDADE ABERTA

Enviado por

Direitos autorais:

Formatos disponíveis

Universidade Federal do Piau

Centro de Educao Aberta e a Distncia

Flvio Rubens de Carvalho Sousa

Flvio Rubens de Carvalho Sousa

EQUIPE DE DESENVOLVIMENTO CONSELHO EDITORIAL DA EDUFPI

S725c Sousa, Flvio Rubens de Carvalho.

1. Banco de Dados - Gerncia. 2. Armazenamento de Dados.

2013. Universidade Federal do Piau - UFPI. Todos os direitos reservados.

Na Unidade I so discutidos os principais aspectos relacionados ao

Na Unidade III se discute o problema do controle de concorrncia em

Por fim, na Unidade IV so apresentados conceitos sobre a recuperao

Atualmente, os Sistemas de Gerenciamento de Bancos de

1 SISTEMAS DE GERENCIAMENTO DE BANCOS DE DADOS

1 RECUPERAO DE BANCO DE DADOS

1. SISTEMAS DE BANCOS DE DADOS

A finalidade de um sistema de bancos de dados simplificar e facilitar o

Um Banco de Dados (BD) uma coleo de dados inter-

Construo de Sistemas de Gerenciamento de Banco de Dados 15

Um SGBD dividido em mdulos, onde cada mdulo trata um aspecto

Figura 1.1 Arquitetura de um SBD

Construo de Sistemas de Gerenciamento de Banco de Dados 17

1.3 Classificao dos Sistemas de Bancos de Dados

Os primeiros SGBDs eram hospedados (instalados) em mainframes

Construo de Sistemas de Gerenciamento de Banco de Dados 19

1. Diferencie Banco de Dados, Sistema de Gerenciamento de Banco de Dados

2. Descreva os componentes funcionais de um SGBD.

3. Como podemos classificar os Sistemas de Bancos de Dados?

4. Quais os componentes do SGBD que interagem diretamente com o Sistema

5. Quais os componentes do SGBD que interagem com o usurio?

Um dos aspectos importantes que distinguem os sistemas de bancos de

Na maioria dos sistemas computacionais existem vrios tipos de armazenamentos

Construo de Sistemas de Gerenciamento de Banco de Dados 21

Construo de Sistemas de Gerenciamento de Banco de Dados 23

Figura 2.1 Hierarquia de Meios de Armazenamento

2.1.1 Caractersticas dos Meios Fsicos de Armazenamento

Custo (c): O custo de um meio fsico de armazenamento

em que CT representa o custo total do sistema de memria

Tempo de Acesso (TA): Representa o tempo mdio necessrio

(ii) Serial-access memory (memria de acesso sequencial):

Alterabilidade: Caracterstica que representa a capacidade de

Construo de Sistemas de Gerenciamento de Banco de Dados 25

2.1.2 Armazenamento de Bancos de Dados

2.2 Discos Magnticos

Disco rgido, ou disco duro, (popularmente conhecido como winchester)

Construo de Sistemas de Gerenciamento de Banco de Dados 27

2.2.1 Acessando uma Unidade de Disco

Construo de Sistemas de Gerenciamento de Banco de Dados 29

2.2.2 Medidas de Desempenho de Discos

2.3 Tcnicas RAID

RAID a sigla para Redundant Array of Independent Disks. Sua definio

Construo de Sistemas de Gerenciamento de Banco de Dados 31

2.3.1. Os nveis de RAID

Construo de Sistemas de Gerenciamento de Banco de Dados 33

2.3.2 Tipos de RAID

1. Tanto a memria principal quanto o disco possibilitam o acesso direto a

O tempo de acesso memria principal independente da localizao a

2. Caso voc tenha um arquivo que frequentemente percorrido

Construo de Sistemas de Gerenciamento de Banco de Dados 35

4. Considere a especificao do disco da questo anterior, e suponha

Construo de Sistemas de Gerenciamento de Banco de Dados 37

O gerenciador de buffer o subsistema do SGBD responsvel pela

3.1 Sistema de Memria Virtual

Quando uma aplicao solicita uma informao do banco e dados, o

Construo de Sistemas de Gerenciamento de Banco de Dados 39