CAPITULO 14

Recuperao
14.1 INTRODUO
Conforme observamos na introduo a esta parte do livro, os
tpicos deste captulo e do seguinte, recuperao e
concorrncia, esto muito inter-relacionados, sendo ambos
aspectos do tpico mais geral de gerenciamento de transaes.
No entanto, para simplificar a apresentao, desejvel
tentar separ-los
tanto quanto possvel (ao menos at que tenhamos acabado de
descrever alguns dos conceitos bsicos); 1 por isso, nosso
foco principal neste captulo ser especificamente na
recuperao, deixando a concorrncia para o captulo
seguinte. Apesar disso, aparecero inevitavelmente algumas
referncias espordicas concorrncia neste captulo.
A recuperao em um sistema de banco de dados significa
basicamente a recuperao do prprio banco de dados: isto ,
restaurar o banco de dados a um estado que se sabe ser
correto (ou melhor, consistente' ) depois que alguma falha o
leva a um estado inconsistente, ou pelo menos suspeito. E os
princpios subjacentes em que se baseia essa recuperao so
muito simples, e podem ser resumidos em uma palavra:
redundncia. (Na verdade, redundncia no nvel fsico; por
razes discutidas em profundidade na Parte III deste livro,
em geral no desejamos que tal redundncia se estenda at o
nvel lgico.) Em outras palavras, o modo de garantir que o
banco de dados de fato recupervel garantir que toda
poro de informao que ele contm possa ser reconstruda a
partir de alguma outra informao armazenada de modo
redundante em algum outro lugar do sistema.
Antes de continuarmos, devemos deixar claro que as idias de
recuperao de fato, as idias de processamento de
transaes em geral so um tanto independentes de ser o
sistema subjacente relacional ou outro qualquer. (Por outro
lado, tambm devemos mencionar que muito do trabalho terico
sobre processamento de transaes historicamente tem sido
feito, e continua a ser feito, em um contexto especificamente
relacional.) Tambm devemos deixar claro que este um tema
enorme! o que esperamos fazer aqui apresentar ao leitor
algumas das idias mais importantes e bsicas. Consulte a
seo Referncias e bibliografia, em especial a referncia
[14.121, para obter algumas sugestes sobre outras leituras,
e tambm os exerccios e as respostas, a fim de encontrar
algumas descries breves de tpicos adicionais.
A organizao do captulo a seguinte: aps esta breve
introduo, as Sees 14.2 e 14.3 explicam a noo
fundamental de uma transao e a idia associada de
recuperao de transao (isto , recuperao do banco de
dados depois que alguma transao individual falhou por
alguma razo). Em seguida, a Seo 14.4 expande essas idias
para a esfera mais ampla de recuperao de sistema (ou seja,
a recuperao depois que alguma espcie de queda do sistema
provoca a falha simultnea de todas as transaes que esto
sendo executadas no momento). A Seo 14.5 um pequeno
passeio pela questo da recuperao da
* No caso, consistente significa satisfazendo a todas as
restries de integridade conhecidas. Portanto, observe que
consistente no quer dizer necessariamente correto; um estado
correto tem de estar consistente, mas um estado consistente
ainda pode estar incorreto, no sentido de que ele no reflete
de modo preciso o verdadeiro estado de coisas no mundo real.
Consistente poderia ser definido como correto no que se
394
refere ao sistema.
mdia (isto , a recuperao depois que o banco de dados
danificado fisicamente de algum modo; por exemplo, pela queda
de uma cabea de gravao sobre o disco). A Seo 14.6
introduz ento o conceito fundamental do commit de duas fases
(two-phase commit). A Seo 14.7 descreve os aspectos
relevantes de SQL. Para encerrar, a Seo 14.8 apresenta um
sumrio e algumas observaes finais.
Uma ltima nota preliminar: supomos em todo este captulo que
estamos em um ambiente de banco de dados de grande porte
(compartilhado, multiusurio). Os SGBDs de pequeno porte
(no compartilhados, de nico usurio) em geral fornecem
pouco ou nenhum suporte em vez disso, a recuperao
considerada responsabilidade do usurio (o que implica que o
usurio deve criar cpias de backup peridicas do banco de
dados e refazer o trabalho manualmente, caso ocorra uma
falha).
14.2 TRANSAES
Como foi dito na Seo 14.1, comeamos nossas discusses pelo
exame da noo fundamental de uma transao. Uma transao
uma unidade lgica de trabalho. Considere o seguinte exemplo.
Suponha que a varivel de relao de peas P inclua um
atributo adicional QDETOTAL, representando a quantidade total
de uma remessa para a pea em questo. Em outras palavras, o
valor de QDETOTAL para qualquer pea dada deve ser igual
soma de todos os valores de QDE, tomados sobre todas as
remessas para essa pea (na terminologia do Captulo 8, isso
uma restrio de banco de dados). Agora, considere o
pseudocdigo de procedimento da Figura 14.1, cuja inteno
adicionar uma nova remessa para o fornecedor F5 e a pea P1,
com a quantidade 1000, ao banco de dados (a operao INSERT
adiciona a nova remessa, a operao UPDATE atualiza o valor
de QDETOTAL para a pea P1 de acordo).
BEGIN TRANSACTION
INSERT INTO FP
RELATION ( TUPLA ( F# F# ( F5' ).
P# P# ( P1 ),
QDE QDE (1000 )
IF ocorreu algum erro THEN GO TO UNDO ; END IF
UPDATE P WHERE P# = P# ( `P1'
QDETOTAL : QDETOTAL + QDE ( 1000)
IF ocorreu algum erro THEN GO TO UNDO ; END IF
COMMIT
GO TO FINISH
UNDO
ROLLBACK
FINISH
RETURN
FIGURA 14.1 Uma amostra de transao (pseudocdigo)
O detalhe importante do exemplo : o que presumivelmente se
pretendia que fosse uma nica operao atmica acrescentar
uma nova remessa na verdade envolve duas atualizaes do
banco de dados, uma operao INSERT e uma operao UPDATE. E
mais, o banco de dados nem sequer consistente entre essas
duas atualizaes; ele viola temporariamente a restrio de
que o valor de QDETOTAL para a pea P1 deve ser igual soma
de todos os valores de QDE para a pea P1. Assim, uma unidade
lgica de trabalho (isto , uma transao) no
necessariamente uma nica operao sobre o banco de dados; em
geral, uma sequncia de vrias dessas operaes, a qual
transforma um estado consistente do banco de dados em outro
estado consistente, sem necessariamente preservar a
consistncia em todos os pontos intermedirios. 395
Agora, claro que o que no se deve permitir que ocorra no
exemplo que uma das atualizaes seja executada e a outra
no, pois isso deixaria o banco de dados em estado
inconsistente. Para ns, o ideal seria ter uma garantia
slida de que ambas as atualizaes sero executadas.
Infelizmente, impossvel fornecer tal garantia h sempre
a possibilidade de que as coisas saiam erradas, e saiam
erradas no pior momento possvel. Por exemplo, poderia
ocorrer uma queda do sistema entre as operaes INSERT e
UPDATE, ou poderia ocorrer um overflow aritmtico na operao
UPDATE etc. * Porm, um sistema que admite o gerenciamento de
transaes fornece algo quase to bom quanto essa garantia.
Especificamente, ele garante que, se a transao executar
algumas atualizaes e ocorrer uma falha (por qualquer
motivo) antes de a transao atingir seu trmino planejado,
ento essas atualizaes sero desfeitas. Assim, a transao
ou ser executada integralmente ou ser totalmente cancelada
(isto , ser como se ela nunca tivesse sido executada).
Desse modo, uma sequncia de operaes que fundamentalmente
no atmica pode parecer atmica de um ponto de vista
externo.
O componente do sistema que fornece essa atomicidade ou
aparncia de atomicidade chamado gerenciador de
transaes (tambm conhecido como monitor de processamento de
transaes ou monitor TP), e as operaes COMMIT e ROLLBACK
so a chave para se entender o modo como ele funciona:
- A operao COMMIT indica o trmino de uma transao bem-
sucedida. Ela informa ao gerenciador de transaes que uma
unidade lgica de trabalho foi concluda com sucesso, o banco
de dados est (ou deveria estar) novamente em um estado
consistente e todas as atualizaes feitas por essa unidade
de trabalho podem agora ser validadas ou tornadas
permanentes.
- Em contraste, a operao ROLLBACK assinala o trmino de uma
transao malsucedida. Ela informa ao gerenciador de
transaes que algo saiu errado, que o banco de dados pode
estar em um estado inconsistente, e que todas as atualizaes
feitas pela unidade lgica de trabalho at agora devem ser
retomadas ou desfeitas.
No exemplo, portanto, emitimos uma instruo COMMIT se
tivermos passado pelas duas atualizaes com sucesso, o que
acarretar a validao das duas alteraes no banco de dados
e as tornar permanentes. Porm, se algo sair errado isto
, se uma das duas atualizaes resultar em uma condio de
erro
emitiremos uma instruo ROLLBACK, a fim de desfazer
quaisquer mudanas feitas at agora. Nota:
mesmo que tenhamos emitido uma instruo COMMIT, o sistema
deve em princpio verificar a restrio de integridade do
banco de dados, detectar o fato de que o banco de dados est
inconsistente e forar de qualquer modo uma operao
ROLLBACK. Contudo, (de modo realista!) no supomos que o
sistema est ciente de todas as restries pertinentes, e
assim a instruo ROLLBACK emitida pelo usurio necessria.
At o momento em que escrevemos, os SGBDs comerciais no
executam uma grande verificao de integridade no instante da
emisso de COMMIT.
A propsito, devemos salientar o fato de que uma aplicao
realista no somente atualizar o banco de dados (ou tentar
faz-lo), mas tambm enviar alguma mensagem de volta ao
usurio final indicando o que aconteceu. No exemplo,
poderamos enviar a mensagem Remessa acrescentada se o
COMMIT fosse alcanado, ou a mensagem Erro remessa no
acrescentada em caso contrrio. Por sua vez, o tratamento de
mensagens tem implicaes adicionais para a recuperao.
Consulte a referncia [14.12] para ver uma discusso
adicional.
Nota: a essa altura, o leitor deve estar se perguntando como
possvel desfazer uma atualizao. A resposta que o
sistema mantm um log ou dirio em fita ou (mais comumente)
em disco, no qual so registrados detalhes de todas as
operaes de atualizao em particular, imagens do objeto
atualizado antes e depois das operaes. Assim, se for
necessrio desfazer alguma atualizao, o sistema poder usar
a entrada de log correspondente para restaurar o objeto
atualizado a seu valor anterior.
(Na verdade, o pargrafo anterior est um tanto simplificado
demais. Na prtica, o log ter duas partes, uma parte ativa
ou on-line, e uma parte de arquivo ou off-line. A parte on-
line a parte usada
A queda do sistema tambm conhecida como uma falha global,
ou do sistema; uma falha de um programa individual, como 396
um overflow, tambm conhecida como uma falha local.
Consulte as Sees 14.3 e 14.4.
durante a operao normal do sistema para registrar detalhes
das atualizaes medida que elas so executadas, e em geral
est contida em disco. Quando a poro on-line fica cheia,
seu contedo transferido para a poro off-line, que por
ser sempre processada sequencialmente pode estar contida em
fita.)
Mais um ponto importante: o sistema deve garantir que
instrues individuais sejam atmicas (tudo ou nada). Essa
considerao se torna particularmente significativa em um
sistema relacional, no qual as instrues so de nvel de
conjuntos e em geral operam sobre muitas tuplas ao mesmo
tempo; no deve ser possvel que uma determinada instruo
falhe durante o processo e deixe o banco de dados em um
estado inconsistente (por exemplo, com algumas tuplas
atualizadas e outras no). Em outras palavras, se ocorrer um
erro em meio a uma certa instruo, ento o banco de dados
deve permanecer totalmente inalterado. Alm disso, como
mencionamos nos Captulos 8 e 9, o mesmo verdade ainda que
a instruo provoque a realizao de operaes adicionais
encobertas, devido a, por exemplo, uma regra DELETE de uma
chave estrangeira que especifica uma ao referencial CASCADE
(em cascata).
14.3 RECUPERAO DE TRANSAES
Uma transao comea com a execuo bem-sucedida de uma
instruo BEGIN TRANSACTION e termina com a execuo bem-
sucedida de uma instruo COMMIT ou de uma instruo
ROLLBACK. Um COMMIT estabelece o que se chama, entre muitas
outras coisas, um ponto de COMMIT ou validao (tambm
conhecido especialmente em produtos comerciais como ponto
de sincronizao). Um ponto de COMMIT corresponde portanto ao
fim de uma unidade lgica de trabalho e, em consequncia, a
um ponto no qual o banco de dados est, ou deveria estar, em
um estado consistente. Em contraste, ROLLBACK devolve o banco
de dados ao estado em que ele se encontrava em BEGIN
TRANSACTION. Isso significa o retorno ao ponto de COMMIT
anterior. (A expresso ponto de COMMIT anterior ainda
exata, mesmo no caso da primeira transao no programa, se
concordarmos em imaginar a primeira instruo BEGIN
TRANSACTION no programa como o estabelecimento tcito de um
ponto de COMMIT inicial.)
Nota: em toda esta seo, o termo banco de dados significa
na realidade apenas a poro do banco de dados acessvel por
meio da transao em questo. Outras transaes podem estar
sendo executadas em paralelo com essa transao e efetuando
mudanas em suas prprias pores; assim, o banco de dados
total pode no se encontrar em um estado totalmente
consistente em um ponto de COMMIT. Contudo, como explicamos
na Seo 14.1, estamos ignorando a possibilidade de
transaes concorrentes neste captulo (tanto quanto
possvel). E claro que essa simplificao no afeta de modo
substancial o ponto em discusso.
Quando um ponto de COMMIT estabelecido:
1. Todas as atualizaes feitas pelo programa em execuo
desde o ponto de COMMIT anterior so validadas, isto , elas
se tornam permanentes. Antes do ponto de COMMIT, todas as
atualizaes devem ser consideradas como apenas tentativas
tentativas no sentido de que podem ser desfeitas
subsequentemente (ou seja, retomadas). Uma vez validada, uma
atualizao tem a garantia de que nunca ser desfeita (essa
a definio de validao).
2. Todos os posicionamentos do banco de dados so perdidos e
todos os bloqueios de tuplas liberados. Nesse caso,
posicionamento de banco de dados se refere idia de que,
em qualquer instante dado, um programa em execuo ter
possibilidade de endereamento a certas tuplas (por exemplo,
atravs de determinados cursores no caso de SQL, como
explicamos no Captulo 4); essa possibilidade de
endereamento se perde em um ponto de COMMIT. Os bloqueios de
tuplas sero explicados no prximo captulo. Nota: alguns
sistemas oferecem uma opo pela qual o programa de fato pode
ser capaz de conservar a capacidade de endereamento para
determinadas tuplas (e, portanto, reter certos bloqueios de
tuplas) de uma transao para a seguinte. Consulte a Seo
14.7 para ver mais detalhes.
O pargrafo 2 anterior excluindo-se a observao sobre a
possibilidade de conservar alguma capacidade de endereamento
e, portanto, conservar certos bloqueios de tuplas tambm se
aplica no caso de uma transao se encerrar com ROLLBACK em
vez de COMMIT. claro que o pargrafo 1 no se aplica nesse
caso.
Observe bem que COMMIT e ROLLBACK terminam a transao, no o
programa. Em geral, a execuo de um nico programa
consistir em uma sequncia de vrias transaes executadas
uma aps a outra, como ilustra a Figura 14.2.
Voltemos agora ao exemplo da seo anterior (Figura 14.1).
Nesse exemplo, inclumos testes explcitos de erros e
emitimos uma instruo ROLLBACK explcita, se qualquer erro
for detectado. Porm, claro que o sistema no pode supor
que programas de aplicao sempre incluiro testes explcitos
para todos os erros possveis. Por isso, o sistema emitir
uma instruo ROLLBACK implcita para todo programa que
falhar por qualquer razo, no atingindo seu trmino
planejado (onde trmino planejado significa uma instruo
COMMIT explcita ou uma instruo ROLLBACK explcita).
Ento, podemos ver agora que as transaes so no apenas a
unidade de trabalho, mas tambm a unidade de recuperao.
Portanto, se uma transao for comprometida com sucesso,
ento o sistema garantir que suas atualizaes sero
instaladas permanentemente no banco de dados, mesmo que o
sistema caia no momento seguinte. Por exemplo, bastante
possvel que o sistema caia depois da instruo COMMIT ser
aceita, mas antes das atualizaes terem sido gravadas
fisicamente no banco de dados elas ainda podem estar
esperando em um buffer de memria principal e serem perdidas
no instante da queda. Mesmo que isso acontea, o procedimento
de reinicializao do sistema ainda instalar essas
atualizaes no banco de dados; ele capaz de descobrir os
valores que devem ser gravados atravs do exame das entradas
relevantes no log. (Resulta que o log deve ser fisicamente
gravado antes de se completar o processamento de COMMIT: essa
a regra de gravao antes do registro no log write-ahead
logging.) Assim, o procedimento de reinicializao recuperar
qualquer transao concluda com sucesso que no tenha
conseguido fazer suas atualizaes serem gravadas fisicamente
antes da queda; por isso, como foi dito antes, as transaes
so de fato a unidade de recuperao. Nota: no prximo
captulo, veremos que elas tambm so a unidade de
concorrncia. Alm disso, como devem supostamente transformar
um estado consistente do banco de dados em outro estado
consistente, elas tambm podem ser consideradas como uma
unidade de integridade (do banco de dados) consulte o
Captulo 8.
As propriedades ACID
Acompanhando a referncia [14.14], podemos resumir esta seo
e a anterior dizendo que as transaes tm quatro
propriedades importantes atomicidade, consistncia,
isolamento e durabilidade (chamadas coloquialmente de
propriedades ACID):
- Atomicidade: as transaes so atmicas (tudo ou nada).

inicializao
do programa
i primeira transao
COMMIT
BEGIN
TRANSACTION
i segunda transao (cancelada)
BEGIN
TRANSACTION
terceira transao
ROLLBACK
BEGIN
TRANSACTION
COMMIT
trmino
do programa
FIGURA 14.2 A execuo de um programa uma sequncia de
transaes
398
- Consistncia: as transaes preservam a consistncia do
banco de dados. Ou seja, uma transao transforma um estado
consistente do banco de dados em outro estado consistente,
sem necessariamente preservar a consistncia em todos os
pontos intermedirios.
- Isolamento: as transaes so isoladas umas das outras.
Isto , embora em geral haja muitas transaes sendo
executadas de modo concorrente, as atualizaes de qualquer
transao dada so ocultas de todas as outras at o commit
dessa transao. Outro modo de dizer isso afirmar que, no
caso de duas transaes distintas T1 e T2, T1 poderia ver as
atualizaes de T2 (aps T2 fazer o commit) ou T2 poderia ver
as atualizaes de T1 (aps T1 fazer o commit), mas
certamente no ambas, consulte o Captulo 15 para ver mais
detalhes.
- Durabilidade: uma vez comprometida uma transao, suas
atualizaes sobrevivem no banco de dados mesmo que haja uma
queda subsequente do sistema.
14.4 RECUPERAO DO SISTEMA
O sistema deve estar preparado para se recuperar no apenas
de falhas puramente locais como a ocorrncia de uma condio
de overflow dentro de uma transao individual, mas tambm de
falhas globais como uma queda de energia. Por definio,
uma falha local s afeta a transao em que a falha realmente
ocorreu; essas falhas j foram discutidas nas Sees 14.2 e
14.3. Em contraste, uma falha global afeta todas as
transaes em andamento no instante da falha e, portanto, tem
implicaes significativas em todo o sistema. Nesta seo e
na seguinte, consideramos brevemente o que est envolvido na
recuperao de uma falha global. Essas falhas se enquadram em
duas grandes categorias:
- Falhas do sistema (por exemplo, queda de energia), que
afetam todas as transaes em curso no momento, mas no
danificam fisicamente o banco de dados. As vezes, uma falha
do sistema chamada soft crash.
- Falhas da mdia (por exemplo, queda da cabea de gravao
sobre disco), que causam danos ao banco de dados ou a uma
parte dele, e afetam pelo menos todas as transaes que no
momento esto usando essa parte. As vezes, uma falha da mdia
chamada hard crash.
As falhas do sistema sero discutidas em seguida; as falhas
da mdia sero examinadas na Seo
14.5.
O ponto crtico no que se refere a falhas do sistema o fato
de que o contedo da memria principal perdido (em
particular, os buffers do banco de dados se perdem). Ento, o
estado exato de qualquer transao em curso no momento da
falha deixa de ser conhecido; desse modo, tal transao no
poder nunca mais ser concluda com sucesso e dever ser
desfeita isto , retomada quando o sistema for
reinicializado.
Alm disso, tambm pode ser necessrio (como sugerimos na
Seo 14.3) refazer no momento de reinicializao certas
transaes concludas com xito antes da queda, mas que no
conseguiram ter suas atualizaes transferidas dos buffers do
banco de dados para o banco de dados fsico.
Surge aqui a questo bvia: de que maneira o sistema saber
no momento de reinicializao quais transaes devem ser
desfeitas e quais devem ser refeitas? A resposta a
seguinte: em certos intervalos predeterminados em geral,
sempre que algum nmero preestabelecido de entradas gravado
no log o sistema automaticamente marca um checkpoint.
Marcar um checkpoint envolve (a) gravar fisicamente
(gravao forada) o contedo dos buffers do banco de dados
no banco de dados fsico e (b) gravar fisicamente um registro
de checkpoint especial no log fsico. O registro do
checkpoint fornece uma lista de todas as transaes que
estavam em andamento no momento em que o checkpoint foi
marcado. Para ver como essa informao utilizada, considere
a Figura 14.3, que deve ser lida da seguinte maneira (observe
que a hora na figura flui da esquerda para a direita):
- Ocorreu uma falha do sistema no instante tf.
- O checkpoint mais recente antes do instante tf foi marcado
no tempo tc. 399
- As transaes de tipo T1 foram concludas (com sucesso)
antes do tempo tc.
- As transaes do tipo T2 foram iniciadas antes do instante
tc e concludas (com sucesso) aps o instante tc e antes de
tf.
- As transaes do tipo T3 tambm foram iniciadas antes do
instante tc, mas no foram concludas at o instante tf.
- As transaes do tipo T4 comearam aps o instante tc e
foram concludas (com sucesso) antes do instante tf.
- Finalmente, as transaes do tipo T5 tambm foram iniciadas
aps o instante tc, mas no foram concludas at o instante
tf.
Tempo tc tf
T
r Ti 1
dT2
n
s T3
T5
e
$
Checkpoint Falha do sistema
(tempo tc) (tempo tf)
FIGURA 14.3 Cinco categorias de transaes
Deve ficar claro que, quando o sistema reinicializado, as
transaes dos tipos T3 e T5 devem ser desfeitas, e as
transaes dos tipos T2 e T4 devem ser refeitas. Contudo,
observe que as transaes do tipo T1 no entram absolutamente
no processo de reinicializao, porque suas atualizaes
foram foradas no banco de dados no instante tc, como parte
do processo do checkpoint. Observe tambm que as transaes
concludas sem sucesso (isto , com uma retomada) antes do
instante tf tambm no entram absolutamente no processo de
reinicializao (por que no?).
Por conseguinte, no momento da reinicializao, o sistema
passa primeiro pelo procedimento a seguir, a fim de
identificar todas as transaes dos tipos T2 a T5:
1. Comear com duas listas de transaes, a lista UNDO e a
lista REDO. Definir a lista UNDO como igual lista de todas
as transaes dadas no registro do checkpoint mais recente;
definir a lista REDO como vazia.
2. Pesquisar o log para a frente, a partir do registro do
checkpoint.
3. Se for encontrada uma entrada de log BEGIN TRANSACTION
para a transao T, acrescentar T lista UNDO.
4. Se for encontrada uma entrada de log COMMIT para a
transao T, mover T da lista UNDO para a lista REDO.
5. Quando for alcanado o final do log, as listas UNDO e REDO
identificaro respectivamente transaes dos tipos T3 e T5 e
transaes dos tipos T2 e T4.
400
Agora, o sistema percorrer o log do fim para o incio,
desfazendo as transaes da lista UNDO; em seguida, ele
percorre o log de novo para a frente, refazendo as transaes
da lista REDO.* Nota: a restaurao do banco de dados a um
estado consistente desfazendo o trabalho s vezes chamada
recuperao inversa. De modo anlogo, a restaurao do banco
de dados a um estado consistente refazendo o trabalho s
vezes chamada recuperao direta.
Finalmente, quando toda essa atividade de recuperao for
concluda, ento (e s ento) o sistema estar pronto para
aceitar um novo trabalho.
14.5 RECUPERAO DA MIDIA
Nota: o tpico de recuperao de mdia de um tipo um pouco
diferente dos assuntos de recuperao de transaes e do
sistema. Ns o inclumos aqui por completeza.
Repetindo o que foi dito da Seo 14.4, uma falha de mdia
uma falha como a queda de uma cabea de disco, ou ento uma
falha do controlador de disco, na qual uma parte do banco de
dados destruda fisicamente. A recuperao de uma falha
desse tipo envolve basicamente o recarregamento (ou a
restaurao) do banco de dados a partir de uma cpia de
backup (ou dump). Em seguida, usa-se o log em geral, tanto
a parte ativa quanto a parte de arquivo para refazer todas
as transaes que se completaram desde que foi feita a ltima
cpia de backup. No h necessidade de desfazer as transaes
que ainda estavam em curso no momento da falha pois, por
definio, todas as atualizaes dessas transaes de
qualquer modo foram desfeitas (na verdade, perdidas).
A necessidade de ser capaz de efetuar a recuperao da mdia
implica a necessidade de um utilitrio de dum pirestore (ou
de descarga/recarga). A poro de dump desse utilitrio
usada para criar cpias de backup do banco de dados por
solicitao. (Essas cpias podem ser mantidas em fita ou em
outro meio de armazenamento de arquivos. No necessrio que
estejam na mdia de acesso direto.) Depois de uma falha de
mdia, a parte de restaurao do utilitrio usada para
recriar o banco de dados a partir de uma cpia de backup
especificada.
14.6 COMMIT DE DUAS FASES
Nesta seo, examinaremos rapidamente uma elaborao muito
importante do conceito bsico de commit/rolback, chamada de
COMMIT de duas fases. O COMMIT de duas fases importante
sempre que uma determinada transao pode interagir com
vrios gerenciadores de recursos independentes, cada um
gerenciando seu prprio conjunto de recursos recuperveis e
mantendo seu prprio log de recuperao.* Por exemplo,
considere uma transao sendo executada em um mainframe IBM
que atualiza um banco de dados IMS e tambm um banco de dados
DB2 (a propsito, essa uma transao perfeitamente vlida).
Se a transao se completar com sucesso, ento todas as suas
atualizaes, tanto aos dados do IMS quanto aos dados do DB2,
tero de ser validadas; inversamente, se ela falhar, ento
todas as suas atualizaes tero de ser retomadas. Em outras
palavras, no dever ser possvel que as atualizaes IMS
sejam validadas e as atualizaes DB2 sejam retomadas, ou
vice-versa pois ento a transao no seria mais atmica.
Segue-se que no faz sentido a transao emitir, digamos, um
COMMIT para o IMS e um ROLLBACK para o DB2. E mesmo que ela
emitisse a mesma instruo para ambos, o sistema ainda
poderia cair entre as duas, com resultados desagradveis.
Assim, em vez disso, a transao emite uma nica instruo
COMMIT (ou ROLLBACK) para todo o sistema. Essa instruo
COMMIT ou ROLLBACK global por um componente do sistema
chamado coordenador, cuja tarefa garantir que ambos os
Voc ir notar que nossa descrio do procedimento de
recuperao do sistema muito simplificado. Em particular,
ele mostra primeiro a execuo de operaes de desfazer, e
depois a execuo das operaes de refazer. Os primeiros
sistemas de fato funcionavam dessa maneira; porm, por razes
de eficincia, os sistemas modernos em geral executam
primeiro as operaes de refazer, e depois as operaes de
desfazer (consulte, por exemplo, as referncias [4.17] e
[4.19]).
* Em particular, ele importante no contexto de sistemas de
bancos de dados distribudos e, por essa razo, descrito
com mais
detalhes no Captulo 20. 401
gerenciadores de recursos (isto , o IMS e o DB2 no exemplo)
faam, a validao ou a retomada das atualizaes pelas quais
so responsveis em unssono e, alm disso, forneam essa
garantia mesmo que o sistema falhe no meio do processo.
Ento, o protocolo de COMMIT de duas fases que permite ao
coordenador oferecer tal garantia.
Vejamos como ele funciona. Para simplificar, suponha que a
transao tenha concludo com sucesso seu processamento de
banco de dados; assim, a instruo no mbito do sistema que
ela emite COMMIT, e no ROLLBACK. Ao receber essa
solicitao de COMMIT, o coordenador executa o seguinte
processo em duas fases:
1. Primeiro, ele instrui todos os gerenciadores de recursos a
ficarem prontos para seguir qualquer caminho na transao.
Na prtica, isso significa que cada participante do processo
ou seja, cada gerenciador de recursos envolvido deve
forar todas as entradas de log de recursos locais utilizados
pela transao em seu prprio log fsico (isto , para o
armazenamento no voltil; acontea o que acontecer da por
diante, o gerenciador de recursos ter agora um registro
permanente do trabalho que realizou para a transao, e ser
capaz de comprometer suas atualizaes ou retom-las,
conforme seja necessrio). Supondo-se que a gravao forada
seja bem-sucedida, o gerente de recursos responder agora
OK ao coordenador. Caso contrrio, ele responder No OK.
2. Depois de receber respostas de todos os participantes, o
coordenador fora a gravao de uma entrada em seu prprio
log fsico, registrando sua deciso a respeito da transao.
Se todas as respostas foram OK, essa deciso ser fazer o
COMMIT; se qualquer resposta tiver sido No OK, a deciso
ser retomar. De qualquer forma, o coordenador informar
ento cada participante de sua deciso, e cada participante
dever ento validar ou retomar a transao de modo local,
conforme tiver sido instrudo. Observe que cada participante
tem de fazer o que lhe diz o coordenador na Fase 2 esse o
protocolo. Observe tambm que o aparecimento do registro de
deciso no log fsico do coordenador assinala a transio da
Fase 1 para a Fase 2.
Agora, se o sistema falhar em algum ponto durante o processo
geral, o procedimento de reinicializao procurar o registro
de deciso no log do coordenador. Se o encontrar, ento o
processo de COMMIT de duas fases poder continuar do ponto em
que foi interrompido. Se no achar o registro, ele presumir
que a deciso foi retomar, e mais uma vez o processo poder
ser concludo adequadamente. Nota: vale a pena observar que
se o coordenador e os participantes forem executados em
mquinas diferentes, como pode acontecer em um sistema
distribudo (consulte o Captulo 20), ento uma falha por
parte do coordenador poder manter algum participante
esperando durante um longo tempo pela deciso do coordenador
e, enquanto ele estiver esperando, quaisquer atualizaes
feitas pela transao atravs desse participante devero ser
mantidas ocultas de outras transaes (isto , essas
atualizaes provavelmente tero de ser mantidas bloqueadas,
conforme veremos no prximo captulo).
Observamos que o gerenciador de comunicaes de dados (o
gerenciador DC consulte o Captulo 2) tambm pode ser visto
com um gerenciador de recursos no sentido descrito. Isto ,
as mensagens tambm podem ser consideradas um recurso
recupervel, exatamente como o banco de dados, e o
gerenciador DC precisa ser capaz de participar do processo de
COMMIT de duas fases. Para obter mais detalhes sobre esse
ponto e sobre toda a idia do COMMIT de duas fases, consulte
a referncia [14.12].
14.7 RECURSOS DE SQL
O suporte de SQL para transaes e, portanto, para
recuperao baseada em transao, segue as linhas gerais
descritas nas sees precedentes. Em particular, a SQL admite
as instrues usuais COMMIT e ROLLBACK (com uma palavra-chave
opcional WORK em ambos os casos, como vimos no Captulo 4);
essas instrues foram uma operao CLOSE de todo cursor
aberto, provocando assim a perda de todo o posicionamento do
banco de dados. Nota: algumas implementaes de SQL fornecem
uma opo para impedir essa operao CLOSE automtica e a
perda de posicionamento em COMMIT (mas no em ROLLBACK). Por
exemplo, o DB2 admite uma opo WITH HOLD em uma declarao
de cursor;
402
COMMIT no fecha esse cursor, mas o deixa aberto e
posicionado de tal forma que a prxima instruo
FETCH o deslocar para a prxima linha em sequncia.
Portanto, o cdigo de reposicionamento possivelmente complexo
que talvez tivesse de ser usado na prxima instruo OPEN no
ser mais necessrio. Atualmente, esse recurso est includo
na SQL3 (consulte o Apndice B).
Uma diferena entre o suporte de SQL para transaes e os
conceitos gerais esboados neste captulo que a SQL no
inclui qualquer instruo BEGIN TRANSACTION explcita. Em vez
disso, uma transao se inicia implicitamente sempre que o
programa executa uma instruo de incio de transao e
ainda no h uma transao em curso. (Assim como ocorre com a
opo manter cursor apresentada antes, provvel que o
suporte para uma instruo BEGIN TRANSACTION explcita seja
acrescentada ao padro em alguma verso futura; no momento,
essa instruo est includa na SQL3.) Os detalhes sobre
exatamente quais instrues de SQL so de incio de
transao esto alm do escopo deste livro basta dizer que
todas as instrues executveis descritas em captulos
anteriores so instrues de incio de transao enquanto,
claro, as instrues COMMIT e ROLLBACK propriamente ditas no
o so. Uma instruo especial chamada SET TRANSACTION usada
para definir certas caractersticas da prxima transao a
ser iniciada (SET TRANSACTION s pode ser executada quando
no h nenhuma transao em curso, e ela prpria no inicia
nenhuma transao). Dessas caractersticas, as nicas que
discutiremos aqui so o modo de acesso e o nvel de
isolamento. A sintaxe :
SET TRANSACTION <lista_com_vrgulas de opes>
onde <lista_com_vrgulas de opes> especifica um modo de
acesso, um nvel de isolamento, ou ambas as opes.
- O modo de acesso READ ONLY ou READ WRITE. Se nenhum deles
for especificado, ser pressuposto o modo READ WRITE, a menos
que o nvel de isolamento READ UNCOMMITED seja especificado;
nesse caso, ser suposto o modo READ ONLY. Se READ WRITE for
especificado, o nvel de isolamento no poder ser READ
UNCOMMITED.
- O nvel de isolamento assume a forma ISOLATION LEVEL
<isolamento>, onde <isolamento> READ UNCOMMITED, READ
COMMITED, REPEATABLE READ ou SERIALIZABLE. Para obter mais
explicaes, consulte o Captulo 15.
14.8 RESUMO
Neste captulo, apresentamos uma introduo necessariamente
breve ao tpico de gerenciamento de transaes. Uma transao
uma unidade lgica de trabalho e tambm uma unidade de
recuperao (e ainda uma unidade de concorrncia e uma
unidade de integridade consulte os Captulos 15 e 8,
respectivamente). As transaes tm as propriedades ACID de
atomicidade, consistncia, isolamento e durabilidade. O
gerenciamento de transaes a tarefa de supervisionar a
execuo de transaes de tal modo que se possa, de fato,
garantir que elas tm essas importantes propriedades. Com
efeito, a funo geral do sistema poderia ser definida como a
execuo confivel de transaes.
As transaes so iniciadas por BEGIN TRANSACTION e
terminadas por COMMIT TRANSACTION (trmino bem-sucedido) ou
por ROLLBACK TRANSACTION (trmino malsucedido). Um COMMIT
estabelece um ponto de COMMIT (as atualizaes se tornam
permanentes). Um ROLLBACK rola o banco de dados para trs,
at o ponto de COMMIT anterior (as atualizaes so
desfeitas). Se uma transao no atingir o trmino planejado,
o sistema forar um ROLLBACK (recuperao de transaes).
Para ser capaz de desfazer (ou refazer) atualizaes, o
sistema mantm um log de recuperao. Alm disso, os
registros do log para uma dada transao devem ser gravados
no log fsico antes de poder ser concludo o processamento de
COMMIT para essa transao (a regra dc registro no log antes
da gravao).
O sistema tambm garante as propriedades ACID de transaes
diante de uma queda do sistema. Para fornecer essa garantia,
o sistema deve (a) refazer todo o trabalho feito por
transaes concludas com sucesso antes da queda e (b)
desfazer todo o trabalho feito por transaes iniciadas, mas
no con403
cludas antes da queda. Essa atividade de recuperao do
sistema executada como parte do procedimento de
reinicializao do sistema (algumas vezes conhecido como
procedimento de reinicializao/recuperao). O sistema
descobre qual trabalho deve ser refeito e qual trabalho deve
ser desfeito examinando o registro de checkpoint mais
recente. Os registros de checkpoint so gravados no log a
intervalos predeterminados.
O sistema tambm fornece recuperao de mdia restaurando o
banco de dados de um dump anterior e depois com a
utilizao do log refazendo o trabalho concludo desde que
esse dump foi feito. Os utilitrios de dump/restore so
necessrios para dar suporte recuperao de mdia.
Os sistemas que permitem a interao de transaes com dois
ou mais gerenciadores de recursos por exemplo, dois SGBDs
diferentes, ou um SGBD e um gerenciador DC devem usar um
protocolo chamado COMMIT de duas fases se tiverem de manter a
propriedade de atomicidade de transaes. As duas fases so
(a) a fase de preparao, na qual o coordenador instrui todos
os participantes a ficarem prontos a irem para qualquer
lado, e (b) a fase de validao, na qual supondo-se que
todos os participantes responderam satisfatoriamente durante
a fase preparao o coordenador instrui todos os
participantes a efetuarem o COMMIT (ou, caso contrrio, o
ROLLBACK).
Com relao ao suporte para recuperao no padro SQL, a SQL
fornece instrues COMMIT e ROLLBACK explcitas (mas nenhuma
instruo BEGIN TRANSACTION explcita). Ela tambm admite uma
instruo SET TRANSACTION que permite ao usurio especificar
o modo de acesso e o nvel de isolamento para a prxima
transao a ser iniciada.
Um ltimo ponto: fizemos em todo este captulo a suposio
tcita de um ambiente de programa- o de aplicaes. Porm,
todos os conceitos discutidos se aplicam igualmente ao
ambiente do usurio final (embora eles possam estar um tanto
ocultos nesse nvel). Por exemplo, os produtos de SQL em
geral permitem que o usurio digite instrues de SQL
interativamente a partir de um terminal. Normalmente, cada
uma dessas instrues interativas de SQL tratada como uma
transao em si; o sistema emitir uma instruo COMMIT
automtica a pedido do usurio depois de executar a instruo
de SQL (ou uma instruo ROLLBACK automtica se ocorrer uma
falha, claro). Contudo, alguns sistemas permitem ao usurio
inibir essas instrues COMMIT automticas e, em vez disso,
executar toda uma srie de instrues de SQL (seguidas por
uma instruo COMMIT ou ROLLBACK explcita) como uma nica
transao. Entretanto, geralmente essa prtica no
recomendvel pois poderia fazer partes do banco de dados
permanecerem bloqueadas e, portanto, inacessveis a outros
usurios por perodos de tempo longos demais (consulte o
Captulo 15). Alm disso, nesse ambiente possvel que
ocorra um DEALOCK (impasse) entre usurios finais, o que um
bom argumento para a proibio dessa prtica (novamente,
consulte o Captulo 15).
EXERCICIOS
14.1 Os sistemas no permitem que uma dada transao valide
mudanas em bancos de dados (ou variveis de relaes, ou
...) individualmente, ou seja, sem o COMMIT simultneo de
mudanas em todos os outros bancos de dados (ou variveis de
relaes ou ...). Por que no?
14.2 Transaes no podem ser aninhadas umas dentro das
outras. Por que no?
14.3 Enuncie a regra de registro no log antes da gravao.
Por que essa regra necessria?
14.4 Quais so as implicaes de recuperao para:
a. Forar a gravao de buffers no banco de dados em COMMIT?
b. Nunca gravar buffers fisicamente no banco de dados antes
de COMMIT?
14.5 Enuncie o protocolo de COMMIT de duas fases e discuta as
implicaes de uma falha por parte (a) do coordenador, (b) de
um participante, durante cada uma das duas fases.
14.6 Usando o banco de dados de fornecedores e peas, escreva
um programa de SQL para ler e imprimir todas as peas na
ordem de nmero de pea, removendo cada dcima pea ao
avanar, e comeando uma nova transao depois de cada dcima
linha. Pode-se supor que a regra de remoo (DELETE) da chave
estrangeira de
404 peas para remessas especifica a operao em cascata
(CASCADE) isto , voc pode ignorar as remessas
para a finalidade deste exerccio. Nota: solicitamos
especificamente uma soluo em SQL neste caso, para que voc
possa usar o mecanismo de cursor de SQL em sua resposta.
REFERNCIAS E BIBLIOGRAFIA
14.1 Philip A. Bernstein: Transaction Processing Monitors,
CACM 33, Nmero 11 (novembro de 1990).
Uma citao: Um sistema TP um conjunto integrado de
produtos que ... inclui hardware, como processadores,
memria, discos e controladores de comunicaes, e ainda
software, como sistemas operacionais, sistemas de
gerenciamento de bancos de dados, redes de computadores e
monitores TP. Grande parte da integrao desses produtos
proporcionada pelos monitores TP. O artigo serve como uma
boa introduo informal estrutura e funcionalidade de
monitores TP.
14.2 Philip A. Bernstein, Vassos Hadzilacos e Nathan Goodman:
Concurrency Control and Recovery in Database Systems.
Reading, Mass.: Addison-Wesley (1987).
Um texto que, como o ttulo indica, aborda no apenas a
recuperao, mas todo o gerenciamento de transaes, de um
ponto de vista muito mais formal que o deste captulo.
14.3 A. Bilris et ai.: ASSET: A System for Supporting
Extended Transactions, Proc. 1994 ACM SIGMOD Int. Conf. on
Management of Data, Minneapolis, Minn. (maio de 1994).
As noes bsicas de transaes descritas no corpo deste
captulo e no prximo so amplamente consideradas rgidas
demais para certos tipos de aplicaes mais novos (em
especial, aplicaes altamente interativas), e diversos
modelos estendidos de transaes tm sido propostos para
cuidar dessa questo (consulte a referncia [14.151).
Contudo, no momento em que escrevemos, nenhuma dessas
propostas se mostrou claramente superior a todas as outras;
em consequncia disso, os fornecedores de bancos de dados
[tm sido relutantes] na incorporao de qualquer modelo
desse tipo a um produto.
O foco de ASSET bem diferente. Em vez de propor mais um
novo modelo de transaes, o trabalho oferece um conjunto de
operadores primitivos inclusive o COMMIT usual e assim por
diante, alm de alguns novos operadores que podem ser
usados para definir modelos personalizados de transaes
adequados para aplicaes especficas. Em particular, o
artigo mostra como ASSET pode ser empregado para especificar
transaes aninhadas, transaes divididas, sagas e outros
modelos estendidos de transaes descritos na literatura.
14.4 L. A. Bjork: Recovery Scenario for a DB/DC System,
Proc. ACM National Conf., Atlanta, Ga. (agosto de
1973).
Esse artigo e seu complemento, o artigo escrito por Davies
[14.71 representam provavelmente os primeiros trabalhos
tericos na rea de recuperao.
14.5 R. A. Crus: Data Recovery in IBM DATABASE 2, IBM Sys.
J. 23, Nmero 2 (1984).
Descreve em detalhes o mecanismo de recuperao do DB2 e, ao
faz-lo, fornece uma boa descrio das tcnicas de
recuperao em geral. Em particular, o artigo explica como o
DB2 se recupera de uma queda do sistema durante o prprio
processo de recuperao, enquanto alguma transao est no
meio de uma retomada. Esse problema exige cuidado especial
para garantir que atualizaes no validadas da transao que
est sendo retomada sejam de fato desfeitas (em certo
sentido, o oposto do problema da atualizao perdida
consulte o Captulo 15).
14.6 C. J. Date: Distributed Database: A Closer Look, em C.
J. Date e Hugh Darwen, Relational Database Writings 1989-
1991. Reading, Mass.: Addison-Wesley (1992).
A Seo 14.6 deste captulo descreve o que poderia ser
chamado de protocolo bsico do COMMIT de duas fases. Vrios
aperfeioamentos desse protocolo bsico so possveis. Por
exemplo, se o participante P responder ao coordenador C na
Fase 1 que no fez nenhuma atualizao na transao em causa
(isto , ela foi somente de leitura), ento C poder
simplesmente ignorar P na Fase 2. Alm disso, se todos os
participantes responderem somente de leitura na Fase 1, ento
a Fase 2 poder ser completamente omitida.
So possveis outros aperfeioamentos e refinamentos. Esse
artigo [14.61 inclui uma descrio tutorial de alguns deles.
Especificamente, ele discute os protocolos de COMMIT
presumido e ROLLBACK presumida (verses melhoradas do
protocolo bsico), o modelo de rvore de processos (quando um
participante precisa servir como coordenador para certas
partes de uma transao), e o que acontecer se uma
falha de comunicao ocorrer durante o processo de
reconhecimento de um participante pelo coordena- 405
dor. Nota: embora as discusses sejam apresentadas no
contexto de um sistema distribudo, a maioria dos conceitos
tem na realidade uma aplicao mais ampla. Consulte o
Captulo 20 para ver uma descrio ampliada de alguma dessas
questes.
14.7 C. T. Davies, Jr.: Recovery Semantics for a DB/DC
System, Proc. ACM National Conf., Atlanta, Ga. (agosto de
1973)
Veja a anotao referncia [14.41.
14.8 C. T. Davies, Jr.: Data Processing Spheres of Control,
IBM Sys. J. 17, Nmero 2 (1978).
As esferas de controle foram a primeira tentativa de
investigar e formalizar o que mais tarde se tornou a
disciplina de gerenciamento de transaes. Uma esfera de
controle uma abstrao que representa um item de trabalho
que (de fora) pode ser visto como atmico. Porm, ao
contrrio do modo como as transaes so admitidas hoje na
maioria dos sistemas, as esferas de controle podem ser
aninhadas dentro de outras, at uma profundidade arbitrria
(ver a resposta ao Exerccio 14.2).
14.9 Hector Garcia-Molina e Kenneth Salem: Sagas, Proc.
1987 ACM SIGMOD Int. Conf. on Management of Data, San
Francisco, Calif. (maio de 1987).
Um grande problema com as transaes descritas neste captulo
o fato de que elas so tacitamente consideradas de durao
muito curta (milissegundos ou mesmo microssegundos). Se uma
transao demorar um longo tempo (horas, dias, semanas) ento
(a) se ela tiver de ser retomada, ser necessrio desfazer
uma grande quantidade de trabalho e (b) mesmo se tiver
sucesso, ela ainda dever depender de recursos do sistema
(dados do banco de dados etc.) por um tempo excessivo,
bloqueando assim outros usurios (consulte o Captulo 15).
Infelizmente, muitas transaes reais tendem a ser de longa
durao, em especial em algumas reas de aplicaes mais
recentes, como engenharia de hardware e software.
As sagas so um modo de atacar esse problema. Uma saga uma
sequncia de transaes curtas (no sentido usual do termo)
com a propriedade de que o sistema garante que (a) todas as
transaes na sequncia sero executadas com sucesso, ou (b)
certas transaes de compensao sero executadas para
cancelar os efeitos de transaes concludas com sucesso
dentro de uma execuo geral incompleta da saga (funcionando
assim como se a saga jamais tivesse sido executada). Por
exemplo, em um sistema bancrio, poderamos ter a transao
somar R$ 100,00 conta A. A transao de compensao seria
obviamente subtrair R$ 100,00 da conta A. Uma extenso da
instruo COMMIT permite que o usurio informe ao sistema que
a transao de compensao a ser executada deve ser
necessria mais tarde para cancelar os efeitos da transao
concluda agora. Observe que, no caso ideal, uma transao de
compensao nunca deve terminar com um ROLLBACK!
14.10 James Gray: Notes on Data Base Operating Systems, em
R. Bayer, R. M. Graham e G. Seegmuller (editores), Operating
Systems: Au Advanced Course (Springer Verlag Lecture Notes in
Com puter Science 60). Nova York, N.Y.: Springer Verlag
(1978). Tambm disponvel como IBM Research Report RJ 2188
(fevereiro de 1978).
Uma das primeiras fontes e certamente a mais acessvel de
material sobre gerenciamento de transaes. Ela contm a
primeira descrio amplamente disponvel do protocolo de
COMMIT de duas fases. E bvio que ela no to completa
quanto a referncia mais recente [14.121, mas ainda assim
recomendvel.
14.11 Jim Gray: The Transaction Concept: Virtues and
Limitations, Proc. 7th Int. Conf. on Very Large Data Bases,
Cannes, Frana (setembro de 1981).
Um enunciado conciso de vrios conceitos e problemas
relacionados com transaes, incluindo uma variedade de
questes de implementao. Um problema particular tratado o
seguinte: em geral, o que se entende por transaes no pode
ficar aninhado dentro de outras transaes (consulte a
resposta ao Exerccio 14.2). Porm, apesar disso, existe
algum modo de permitir que as transaes sejam desmembradas
em subtransaes menores? A resposta um sim limitado
possvel que uma transao estabelea pontos de gravao
intermedirios enquanto est sendo executada e, mais tarde,
efetuar a retomada at um ponto de gravao estabelecido
anteriormente (se necessrio), em vez de retomar todo o
caminho at o incio. Na verdade, um recurso de ponto de
gravao semelhante a esse foi incorporado a vrios sistemas
implementados, inclusive (por exemplo) o Ingres o produto
comercial, no o prottipo e o System R (mas no o DB2).
Tal conceito parece um pouco mais prximo da noo de
transaes reconhecida normalmente no mundo real. Porm,
observe que estabelecer um ponto de gravao no o
406
mesmo que executar uma operao COMMIT; atualizaes feitas
pela transao ainda no estaro visveis para outras
transaes at o trmino (bem-sucedido) da transao.
Nota: as sagas da referncia [14.9] que, em certos
aspectos, se refere ao mesmo problema como pontos de gravao
foram propostas aps Gray ter escrito esse artigo.
14.12 Jim Gray e Andreas Reuter: Transaction Processing:
Concepts and Techniques. San Mateo, Calif.: Morgan Kaufmann
(1993).
Se algum texto de cincia da computao merece o epteto
clssico instantneo certamente este. A princpio, seu
tamanho assustador (?), mas os autores exibem uma invejvel
clareza, que torna agradvel a leitura at mesmo dos aspectos
mais ridos do assunto. Em seu prefcio, eles afirmam que sua
inteno a de ajudar ... a resolver problemas reais. O
livro pragmtico, cobrindo questes bsicas sobre
transaes em detalhes considerveis. A apresentao est
repleta de fragmentos de cdigo mostrando
algoritmos bsicos e estruturas de dados e no
enciclopdico. Apesar dessa ltima afirmao, o livro (o
que no surpreende) abrangente, e com certeza se destina a
tornar-se a obra padro. Fortemente recomendvel.
14.13 Jim Gray: The Recovery Manager of the System R Data
Manager, ACM Comp. Surv. 13, Nmero 2 (junho de 1981).
As referncias [14.131 e [14.18] tratam dos recursos de
recuperao do System R (uma espcie de pioneiro nesse
campo). A referncia [14.13] fornece uma viso geral de todo
o subsistema de recuperao. A referncia [14.18] descreve em
detalhes um aspecto especfico, chamado mecanismo de
SHADOWPAGE (consulte a anotao a essa ltima referncia mais
adiante).
14.14 Theo Hiirder e Andreas Reuter: Principies of
Transaction-Oriented Database Recovery, ACM Comp. Surv. 15,
Nmero 4 (dezembro de 1983).
A origem da sigla ACID. O artigo oferece uma apresentao
tutorial muito clara e cuidadosa dos princpios de
recuperao. Ele tambm fornece uma estrutura de terminologia
coerente para descrever uma ampla variedade de esquemas de
recuperao e tcnicas de registro de log de maneira
uniforme. O artigo classifica e descreve vrios sistemas
existentes de acordo com esse quadro de terminologia.
O artigo inclui alguns nmeros empricos interessantes sobre
a frequncia de ocorrncias e tempos tpicos de recuperao
(aceitveis) para trs espcies de falhas (local, de sistema,
de mdia) em um sistema tpico de grande porte:
14.15 Henry F. Korth: The Double Life of the Abstraction
Conccpt: Fundamental Principie and Evolving System Concept
(palestrante convidado), Proc. 2lst Int. Conf. on Very Large
Data Bases, Zurique, Sua (setembro de 1995).
Uma boa e breve viso geral das maneiras pelas quais o
conceito de transao precisa evoluir para oferecer suporte a
novos requisitos de aplicaes.
14.16 Henry F. Korth, Eliezer Levy e Abraham Silberschatz: A
Formal Approach to Recovery by Compensating Transactions,
Proc. l6th Int. Conf. on Very Large Data Bases, Brisbane,
Austrlia (agosto de 1990).
Formaliza a noo de transaes de compensao usadas em
sagas [14.9] e outros lugares para desfazer transaes
validadas (e no-validadas).
14.17 David Lomet e Mark R. Tuttle: Redo Recovery after
System Crashes, Proc. 2lst Int. Conf. on Very Large Data
Bases, Zurique, Sua (setembro de 1995).
407
Tipo de
falha
Frequncia de
ocorrncia
Tempo de recuperao
Local
Sistema
Mdia
10 a 100 por minuto
Vrias por semana
Uma ou duas vezes
por ano
Igual ao tempo de execuo
da transao
Alguns minutos
Uma a duas horas
Uma anlise precisa e cuidadosa da recuperao de operaes
de refazer (isto , recuperao direta). [Embora] a
recuperao de refazer seja apenas uma forma de recuperao,
ela ... importante [porque uma parte crucial do processo
geral de recuperao e] deve resolver os [problemas] mais
difceis. (Nesse sentido, observe que em contraste com o
algoritmo esboado na Seo 14.4 ARIES [14.19] sugere que
se entenda a recuperao ... como a realizao da recuperao
de refazer seguida pela recuperao de desfazer.) Os autores
afirmam que sua anlise conduz a uma compreenso melhor das
implementaes existentes e ao potencial para melhorar
significativamente os sistemas de recuperao.
14.18 Raymond A. Lorie: Physical Integrity in a Large
Segmented Database, ACM TODS 2, Nmero 1 (maro de 1977).
Como foi explicado na anotao referncia [14.13], esse
artigo trata de um aspecto especfico do sub- sistema de
recuperao do System R, chamado mecanismo de shadow page. (A
propsito, observe que o termo integridade no ttulo desse
artigo tem pouca relao com a noo de integridade discutida
no Captulo 8.) A idia bsica simples: quando uma
atualizao (no validada) gravada pela primeira vez no
banco de dados, o sistema no sobrescreve a pgina existente,
mas armazena uma nova pgina em algum outro lugar no disco. A
pgina antiga ento a sombra para a nova. O commit da
atualizao envolve a atualizao de diversos ponteiros, a
fim de apontar para a nova pgina e descartar a sombra; por
outro lado, a retomada da atualizao envolve restabelecer a
shadow page e descartar a nova.
Embora seja conceitualmente simples, o esquema de shadow page
sofre da deficincia sria de destruir qualquer clusterizao
que possa ter existido anteriormente nos dados. Por isso, o
esquema no foi escolhido do System R para ser usado no DB2
[14.5], embora tenha sido usado em SQL/DS [4.13].
14.19 C. Mohan, Don Haderle, Bruce Lindsay, Hamid Pirahesh e
Peter Schwartz: ARIES: A Transaction Recovery Method
Supporting FineGranularity Locking and Partial Rollbacks
Using Write-Ahead Logging, ACM TODS 17, Nmero 1 (maro de
1992).
ARIES significa Algorithm for Recovery and Isolation
Exploiting Semantics Algoritmo para Recuperao e
Isolamento Explorando a Semntica. ARIES foi implementado
(em vrios graus) em diversos sistemas comerciais e
experimentais, incluindo em particular o DB2. Citando o
artigo: Solues do [problema de gerenciamento de
transaes] podem ser avaliadas usando-se vrias mtricas:
grau de concorrncia admitido dentro de uma pgina e entre
pginas, complexidade da lgica resultante, sobrecarga de
espao no armazenamento no voltil e em pginas de memria
para dados e para o log, sobrecarga em termos do nmero de
operaes de E/S sncronas e assncronas exigidas durante a
reinicializao/recuperao e o processamento normal, tipos
de funcionalidade admitidos (retomadas parciais de
transaes, etc.), quantidade de processamento executada
durante a reinicializao/recuperao, grau de processamento
concorrente admitido durante a reinicializao/recuperao,
extenso de retomadas de transaes induzidas pelo sistema
causadas por impasses, restries impostas sobre dados
armazenados (por exemplo, exigncia de chaves exclusivas para
todos os registros, restrio do tamanho mximo de objetos ao
tamanho da pgina etc.), capacidade de dar suporte a novos
modos de bloqueio que permitam a execuo concorrente com
base na comutatividade e em outras propriedades de
operaes como incremento/decremento sobre os mesmos dados
por diferentes transaes, e assim por diante. [ARIES] se
comporta muito bem com relao a todas essas mtricas. (Uma
parfrase breve.)
Desde que ARIES foi projetado pela primeira vez, numerosos
aperfeioamentos e diversas verses
especializadas foram desenvolvidas e descritas na literatura:
ARIES/CS (para sistemas cliente/servidor), ARIES/IM (para
gerenciamento de ndices), ARIES/NT (para transaes
aninhadas), etc.
RESPOSTAS A EXERCICIOS SELECIONADOS
14.1 Esse recurso estaria em conflito com o objetivo da
atomicidade de transaes. Se uma transao pudesse validar
algumas, mas no todas as suas atualizaes, ento as
atualizaes no-validadas poderiam mais tarde ser retomadas,
enquanto as atualizaes validadas naturalmente no poderiam.
Assim, a transao deixaria de ser tudo ou nada.
14.2 Esse recurso entraria em conflito com o objetivo da
atomicidade de transaes. Considere o que aconteceria se a
transao B estivesse aninhada na transao A e ocorresse a
seguinte sequncia de eventos (mais uma vez, supomos para
simplificar que faz sentido falar sobre atualizar uma
tupla):
BEGIN TRANSACTION (transao A)
408
BEGIN TRANSACTION (transao B)
a transao B atualiza a tupla t
COMMIT (transao 8)
ROLLBACK (transao A)
Se a tupla t foi restaurada a seu valor anterior a A nesse
ponto, ento a instruo COMMIT de B na verdade no foi uma
instruo COMMIT. Reciprocamente, se a instruo COMMIT de B
foi genuna, ento a tupla t no pode ser restaurada a seu
valor anterior a A e, portanto, a instruo ROLLBACK de A no
pode ser executada.
Observe que afirmar que as transaes no podem ser aninhadas
dizer que um programa s pode executar uma operao BEGIN
TRANSACTION quando no h nenhuma transao em execuo no
momento.
Na verdade, muitos autores (a comear por Davies na
referncia [14.7]) propuseram a possibilidade de aninhar
transaes descartando-se a exigncia de durabilidade (a
propriedade D em ACID) por parte de uma transao mais
interna. Isso significa que a instruo COMMIT emitida por
uma transao interna comprometer as atualizaes dessa
transao, mas apenas at o nvel externo seguinte. Se esse
nvel externo terminar ento com uma retomada, a transao
interna tambm ser retomada. No exemplo, a instruo COMMIT
de B seria assim uma instruo COMMIT apenas para A, no para
o mundo exterior, e poderia ento de fato ser revogada
subsequentemente.
Vale a pena dedicar um instante a uma breve elaborao das
idias precedentes. As transaes aninhadas podem ser vistas
como uma generalizao dos pontos de gravao [14.11]. Os
pontos de gravao permitem que uma transao seja organizada
como uma sequncia de aes (e a retomada pode ocorrer em
qualquer instante at o incio de qualquer ao anterior na
sequncia); em contraste, o aninhamento permite que uma
transao seja organizada de forma recursiva como uma
hierarquia de tais aes (ver Figura 14.4). Em outras
palavras:
- BEGIN TRANSACTION estendida para dar suporte a
subtransaes (ou seja, se BEGIN TRANSACTION for emitida
quando j houver uma transao em execuo, ela iniciar uma
transao filha).
- COMMIT compromete, mas apenas dentro do escopo superior
(se essa transao uma filha).
- ROLLBACK desfaz o trabalho, mas s at o incio dessa
transao em particular (incluindo transaes filhas, netas,
etc.), mas no incluindo a transao superior, se houver
alguma).
FIGURA 14.4 Transaes aninhadas tpicas
Observamos que as transaes aninhadas sero difceis de
implementar de um ponto de vista puramente sinttico! em
uma linguagem como a SQL, que carece de uma operao BEGIN
TRANSACTION explcita (deve existir alguma forma explcita de
indicar que uma transao interna deve ser iniciada e de
assinalar o ponto para a retomada no caso de uma falha dessa
transao interna).
14.4
a. Uma operao de refazer nunca necessria depois de uma
falha do sistema.
b. A operao de desfazer fsica nunca necessria e,
portanto, registros de log de desfazer tambm so
desnecessrios.
409
j
ri
,,
[A1
ri H12 etc.
F14.6 Este exerccio tpico de uma ampla classe de
aplicaes, e o esboo de soluo a seguir tambm tpico.
EXEC SQL DECLARE CP CURSOR FOR
SELECT P.P#, P.PNOME, P.COR, P.PESO, P.CIDADE
FROM P
WHERE P.P# > P#anterior
ORDER BY P#
P#anterior :
eof := falso
DO WHILE ( eof = falso
EXEC SQL OPEN CP
DO contagem : 1 TO 10
EXEC SQL FETCH CP INTO :P#,
IF SQLSTATE = `02000 THEN
DO;
EXEC SQL CLOSE CP
EXEC SQL COMMIT ;
eof := verdadeiro
END DO
ELSE imprimir P#, .
END IF
ENDDO;
EXEC SQL DELETE FROM P WHERE P.P# = :P# ;
EXEC SQL CLOSE CP
EXEC SQL COMMIT
P#anterior : P#
END DO ;
Observe que perdemos posio dentro da tabela de peas P no
fim de cada transao (mesmo se no fechssemos
explicitamente o cursor CP, a instruo COMMIT o fecharia de
modo automtico). O cdigo anterior no ser portanto
particularmente eficiente, porque cada transao nova exige
uma pesquisa na tabela de peas para restabelecer a posio.
As coisas melhorariam um pouco se houvesse um ndice sobre a
coluna P# como de fato bem provvel que acontea, pois
{P#} a chave primria e o otimizador escolhe esse ndice
como caminho de acesso para a tabela.
410