A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

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

Apresentações semelhantes


Apresentação em tema: "1 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 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 commits 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 2 Flush e Write Fetch ReadWrite Buffer pool Gerente de Recuperação Arquivo de LOG BD Gerente de Recuperação 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 Ger. Log ReadWrite

3 3 A estrutura do Log 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 :::::: –O que é um item no log? Pode-se colocar todo o bloco => perdulário Apenas a parte modificada (N o 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. Tempo

4 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 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). Transações T1T1 T2T2 T3T3 T4T4 T5T5 Check Point Falha ttc tf 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 6 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 Estratégias de Recuperação 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 7 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 Recuperação: No Undo/ Redo (cont.)

8 8 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) Recuperação: Undo/No Redo

9 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 10 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} active_L = active_L - {T} Recuperação:Undo/Redo

11 11 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} Recuperação: Undo/Redo

12 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 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


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

Apresentações semelhantes


Anúncios Google