BD II (SI 587) Algoritmos de recuperação Avançado e ARIES Josenildo Silva jcsilva@ifma.edu.br
Nota Estes slides são baseados nos slides disponibilizados pelo autor SILBERSCHATZ, para o livro Sistemas de Banco de Dados, 5ª. Edição, Ed. Elsevier. Capítulo 17. Sistema de Recuperação.
Algoritmo de Recuperação Avançada
Principais características Técnicas com alta taxa de concorrência Suporta UNDO lógico Recuperação baaseada em história repetida -- repete ações como no processamento normal Refaz logs de transações incompletas e REDOs Mais fácil de entender e demontrar a corretude
UNDO Lógico Operações nos índices como inserções em árvores B+ libera bloqueios mais cedo Não podem ser desfeitos simplesmente restaurando os valores (UNDO físico), pois outras transações podem ter atualizado a árvore B+ Ao invés disto, inserções (e deleções) são desfeitas através de operações de deleção (e inserção), que é o UNDO lógico
UNDO Lógico Para tais operações, o log de UNDO deve incluir a operação de UNDO correspondente Exemplos: Log inserção para desfazer deleção Log deleção para desfazer inserção Log subtração para desfazer adição etc.
REDO físico A informação de REDO é fisicamente armazenada no log REDO lógico é complicado, pois os estados do disco podem não ser consistentes quando a recuperação inicia REDO físico não conflita com liberação mais cedo dos bloqueios
Log de operações No inicio, grava <T i, O j, operation-begin> O j é um id para a operação. Durante a execução, grava logs normais com informações de REDO físico Ao final, grava <T i, O j, operation-end, U> U contém a informação para o UNDO lógico
Exemplo de log Inserir valores (K5, RID7) no index I9 <T1, O1, operation-begin>. <T1, X, 10, K5> <T1, Y, 45, RID7> Passos para o REDO físico na inserção <T1, O1, operation-end, (delete I9, K5, RID7) > Informação para UNDO lógico
Log de operações Se a falha acontece antes de completar a operação: O log de fim de operação não é encontrado e a informação de UNDO físico é utilizada Se a falha ocorre depois de completar a operação: O log de fim de operação é encontrado e a operação de UNDO lógico é realizado com a informação U A informação de UNDO físico é ignorada neste caso
Log de operações Operação de REDO após a falha ainda usa informação de REDO físico
Rollback de transação Percorre o log de trás para frente. Se encontrar um registro de log <Ti, X, V1, V2> faça o UNDO e registre <Ti, X, V1 >, chamado REDO-only Registros REDO-only não tem id de operação Se encontrar <Ti, Oj, operation-end, U> use U para rollback lógico
Rollback de transação Atualizações durante o rollback são logadas normalmente Ao fim do rollback, registre <Ti, Oj, operation-abort> Ignore outras operações de Ti até <Ti, Oj operation-begin>
Rollback de transação Ignore os registros REDO-only durante a recuperação Se encontrar um registro <Ti, Oj, operationabort> ignore todos os registros de Ti até encontrar <Ti, Oj, operation-begin> Pare a recuperação ao encontrar <Ti, start> e adicione <Ti, abort> ao log
Rollback de transação REDO-only e operation-abort só são encontrados se ouver falha durante um rollback de transação O registro operation-abort evita que uma mesma operação tenha multiplos rollbacks.
Exemplo de Rollback <T1, start> <T1, O1, operation-begin>. <T1, X, 10, K5> <T1, Y, 45, RID7> <T1, O1, operation-end, (delete I9, K5, RID7)> <T1, O2, operation-begin> <T1, Z, 45, 70> Crash!
Exemplo de Rollback <T1, start> <T1, O1, operation-begin>. <T1, X, 10, K5> <T1, Y, 45, RID7> <T1, O1, operation-end, (delete I9, K5, RID7)> <T1, O2, operation-begin> <T1, Z, 45, 70> // O Rollback de T1 começa aqui <T1, Z, 45> // Registros redo-only durante o UNDO físico de O2 <T1, Y,..,..> // Redo normal para UNDO lógico de O1 <T1, O1, operation-abort> // E se o crash acontecer depois deste ponto? <T1, abort>
Recuperação após falha do sistema Fase de REDO: pesquisa o log do ultimo <checkpoint L> até o fim do log. Repita a história fazendo REDO físico de todas as transações Crie uma lista UNDO, adicionando Ti se encontrar <Ti, start> e deletando se encontrar <Ti, commit> ou <Ti, abort> Nesta fase todas as transações foram refeitas A lista de UNDO contém as transações incompletas
Recuperação após falha do sistema Fase de UNDO: percorra o log de trás para frente, fazendo UNDO das transações da lista UNDO Faça log durante o rollback como distido anteriormente Se encontrar <Ti, start> adicione um <Ti, abort> no log Esta fase desfaz efeiots de transações incompletas. Isto completa o processo de recuperação
Algoritmo ARIES
ARIES Estado da arte em recuperação Incorpora várias otimizações para acelerar o processo de recuperação O algoritmo avançado é uma simplificação do ARIES
ARIES ARIES identifica registros com log sequence number (LSN) Os LSN são armazenados em páginas para indicar quais atualizações foram aplicadas a uma página do BD Utiliza REDO fisiológico Utiliza tabela de página suja para evitar REDOs desnecessários na recuperação
REDO Fisiológico A página afetada é identificada fisicamente. A ação pode ser lógica. Requer que páginas sejam transferidas para o disco de maneira atomica Hardware RAID e alguns sistemas de disco Tranferencias de páginas incompletas podem ser detectadas por checksum e é tradada como falha
Estruturas de dados do ARIES Página de LSNs Possui um pagelns Diferentes tipos de registro de log Tabela de página suja
Página de LNS Cada página contém um pagelns (ultimo LNS que afetou a página) Para atualizar a página de LNS Bloqueia (latch) pra escrita e escreve no log Atualiza a página Atualiza o valor de PageLNS da página Desbloqueia a página
Página de LNS Para transferir a página para o disco Blqueio (s-latch) compartilhado O estado da página no disco é consistente para operações PageLSN é utilizado durante a recuperação para prevenir REDO repetido
Registros de Log Cada registro tem o LSN do registro anterior da mesma transação. Um log espcial REDO-only chamado de registro de compensação é utilizado durante a recuperação e que não precisa ser desfeito. Serve como operation-abort usado no algoritmo avançado Possui um campo UndoNextLSN para indicar o próximo registro a ser desfeito. Isto evita REDOs repetidos
Tabela DirtyPage Lista de páginas no buffer que foram atualizadas Contém (para cada página) PageLSN da página RecLSN é o LSN da primeira operação que tornou a página suja
Tabela DirtyPage Memória Disco P1 25 P6 16 P23 19 Page LSNs on disk P15 9 Page PLSN RLSN P1 25 17 P6 16 15 P23 19 18 Buffer Pool P1 16 P6 12.. P15 9.. P23 11 DirtyPage Table
Log de Checkpoint Registro de Checkpoint contém Tabela DirtyPage e a lista de transações ativas no momento do checkpoint Para cada transação T i registra LastLSN, o LSN do ultimo registro de log escrito por T i Registro do utimo checkpoint completado Páginas sujas não são escritas durante o checkpoint, mas em background
Fases do ARIES Fase de Análise Identifica quais transações serão desfeitas, quais páginas estão sujas, e o RedoLSN Fase de Redo Repete a história, refazendo todas as operações a partir de RedoLSN Fase de Undo Desfaz todas as transações incompletas e que ainda não foram abortadas
Fases do ARIES Análise determina onde o REDO deve começar UNDO tem que voltar até a operação incompleta mais antiga Tempo Ultimo checkpoint Fim do Log Log Redo pass Analysis pass Undo pass
Fase de Análise Começa a partir do ultimo checkpoint completo Lê tabela de DirtyPage no registro de log Atualiza RedoLSN = min RecLSN de todas as página na tabela de DirtPages Se nehuma página está suja, RedoLSN = LSN do registro de checkpoint Lê LSN do ultimo registro de cada transação na lista UNDO do registro de checkpoint
Fase de Análise (Cont.) Faz uma busca a partir do checkpoint Adicione transações na lista UNDO Se necessário, adicione página à DirtyPage, RecLSN = LSN da atualização Se encontrar fim de transação, remova a transação da lista UNDO Armazene o ultimo registro para cada transação na lista UNDO
Fase de Análise (Cont.) Ao final da análise RedoLSN determina onde começar o REDO RecLSN de cada página na tabela DirtyPage é utilizado para minizar o trabalho de REDO Todas as transações que estão na lista UNDO precisam ser desfeitas (rollback).
Fase de REDO Repete a história das operações Começa a partir de RedoLSN. Se encontrar um registro de atualização, faça: Ignore a operação se a página não está suja se LSN < RecLSN Se não, leia a página do disco. Se PageLSN < LSN entao refaça Obs: Se ambos os testes forem negativos é porque os efeitos da transação já estão registrados no disco.
Ações de UNDO no ARIES Quando um UNDO é realizado para um registro de atualização Gere um CLR contendo a ação UNDO realizada CLR para um registro n é denotado por n' na figura abaixo No CLR faça UndoNextLSN = PrevLSN do registro de atualização 1 2 3 4 4' 3' 5 6 6' 5' 2' 1'
Rollback parcial. Desfaz apenas parcialmente até liberar os bloqueios necesários Na figura abaixo, registros 3 e 4 são desfeitos e depois 5 e 6, e por fim, rollback total 1 2 3 4 4' 3' 5 6 6' 5' 2' 1'
Fase de UNDO Percorre o log do fim para o início desfazendo transações da lista UNDO Ignora registros desnecessários
Fase de UNDO O próximo LSN a ser desfeito é o RecLSN encontrado na fase de análise Para cada passo, escolha o maior LSN, e desfaça-o Depois de desfazer um registro do log, o próximo LSN a ser desfeito é indicado por PrevLSN. Para CLR o proximo LSN é o UndoNextLSN
Fase de UNDO Outros registros são ignorados pois já devem ter sido desfeitos As operações de UNDO são realizadas como descrito nos slides anteriores
Outras características do ARIES Independência de recuperação Páginas podem ser recuperadas independente umas das outras Ex: se uma página falhar, pode ser recuperada de um backup enquanto as outras podem continuar a ser utilizadas normalmente
Outras características do ARIES Savepoints Transações podem registrar savepoints e desfazer até o savepoint Utilizado em transações complexas Também utilizado para fazer rollback parcial no tratamento de deadlocks
Outras características do ARIES Bloqueio de baixa granularidade Permite bloqueio ao nível de tuplas em índices Requer UNDO lógico