INSTITUTO DE COMPUTAÇÃO

Universidade Estadual de Campinas

Mecanismos de Recuperação
Rodrigo Tripodi Calumby
tripodi@ic.unicamp.br

Ricardo da Silva Torres

rtorres@ic.unicamp.br

RECOD – Reasoning for Complex Data

Tópicos do curso
 Introdução – conceitos básicos e
arquitetura de SGBD
 Modelagem de Dados (MER)
 Modelo Relacional
 Linguagens de Manipulação de Dados
 Dependências Funcionais e normalização
 Processamento e Otimização de Consultas
 Processamento de Transações, Controle
de Concorrência e Recuperação de Dados
Agenda
 Motivação/Objetivo
 Tipos de falha
 Log de transações
 Atualizações de dados
 “Caching” de dados
 “Undo/Redo” de transações
 Checkpoint
 Esquemas de Recuperação
 Esquema de recuperação do ARIES
 Recuperação em sistemas com múltiplos
bancos de dados
Motivação/Objetivo
 Exemplo:

 Se o sistema falha durante uma transação de

transferência, então uma das contas pode ter valores
incorretos

 O banco de dados deve retornar ao estado consistente

anterior à modificação de uma das contas

 Objetivo:

 Trazer o banco de dados para o último estado consistente

(antes da falha)

 Preservar propriedades de transações (Atomicidade,

Consistência, Isolamento e Durabilidade)
Tipos de falhas
 Falhas de hardware e software
 Erro no sistema/transação
 Ex.: overflow, divisão por zero
 Erros locais ou condições de exceção
 Ex.: falta de saldo em uma conta, “abort”
programado
 Técnica aplicada para controle de
concorrência
 Ex: deadlock, violação de serialidade
 Falha no disco, falha na RAM
Log de Transações
 O que é necessário:
 Valores de dados antes da modificação
 (BFIM - BeFore Image)

 Valores de dados depois da modificação

 (AFIM – AFter Image)

 Back P e Next P apontam para registros anterior

e posterior de uma mesma transação
T ID Back P Next P Operation Data item BFIM AFIM
T1 0 1 Begin
T1 1 4 Write X X = 100 X = 200
T2 0 8 Begin
T1 2 5 W Y Y = 50 Y = 100
T1 4 7 R M M = 200 M = 200
T3 0 9 R N N = 400 N = 400
T1 5 nil End
Atualização de dados
 Atualização imediata: assim que
o item de dado é modificado em
memória, a cópia em disco pode ser
atualizada
 Atualização atrasada/adiada:
todos os itens de dados em
memória são escritos quando a
transação termina sua execução
(atinge ponto de commit) ou depois
que um número fixo de transações
finalizam
Atualização de dados
 Atualização “Shadow”: a versão
modificada de um item de dado não
sobrescreve sua cópia em disco, mas
é escrita em uma localização
separada no disco
 Atualização “In-place”: a versão
em disco do item de dado é
sobrescrita pela versão em memória
Caching de dados
 Itens de dados que são modificados são
armazenados, primeiramente, no cache do
bd pelo Gerenciador de Cache e, depois da
modificação, eles são gravados no disco
 A gravação é controlada pelos bits Modified
e Pin-Unpin
• Pin-Unpin: informa ao SO para não gravar o
item de dado
• Modified: indica o AFIM de cada item
Undo/Redo de transações
 Para manter atomicidade, as
operações de transações são
refeitas ou desfeitas
 Undo: Restaura todos os BFIMs no
disco (Remove todos os AFIMs)
 Redo: Regrava todos os AFIMs no
disco
 A recuperação do bd ocorre através
da execução de operações Undo ou
Redo, ou combinação das duas
Exemplo

T1 T2 T3
read_item (A) read_item (B) read_item (C)
read_item (D) write_item (B) write_item (B)
write_item (D) read_item (D) read_item (A)
write_item (A) write_item (A)
Exemplo
A B C D
30 15 40 20

