Cap. 21 - Recuperação

1. Cap. 21 - 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 Gerente de Recuperação Ger. Log Buffer pool Arquivo de LOG BD Flush e Write Fetch Write Read Read Write • 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. T1 Item Valor Ant Valor T2 Item Valor Ant Valor T3 Item Valor Ant Valor T1 Item Valor Ant Valor T3 Item Valor Ant Valor A estrutura do Log : : : Tempo • 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. 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 Grav. em Disco a Partir do Cache

5. 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). Check Points 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} active_L = active_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) active_L = active_L - {T}

10. Undo/Redo: Mais flexível: O controlador do buffer pool tem total liberdade para escrever os blocos p/o disco quando lhe convier. Recuperação:Undo/Redo 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} active_L = active_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. 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 Recuperação: No Undo/No Redo

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