Cap. 21 - Recuperação Pretende garantir a atomicidade e durabilidade das transações. Atomicidade => É responsabilidade do gerente de recuperação voltar.

Apresentação em tema: "Cap. 21 - Recuperação Pretende garantir a atomicidade e durabilidade das transações. Atomicidade => É responsabilidade do gerente de recuperação voltar."— Transcrição da apresentação:

1 Cap Recuperação Pretende garantir a atomicidade e durabilidade das transações. Atomicidade => É responsabilidade do gerente de recuperação voltar o BD ao estado anterior ao início de uma transação que aborta ou é interrompida por uma falha do sistema. Durabilidade => É responsabilidade do GR garantir que dados modificados por transações que tiveram seus commit’s atendidos, sejam refletidos no BD mesmo em presença de falhas. Falhas: Transações incorretas (quebram consistência) => não são tratadas. Falhas em transações: aborts explícitos, underflow, overflow ... Erros de sistema: quedas de força, falhas no SO, no SGBD ... => Conteúdos da memória principal e do buffer pool são perdidos. O conteúdo do BD não. Falhas de meio magnético: corrupção no armazenamento estável => tratados via back-up.

2 Gerente de Recuperação
Flush e Write Fetch Buffer pool Ger. Log Write Read Read Write Arquivo de LOG BD Log - Registro das operações (write, commit, abort) usado para recuperação Pode conter também informação sobre transações ativas, “commited” e abortadas. Operações sobre o Log: Undo/Redo => Idempotentes

3 A estrutura do Log : Cache de log O que é um item no log?
Valor Ant Valor T2 Item Valor Ant Valor Tempo T3 Item Valor Ant Valor T1 Item Valor Ant Valor T3 Item Valor Ant Valor O que é um item no log? Pode-se colocar todo o bloco => perdulário Apenas a parte modificada (No bloco, offset, tamanho_item). O log cresce muito => Faz necessário arquivamento (archive) da parte mais antiga, e restauração da mesma em caso de falha. Cache de log Exige vinculação dos blocos do buffer pool com entradas do log. Write Ahead Logging (WAL): blocos do log escritos em disco antes dos blocos de dados.

4 Grav. em Disco a Partir do Cache
Necessário Garantir persistência Liberar espaço de Buffer: estratégia LRU (Menos recentemente usado) e estratégia FIFO (First-in First-out) Abordagens Steal/No-steal: Abordagem no-steal impede gravação em disco de páginas antes do commit Pin-unpin: cotrole de páginas que podem ir para disco Steal exige menos memória para buffer Abordagens Force/No-force: Abordagem force obriga a gravação de todas as páginas alteradas em disco no momento do commit No-force diminui operações de E/S

5 Check Points Ponto registrado no log onde se tem garantia de que toda atualização anterior ao mesmo está refletida no BD. O restart não precisa ler todo o log. Permite apagar partes antigas do arquivo de log (liberando espaço). t tc tf T1 T2 T3 Transações T4 T5 Check Point Falha T1: Sem problemas (Commit antes de tc => já está no BD) T2, T4: Commit antes da Falha => devem ser refeitas (Redo) T3, T5: Falha antes do commit => devem ser desfeitas (Undo)

6 Estratégias de Recuperação
Dependência do Controle de Concorrência Atualização postergada (no undo/redo) Os dados alterados por uma transação só podem ser refletidos no BD após o commit. Opções: Área temp. p/ itens alterados (“after_image”) Pin de páginas alteradas Exemplo c/ uso de área temporária e bloqueio estrito Write(T,item,valor): Log (T, item, valor) after_image(T,item)=valor Read(T,item): Se T já escreveu em item então retorna after_image(T,item) senão retorna fetch(item)

7 Recuperação: No Undo/ Redo (cont.)
Commit(T): commit_L = commit_L È {T} copia after_image(T,*) para cache Abort(T): abort_L = abort_L È {T} Descarta after_image(T,*) Restart: Redone = Æ Varre o log do fim para o início para cada entrada L se (L.T Î commit_L e L.item Ï Redone) então copia L.valor para o cache Redone = Redone È {L.item} Vantagens Transações abortadas são simplesmente submetidas de novo Sem rollback por falhas Sem rollback em cascata Desvantagens Espaço adicional de memória Bloqueio estrito: menor concorrência

8 Recuperação: Undo/No Redo
Atualização imedidata (undo / no redo) Toda vez que é necessária alteração num item, o(s) bloco(s) com aquele item são trazidos para memória modificados e atualizados no buffer pool. Quando há o Commit deve forçar a escrita em disco (Flush). Write(T,item,valor): active_L = active_L È {T} Log (T, item, before_image) Escreve valor no cache Read(T,item): retorna fetch(item)

9 Commit(T): Para cada item do cache escrito por T Flush(item) commit_L = commit_L È {T} active_L = active_L - {T} Abort(T): Para cada item do cache ou do BD escrito por T copia a before_image do item (contida no primeiro registro do log referente à modificação do item por T) para o cache abort_L = abort_L È {T} Restart: Varre o log do fim para o início para cada entrada L se (L.T Ï commit_L) então copia L.before_image p/o cache para cada T se (T Î active_L e T Î commit_L)

10 Recuperação:Undo/Redo
Undo/Redo: Mais flexível: O controlador do buffer pool tem total liberdade para escrever os blocos p/o disco quando lhe convier. Write(T,item,valor): active_L = active_L È {T} Log (T, item, before_image, valor) Escreve valor no cache Read(T,item): retorna fetch(item) Commit(T): commit_L = commit_L È {T} active_L = active_L - {T} Abort(T): Para cada item do cache ou do BD escrito por T copia a T.before_image para o cache abort_L = abort_L È {T}

11 Recuperação: Undo/Redo
Restart: Undone = Æ Redone = Æ Varre o log do fim para o início para cada entrada L se (L.item Ï Redone) então se L.T Î commit_L então copia L.valor p/o cache Redone = Redone È {L.item} senão copia L.before_image p/o cache para cada T se (T Î active_L e T Î commit_L) active_L = active_L - {T}

12 Recuperação: No Undo/No Redo
Shadowing: Quando uma transação tem de modificar um item, o GR copia o bloco envolvido numa área livre do disco. Monousuário: dispensa log Copia-se (em disco) diretório no início da transação e mantém-se antigo (shadow) sem modific. Commit: descarta shadow Abort: descarta-se diret. corrente e novas páginas alocadas e diretório shadow volta a ser corrente

13 Recuperação: No Undo/No Redo
Vantagem: simplicidade na recuperação Desvantagens: Complica a ordenação física dos dados. Reaproveitar espaço de páginas antigas: Coleta de lixo necessária Mudanças de diretório (corrente e shadow) precisam ser atômicas Obs: com transações concorrentes logs e checkpoints são necessários