[start_transaction, T3]
[read_item, T3, C]
* [write_item, T3, B, 15, 12] 12
[start_transaction,T2]
[read_item, T2, B]
**[write_item, T2, B, 12, 18] 18
[start_transaction,T1]
[read_item, T1, A]
[read_item, T1, D]
[write_item, T1, D, 20, 25] 25
[read_item, T2, D]
**[write_item, T2, D, 25, 26] 26
[read_item, T3, A]
---- system crash ----

* T3 é rolled back porque não atingiu o seu ponto de commit

** T2 is rolled back porque ela leu o valor do item B escrito por T3
 Undo/Redo de transações
Registro das operações no log:

T3 READ(C) WRITE(B) READ(A)

BEGIN READ(B) WRITE(B) READ(D) WRITE(D)
T2
BEGIN READ(A) READ(D) WRITE(D)
T1
BEGIN
Time
system crash

Exemplo de roll-back em cascata

Undo/Redo de transações
 Write-Ahead Logging (WAL)
 Quando atualização in-place (imediata ou
atrasada) é usada, então o log é necessário
para a recuperação
 Para a operação Undo: antes da AFIM de um
item de dado ser gravado no disco
(sobrescrevendo a BFIM) sua BFIM deve ser
escrita no log, que deve ser salvo no disco
 Para operação Redo: antes de uma operação
executar a operação de commit, todas as suas
AFIMs devem ser escritas no log, que deve ser
salvo no disco
Checkpoint
 De tempos em tempos (aleatoriamente ou
segundo algum critério) o bd grava seus buffers
no disco buscando minimizar a tarefa de
recuperação
 Processo:
– Suspensão temporária da execução de transações
– Grava (“force write”) os dados modificados do buffer
no disco
– Escreve um registro de [checkpoint] no log e salva o
log no disco
– Volta a re-executar transações
 Durante a recuperação, as operações de redo ou
undo são requeridas para transações que
aparecem depois do registro de [checkpoint]
Esquemas de recuperação
 Maneiras para gravar informação do cache do bd no
disco:
 Steal: cache pode ser gravada antes da transação
comitar
 No-Steal: cache não pode ser gravada antes da
transação comitar
 Force: se todas as páginas atualizadas por uma
transação forem imediatamente escritas no disco
quando a transação se efetivar
 No-Force: as páginas atualizadas por uma transação
podem ser escritas depois que ela efetivou.
 Quatro diferentes mecanismos de recuperação
 Steal/No-Force (Undo/Redo)
 Steal/Force (Undo/No-redo)
 No-Steal/No-Force (No-undo/Redo)
 No-Steal/Force (No-undo/No-redo)
Esquemas de Recuperação
 Atualizações atrasadas (No-Undo/Redo)
 Atualizações atrasadas em sistemas monousuários
 Sem concorrência
 Um conjunto de transações registra suas
atualizações no log
 No ponto de commit, sob o esquema WAL,
estas atualizações são gravadas no disco
 O log é usado para refazer todas as transações
afetadas pela falha
 Nenhuma operação de undo é necessária porque a
AFIM é gravada no disco somente antes da transação
comitar
Esquemas de Recuperação
 Sistema monousuário com atualização atrasada
(a) T1 T2
read_item (A) read_item (B)
read_item (D) write_item (B)
write_item (D) read_item (D)
write_item (A)

(b)
[start_transaction, T1]
[write_item, T1, D, 20]
[commit T1]
[start_transaction, T2]
[write_item, T2, B, 10]
[write_item, T2, D, 25] ← falha

 As operações [write_item, …] de T1 são refeitas

 As entradas no log referentes à transação T2 são ignoradas pelo
gerenciador de recuperação
Esquemas de Recuperação
Atualização atrasada em sistemas multiusuário
 Necessidade por um mecanismo de controle de concorrência
para garantir isolamento
 Transações que registram operações no log depois do
checkpoint são refeitas.
 O gerenciador de recuperação pode analisar registros de
transações anteriores ao checkpoint para conseguir AFIMs.

T1
T2
T3
T4
T5
t1 Time t2
checkpoint system crash

 Recuperação em ambiente multiusuário

Esquemas de Recuperação
 Sistema multiusuário com atualização atrasada
