As informações de redo dos logs de compensação correspondem às informações de undo da entrada de log que tornou necessária sua criação durante a fase de undo.
Isso me parece que as informações de refazer dos CLRs são as mesmas que as informações de desfazer dos logs que os desencadearam.
Mas não deveria ser que eles tenham a informação REDO para cancelar as operações UNDO executadas no caso de um processo de recuperação interrompido?
Aqui está um exemplo:
seja T2 uma transação perdedora:
<#55, T2, P3, J=J+9, J = J-9, #53>
J=J+9 é o redo-op e J = J-9 é o undo-op.
Agora, o CLR anexado ao arquivo de log durante a fase de redo seria:
<#56, T2, J=J-9,__, #53>
Com J=J-9 sendo a operação de desfazer da entrada de log original como as informações de redo no CLR. Caso a recuperação seja interrompida, o log-entry #56 será executado durante a fase de redo.
O objetivo do CLR é garantir que reiniciar o processo de recuperação e executá-lo novamente sempre leve ao mesmo resultado. Como a execução da operação J=J-9 durante a fase de refazer da reexecução garante isso?
Alguém por favor pode me explicar isso?
Os registros de log de compensação (CLRs) não são gravados no log durante a operação normal. Eles são produzidos durante o processamento de uma reversão, solicitada pelo aplicativo ou devido a uma falha. Uma vez que seu único uso é durante uma reversão, eles precisam apenas reter informações suficientes para executar essa ação, ou seja, J=J-9 do exemplo. Cada CLR é emparelhado com seu registro de log original correspondente por meio de uma referência LSN.
A finalidade da fase de recuperação de refazer é retornar o banco de dados ao estado em que estava no momento da falha. Se essa falha ocorreu no meio de uma recuperação, a fase de refazer da segunda recuperação deve deixar o banco de dados como estava no meio da primeira recuperação. A fase de refazer da segunda recuperação processa os CLRs escritos pela fase de desfazer da primeira recuperação. Como os CLRs estão vinculados aos registros de log de atualização originais, saber o último CLR processado informa à fase de desfazer da segunda recuperação para qual registro de log pular para concluir a reversão.
Para usar o exemplo dado, a primeira fase de desfazer da recuperação processará a ação de desfazer do registro de log #55 (J = J-9) e criará o CLR #56. Em seguida, ele irá retroceder para o registro vinculado anterior (#53). Digamos que travamos antes de ser processado. A segunda fase de refazer da recuperação processará a operação do CLR #56. Se este for o último CLR, a segunda fase de desfazer da recuperação seguirá o link de volta para #53 e concluirá a reversão a partir daí. Efetivamente o nº 56 substitui o nº 55 durante a segunda e as recuperações subsequentes.
Então, por que se preocupar com tudo isso? Por que a segunda recuperação não pode simplesmente fazer exatamente o que a primeira recuperação fez? Como Áries assume um gerenciador de buffer usando roubar, nenhuma política de força. Durante a primeira recuperação, uma página pode ter sido parcialmente revertida e depois retirada do buffer pool. Portanto, a segunda recuperação não está começando do mesmo estado persistente que a primeira, portanto, ela não pode simplesmente executar as mesmas ações uma segunda vez.