Aula11 Administração BD

Tecnologia em Análise e Desenvolvimento de

Sistemas

Administração de Banco de Dados

Recuperação de Falhas - Log do

Sistema

❖

Para se recuperar de falhas que afetam as

transações, o sistema mantém um histórico (

log

)

para registrar as operações das mesmas que

afetam os valores dos itens do banco;

Recuperação de Falhas - Log do

Sistema

❖

Os dados de log podem ser necessários para:

❖

Desfazer ações de uma transação abortada;

❖

Recuperar o sistema de falhas;

Recuperação de Falhas

–

Log do

Sistema

❖

Para cada transação, são registradas no log as

informações:

❖

[start_transaction, T

]

❖

Indica o início da transação T.

❖

[write_item, T, X, old_value, new_value]

❖

Indica que a transação T alterou o valor do item X do

Recuperação de Falhas

–

Log do

Sistema

❖

Para cada transação, são registradas no log as

informações:

❖

[read_item, T, X]

❖

Indica que a transação T leu o valor do item X do

banco de dados.

❖

[commit, T]

Recuperação de Falhas

–

Log do

Sistema

❖

Para cada transação, são registradas no log as

informações:

❖

[abort, T]

❖

Indica que a transação T foi abortada.



[chekpoint]



Entrada no log gravada periodicamente;

Recuperação de Falhas

–

Log do

Sistema

❖

[chekpoint]



A execução de um checkpoint envolve:



Gravar fisicamente o conteúdo do BD da memória volátil

no BD físico



Gravar fisicamente (meio estável) o conteúdo do Log



Gravar um registro de checkpoint no Log



Se não existe este registro, teríamos que investigar todo o

Recuperação de Falhas

–

Log do

Sistema

❖

[chekpoint]



Quando ocorre uma falha de sistema



Todas as transações cujos registros <commit, Ti> estejam

depois do checkpoint mais recente gravado no Log



Devem ser refeitas (REDO)



Todas as transações cujos registros <begin transaction, Ti>

estejam no Log mas os registros <commit, Ti> ou <rollback,

Ti> não estejam

Recuperação de Falhas

–

Log do

Sistema

❖

Chekpoint Fuzzy

❖

Usa [begin_checkpoint] no início do processo

e libera para outros processos

❖

_{Usa [end_checkpoint] no final}

Recuperação de Falhas

–

Log do

Sistema

❖

Quando todas as operações de uma transação

tiverem sido executadas com sucesso e seus efeitos

registrados no log, ocorre o ponto de confirmação

(

commit

) da transação.

❖

Após tal ponto, a transação é considerada confirmada

(

committed

) e, em princípio, os efeitos de suas

operações estão permanentemente registradas no

banco (no caso, a transação registra um

[commit, T]

Exercícios

❖

1)

Uma propriedade importante quando se considera a

recuperação de um banco de dados é constituída pelos

chamados pontos de verificação (checkpoints). Um

checkpoint consiste de um registro, cuja função é indicar

que

❖

(A) o banco de dados sofreu uma paralisação

programada para manutenção.

❖

(B) houve uma falha no conjunto de discos utilizado para

armazenamento dos dados.

❖

(C) houve uma falha de comunicação entre as máquinas

servidora e cliente.

❖

(D) o banco de dados passou por uma operação de

backup completo.

❖

(E) Todas as transações encerradas anteriormente ao

Recuperação de Falhas

–

Log do

Sistema

❖

Portanto, no processo de recuperação de

falhas relativa a uma transação T, as seguintes

operações podem ser usadas:

❖

UNDO

(desfazer)

❖

Desfaz a transação, ou seja, percorre o log de forma

retroativa, retornando todos os itens alterados por

Recuperação de Falhas

–

Log do

Sistema

❖

Portanto, no processo de recuperação de

falhas relativa a uma transação T, as seguintes

operações podem ser usadas:

❖

REDO

(refazer)

❖

Refaz a transação, ou seja, percorre o log para

Recuperação de Falhas

–

Log do

Sistema

❖

Cada transação T tem um identificador único

gerado automaticamente pelo sistema;

❖

Campos para recuperação (UNDO e REDO):

v

BFIM (Before Image): estado antes da alteração

v

usado para UNDO

❖

AFIM (After Image): estado depois da alteração

Recuperação de Falhas

–

Log do

Sistema

Recuperação

❖

Algoritmo básico:

❖

Varre o log de trás para frente

❖

cria listas de transações commit e rollback

❖

desfaz alterações de transações ativas

❖

Varre o log de frente para trás

❖

refaz alterações de transações confirmadas

❖

ignora transações abortadas

Recuperação - Cache

❖

Cache do SGBD

❖

Baseado em páginas de disco mantidas pelo SO;

❖

SGBD chama rotinas de baixo nível do SO;

❖

Essencial para desempenho, porém adiciona

Recuperação - Cache

❖

Dados por Página do Cache

❖

Bit sujo

❖

0 → página não alterada

❖

1 → página alterada

❖

Bit preso-solto

❖

0 → página pode ser gravada

❖

1 → página ainda não pode ser gravada (e.g., espera

de commit)

Recuperação - Cache

❖

Atualização Shadow x In-place

❖

Shadow

: versão modificada de um item gravada

em nova localização de disco

❖

In-place

: versão modificada de item sobrescreve

Recuperação - Cache

❖

Gravando Cache no Disco

❖

Forçar gravação dos itens alterados no disco

quando alterados na memória (antes do

commit)?

❖

Sim: Force

Recuperação - Cache

❖

Gravando Cache no Disco

❖

Permitir alguma gravação antes do

commit

(para

substituição de páginas)?

❖

Sim: Steal

Recuperação - Cache

❖

Gerenciando o cache

❖

Force

❖

Alto tempo de resposta;

❖

Provê durabilidade;

❖

Steal

❖

Melhor throughput;

Recuperação - Cache

Force

No-REDO

Recuperação - Cache

No-Steal

No-UNDO

Recuperação - Cache

❖

Recuperação e Steal/No-Steal x

Force/No-Force

❖

Steal/No-Force (Undo/Redo);

❖

Steal/Force (Undo/No-redo);

❖

No-Steal/No-Force (Redo/No-undo);

Exercícios

❖

2) Pesquisar sobre:

❖

O protocolo

Write-Ahead Logging

(Escrita

Antecipada no Log)

❖

O algoritmo de recuperação ARIES

❖

Traçar um comparativo entre essas duas

técnicas de recuperação

❖

Enviar a pesquisa para:

Contato!!!!