(a) T1 T2 T3 T4
read_item (A) read_item (B) read_item (A) read_item (B)
read_item (D) write_item (B) write_item (A) write_item (B)
write_item (D) read_item (D) read_item (C) read_item (A)
write_item (D) write_item (C) write_item (A)

(b)
[start_transaction, T1]
[write_item, T1, D, 20]
[commit, T1]
[checkpoint]
[start_transaction, T4]
[write_item, T4, B, 15]
[write_item, T4, A, 20]
[commit, T4]
[start_transaction T2]
[write_item, T2, B, 12]
[start_transaction, T3]
[write_item, T3, A, 30]
[write_item, T2, D, 25] ← system crash
 T2 e T3 são ignoradas porque elas não alcançaram os seus pontos de commit
 T4 é refeita porque seu commit acontece depois do último checkpoint
Esquemas de Recuperação
 Sistema multiusuário com atualização atrasada
 Duas tabelas são necessárias para a implementação
deste protocolo:
 Active table: todas as transações ativas são mantidas
nesta tabela
 Commit table: todas as transações comitadas são
mantidas nesta tabela

 Durante a recuperação, todas as transações da tabela

de commit são refeitas e todas as transações da
tabela active são ignoradas caso suas AFIMs não
tenham sido gravadas no bd.
 É possível que uma transação da tabela de commit
possa ser refeita duas vezes
Esquemas de Recuperação
 Técnicas de recuperação baseada em
atualização imediata
 Atualizações são gravadas no disco antes do
commit
• Algoritmo Undo/No-redo

 Atualizações podem ser gravadas no disco depois

do commit
• Algoritmo Undo/Redo
Esquemas de Recuperação
 Técnicas de recuperação baseada em
atualização imediata
 Algoritmo Undo/No-redo
• AFIMs de transações são gravadas
no disco seguindo o esquema WAL
antes do commit
• Durante a recuperação, transações são
desfeitas
• Nenhuma transação é refeita
• Mesmo transações que tenham
terminado a sua execução podem ser
desfeitas
Esquemas de Recuperação
 Técnicas de recuperação baseada em atualização
imediata
 Algoritmo Undo/Redo (ambiente monousuário)
• Log é mantido sob o protocolo WAL
• Atualizações podem ser gravadas no disco depois do commit
• Em um dado momento, uma transação estará no sistema
– na tabela de commit
– ou na tabela de transações ativas
• Desfaz a transação se ela está na tabela de
transações ativas
• Refaz a transação se ela está na tabela de commit
Esquemas de Recuperação
 Técnicas de recuperação baseada em atualização imediata
Algoritmo Undo/Redo (execução concorrente)
–
• Técnica de controle de concorrência é necessária
2PL restrito (uma transação só lê ou escreve dados escritos por
–
transações efetivadas)(pode ocorrer deadlock)
Log mantido sob esquema WAL
•
Atualizações podem ser gravadas no disco depois do commit
•
Uso de tabelas de transações ativas e de transações comitadas
•
Checkpoint é usado
•

Desfaz a transação se ela está na tabela de transações ativas

•
Refaz a transação se ela está na tabela de transações comitadas
•
Esquemas de Recuperação
 Shadow paging
 A AFIM não sobrescreve sua BFIM
 É armazenada em outro lugar do disco
 Há duas versões de um item de dado em lugares
diferentes do disco

X Y
X' Y'

Database

 X e Y: cópias shadow de itens de dados

 X` e Y`: cópias correntes de itens de dados
 Esquemas de Recuperação
Current Directory Shadow Directory
(after updating pages 2, 5) (not updated)
Page 5 (old)
1 Page 1 1
2 Page 4 2
3 Page 2 (old) 3
4 Page 3 4
5 Page 6 5
6 Page 2 (new) 6
Page 5 (new)
Algoritmo de Recuperação ARIES

 Baseado em:
 WAL (Write Ahead Logging)
 Repetir histórico durante redo: ARIES
rastreia todas as atualizações feitas no
bd antes da falha
 Registrar alterações no log durante o
undo: previne ARIES a não repetir
operações completas de undo se uma
falha ocorre durante a recuperação
Algoritmo de Recuperação ARIES
 O algoritmo de recuperação ARIES
