o problema
Um banco de dados precisa sobreviver a três coisas: um processo que morre no meio de um update, o sistema inteiro que cai, e o disco que se perde. Até os anos 1980, uma resposta influente era shadow paging, usada no System R: a página modificada é escrita em outro lugar do disco, e a versão antiga fica guardada como estado consistente até o próximo checkpoint. Funciona, mas cobra caro — espaço, movimentação de páginas, checkpoints que perturbam o sistema inteiro, recovery de índice em lock-step com o recovery dos dados.
A alternativa é write-ahead logging com update in-place: você escreve o log antes, depois modifica a página onde ela já estava. O preço é que a página no disco vira uma fotografia de estado desconhecido. E o problema explode quando o lock é de registro, e não de página: duas transações não commitadas mexem na mesma página ao mesmo tempo, e o que está no disco é uma mistura das duas. Pior, um rollback interrompido por uma segunda falha deixa uma página meio desfeita. Os autores relatam o estrago concreto disso em sistemas reais: o IMS podia desfazer o mesmo registro de log várias vezes; DB2, AS/400 e NonStop SQL podiam desfazer as próprias compensações, o que “causou problemas sérios em situações de clientes reais”.
a ideia
ARIES separa duas perguntas que os métodos anteriores misturavam. A primeira: qual era o estado do banco no instante exato da falha? A segunda: o que desse estado precisa ser revertido?
A resposta à primeira é repetir a história. No restart, ARIES reaplica todas as atualizações registradas no log que não chegaram ao disco — sem perguntar se a transação commitou. Reconstruído o instante da queda, os perdedores são desfeitos exatamente como seriam num rollback de operação normal. Não é preciso adivinhar nada: o banco volta a um ponto que existiu de verdade, e o undo passa a ser rotina, não exceção.
A segunda peça é logar o undo. Cada ação desfeita gera um compensation log record, e um CLR nunca é desfeito. Ele carrega um ponteiro para o registro anterior ao que acabou de compensar, o que dá ao rollback uma memória de progresso própria.
como funciona
Toda página do banco tem um campo page-LSN com o endereço do último log record que a modificou. O log é uma sequência crescente de LSNs; cada registro aponta para o anterior da mesma transação via PrevLSN. O buffer manager só escreve uma página no disco depois que o log daquela página chegou a armazenamento estável.
O restart tem três passagens. A de análise varre do último checkpoint até o fim do log e reconstrói duas tabelas: a de transações, com quem estava em progresso e qual o próximo registro a desfazer para cada uma, e a de páginas sujas, com o RecLSN — o ponto do log a partir do qual pode haver updates ausentes do disco. O menor RecLSN vira o ponto de partida do redo.
O redo é condicional: para cada registro de update, se a página está na tabela de sujas e o page-LSN é menor que o LSN do registro, a atualização é reaplicada. Nada é logado aqui. O undo é incondicional e roda em uma única varredura para trás, pegando sempre o maior LSN pendente entre os perdedores. Ao encontrar um CLR, o undo não o compensa: usa o UndoNxtLSN para pular direto ao próximo registro que ainda falta desfazer.
Em cima disso vêm os detalhes que fazem o método servir a um sistema real: checkpoints fuzzy, que não param o sistema; savepoints, para rollback parcial; e nested top actions, em que uma sequência de ações estruturais — estender um arquivo, dividir uma página de índice — é fechada por um CLR dummy e passa a ser imune ao rollback da transação que a iniciou.
o que isso custou
Complexidade, e os autores dizem isso na cara: concorrência e recovery são assuntos difíceis, algoritmos complexos tendem a ser cheios de erro, e o artigo é longo porque as interações entre método de recovery, granularidade de lock e gerência de armazenamento não são independentes — não dá para escolher cada peça isolada e esperar que o conjunto funcione. Várias metas do projeto são explicitamente contraditórias, e o que existe é um conjunto de trade-offs escolhidos por experiência.
O método loga mais: toda ação de rollback vira registro. Refaz mais: reaplica até o que os perdedores escreveram. Exige um LSN em cada página e um buffer manager disciplinado, com a página latchada durante a chamada ao logger para que a ordem de log seja a ordem dos updates. O undo lógico, que é o que libera a alta concorrência, exige que o dado possa ser reencontrado — retravessar a árvore do índice para achar a chave que outra transação já moveu de página. E há um limite declarado: combinar modos de lock de alta concorrência como increment/decrement com índices definidos sobre esses mesmos campos “fica muito complicado”, e os autores dizem que ainda estavam estudando o caso.
onde isso aparece hoje
ARIES não é um sistema; é o vocabulário. Page-LSN, dirty pages table, analysis/redo/undo, CLR: quem lê o código de recovery de um banco relacional hoje encontra esses nomes. Os próprios autores listam implementações em graus variados no DB2, no OS/2 Extended Edition Database Manager, no Starburst, no QuickSilver e nos protótipos EXODUS e Gamma, de Wisconsin.
A regra de escrever no log antes de tocar na estrutura atravessa desenhos muito diferentes do original, do log-structured merge-tree aos bancos de nuvem que empurram a ideia ao extremo e tratam o redo log como a própria unidade de replicação, como em Amazon Aurora.