Números de sequência de log CLFS

No CLFS (Common Log File System), cada registro de log em um determinado fluxo é identificado exclusivamente por um LSN (número de sequência de log). Ao gravar um registro em um fluxo, você recebe de volta um LSN que identifica esse registro para referência futura.

Os LSNs criados para um fluxo específico formam uma sequência estritamente crescente. Ou seja, o LSN atribuído a um registro de log em um determinado fluxo é sempre maior do que os LSNs atribuídos aos registros de log gravados anteriormente nesse mesmo fluxo. As funções a seguir estão disponíveis para comparar os LSNs de registros de log em um determinado fluxo.

ClfsLsnNull

ClfsLsnEqual

ClfsLsnGreater

ClfsLsnLess

As constantes CLFS_LSN_NULL e CLFS_LSN_INVALID são os limites inferior e superior para todos os LSNs válidos. Qualquer LSN válido é maior ou igual a CLFS_LSN_NULL. Além disso, qualquer LSN válido é estritamente menor que CLFS_LSN_INVALID. Observe que CLFS_LSN_NULL é um LSN válido, enquanto CLFS_LSN_INVALID não é um LSN válido. Mesmo assim, você pode comparar CLFS_LSN_INVALID com outros LSNs usando as funções na lista anterior.

Para cada fluxo, o CLFS controla dois LSNs especiais: o LSN base e o último LSN. Além disso, cada registro de log individual tem dois LSNs especiais (o LSN anterior e o LSN de desfazer o próximo) que você pode usar para criar cadeias de registros de log relacionados. As seções a seguir descrevem esses LSNs especiais em detalhes.

Base LSN

Quando um cliente grava o primeiro registro em um fluxo, o CLFS define o LSN base para o LSN desse primeiro registro. O LSN base permanece inalterado até que um cliente o altere. Quando os clientes do fluxo não precisam mais dos registros antes de um determinado ponto no fluxo, eles podem atualizar o LSN base chamando ClfsAdvanceLogBase ou ClfsWriteRestartArea. Por exemplo, se os clientes não precisarem mais dos cinco primeiros registros de log, eles poderão definir o LSN base para o LSN do sexto registro.

Último LSN

À medida que os clientes gravam registros em um fluxo, o CLFS ajusta o último LSN para que seja sempre o LSN do último registro gravado. Se os clientes não precisarem mais dos registros após um determinado ponto no fluxo, eles poderão atualizar o último LSN chamando ClfsSetEndOfLog. Por exemplo, se os clientes não precisarem mais de registros gravados após o décimo registro, eles poderão truncar o fluxo definindo o último LSN para o LSN do décimo registro.

Parte ativa de um fluxo

A parte ativa de um fluxo é a parte de um fluxo que começa com o registro apontado pelo LSN base e termina com o registro apontado pelo último LSN. O diagrama a seguir ilustra como o LSN base e o último LSN delineam a parte ativa de um fluxo.

Nota Se um fluxo tiver uma cauda de arquivo morto, a parte ativa do fluxo começará no registro apontado pelo LSN base ou pela parte final do arquivo morto, o que for menor. Para obter mais informações sobre arquivamento, consulte Suporte do CLFS para arquivamento.

LSN anterior

Suponha que duas transações de banco de dados ativas (transação A e transação B) estejam gravando registros no mesmo fluxo ao mesmo tempo. Sempre que a transação A grava um registro, ela define o LSN anterior do registro para o LSN do registro de log anterior gravado pela transação A. Isso forma uma cadeia de registros de log, pertencente à transação A, que pode ser percorrida em ordem inversa. A cadeia termina com o primeiro registro de log gravado pela transação A, que tem seu LSN anterior definido como CLFS_LSN_INVALID. Da mesma forma, a transação B cria sua própria cadeia de registros de log definindo o LSN anterior de cada registro de log que grava.

As setas no diagrama a seguir ilustram como o LSN anterior de um registro de log aponta para o registro anterior em uma cadeia que pertence a uma transação específica.

Desfazer o próximo LSN

Suponha que uma transação faça cinco atualizações em um objeto de dados em memória volátil, reverta a quarta e a quinta atualizações e faça uma sexta atualização. À medida que a transação faz as atualizações, ela grava os registros de log 1, 2, 3, 4, 5, 5', 4' e 6. Os registros de log de 1 a 5 descrevem as alterações feitas pelas atualizações de 1 a 5. O Registro 5' descreve as alterações feitas durante a reversão da atualização 5 e o registro 4' descreve as alterações feitas durante a reversão da atualização 4. Por fim, o registro 6 descreve as alterações feitas pela atualização 6. Observe que os números 1, 2, 3, 4, 5, 5', 4' e 6 não são os LSNs dos registros de log; são apenas números usados para nomear os registros de log para fins desta discussão.

Os registros de log 5' e 4', que descrevem reversões, são chamados de CLRs (registros de log de compensação). A transação define o LSN de desfazer-próximo de cada CLR como o predecessor (entre os registros gravados pela transação) do registro de log cuja atualização acabou de ser revertida (desfeita). Neste exemplo, o LSN de desfazer o próximo registro 5' é o LSN do registro 4 e o LSN de desfazer o próximo registro 4' é o LSN do registro 3.

Os registros de log comuns (aqueles que não são CLRs) têm seus LSNs de desfazer-próximo definidos como o registro de log anterior gravado pela transação. Ou seja, para um registro comum, o LSN de desfazer e o LSN anterior são os mesmos.

Agora suponha que haja uma falha do sistema e, durante a recuperação de reinicialização, toda a transação deve ser revertida. O código de recuperação lê o registro de log 6. Os dados no registro 6 indicam que o registro 6 é um registro comum (não um CLR), portanto, o código de recuperação reverte a atualização 6. Em seguida, o código de recuperação inspeciona o LSN de desfazer o próximo registro 6 e descobre que ele aponta para o registro 4'. Os dados no registro 4' indicam que ele é um CLR, portanto, o código de recuperação não reverte a atualização 4'. Em vez disso, ele inspeciona o LSN de desfazer o próximo registro 4' e descobre que ele aponta para o registro 3. O Registro 3 não é um CLR, portanto, o código de recuperação reverte a atualização 3. Atualizações 5 e 4 não são revertidos durante a recuperação porque já foram revertidos durante o processamento de encaminhamento comum. Por fim, o código de recuperação reverte as atualizações 2 e 1.

As setas no diagrama a seguir ilustram como o LSN de desfazer próximo fornece um mecanismo que código de recuperação pode usar para ignorar registros cujas atualizações já foram revertidas.