consiste em três etapas:
 Análise: identifica páginas “sujas”
(atualizadas) no buffer e o conjunto de
transações ativas no momento da falha. O
ponto do log onde a operação de redo vai
iniciar é determinado
 Redo: operações redo necessárias são
executadas
 Undo: log é percorrido de trás para frente e
operações de transações ativas no momento
da falha são desfeitas na ordem reversa
Algoritmo de Recuperação ARIES
 Log e o número de sequência no log (LSN)
– Um registro de log é escrito para (a) atualização de
dado, (b) efetivação de transações, (c) “aborto” de
transações, (d) undo, e (e) fim de transação

– Um único LSN é associado para cada registro de log.

LSN aumenta monotonicamente e indica o endereço no
disco do registro do log associado

– Cada página de dado armazena o LSN do registro de

log mais recente correspondente a uma atualização na
página
Algoritmo de Recuperação ARIES
 Um registro de log armazena:
 LSN do registro anterior da transação
 Id da transação
 Tipo de registro de log

Para uma operação de escrita, registram-se ainda:

 ID da página que inclui o item
 Tamanho do item atualizado
 Deslocamento (offset) em relação ao início da
página
 BFIM do item
 AFIM do item
Algoritmo de Recuperação ARIES
 Ainda são armazenadas no log durante o
checkpoint:
 Transaction table: contém uma entrada para cada
transação ativa
 Id da transação
 Status da transação
 LSN do registro mais recente da transação

 Dirty Page table: contém uma entrada para cada

página modificada no buffer
 Id da página
 LSN correspondente à atualização mais recente
daquela página
Algoritmo de Recuperação ARIES
 Durante o checkpoint, as seguintes
operações são feitas:
 Escreve um registro de begin_checkpoint no log
 Escreve um registro de end_checkpoint no log
 O conteúdo da tabela de transações e da
tabela de páginas sujas são colocadas no
final do log
 Escreve o LSN do registro begin_checkpoint em
um arquivo especial
 Este arquivo especial é acessado durante a
recuperação para localizar o último
checkpoint
 Usa “fuzzy checkpointing”
Algoritmo de Recuperação ARIES
 Fase de análise:
– inicia no registro begin_checkpoint e varre até o registro
end_checkpoint;
– reconstrói as tabelas de transações ativas e de páginas
sujas gravadas no final do log;
– identifica operações de redo e undo que devem ser
executadas
 Fase de Redo:
– refaz operações que aparecem na tabela de páginas
sujas na ordem em que foram executadas
 Fase de Undo:
– desfaz operação, varrendo o log de trás para frente;
para cada operação de undo, escreve um registro no log

 O processo de recuperação termina no final da fase de undo

Algoritmo de Recuperação ARIES
LSN LAST-LSN TRAN-ID TYPE PAGE-ID Other Info.
1 0 T1 update C -----
2 0 T2 update B -----
3 1 T1 commit -----
(a) 4 begin checkpoint
5 end checkpoint
6 0 T3 update A -----
7 2 T2 update C -----
8 7 T2 commit -----

TRANSACTION TABLE DIRTY PAGE TABLE

TRANSACTION ID LAST LSN STATUS PAGE ID LSN
(b) T1 3 commit C 1
T2 2 in progress B 2

TRANSACTION TABLE DIRTY PAGE TABLE

TRANSACTION ID LAST LSN STATUS PAGE ID LSN
T1 3 commit C 1
(c) T2 8 commit B 2
T3 6 in progress A 6
Recuperação em sistema com
múltiplos bancos de dados
 Multidatabase system
 sistema de bancos de dados distribuídos
 SGBDs diferentes/ diferentes SO
 Uma transação pode ser executada em múltiplos
nós
 Neste cenário de execução, a transação se efetiva
somente quando todos os nós concordam em
efetivar a parte da transação que está executando
 Este esquema de efetivação é chamado de “two-
phase commit” (2PC)
 Se um dos nós falha ou não pode efetivar a parte
da transação de que é responsável:
 A transação é abortada
 Cada nó recupera a transação sob o seu próprio
protocolo de recuperação
Fontes

Elmasri & Navathe

Dúvidas?