Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
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.
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. 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.
Em cada fluxo, o CLFS controla dois LSNs especiais: o LSN base e o LSN final. Além disso, cada registro de log individual tem dois LSNs especiais (o LSN anterior e o próximo LSN de desfazer) que podem ser utilizados para formar cadeias de registros de log interligados. As seções a seguir descrevem esses LSNs especiais em detalhes.
Base LSN (Número de Sequência de Log)
Quando um cliente grava o primeiro registro em um fluxo de dados, o CLFS define o valor de LSN base igual ao 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.
Se um fluxo tiver uma cauda de arquivo, a parte ativa do fluxo começará no registro apontado pelo LSN base ou pela cauda de arquivo, o que for menor. Para obter mais informações sobre o arquivamento, consulte o suporte do CLFS para arquivamento.
LSN anterior
Suponha que duas transações de banco de dados ativas (transação A e 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 ao definir o LSN anterior de cada registro de log que é gravado.
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 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 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. 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 esta 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 próximo LSN de desfazer de cada CLR para o predecessor do registro de log (entre os registros escritos pela transação) cuja atualização foi revertida (desfeita). Neste exemplo, o LSN de desfazer-próximo do registro 5' é o LSN do registro 4 e o LSN de desfazer-próximo do registro 4' é o LSN do registro 3.
Os registros de log comuns (que não são CLRs) têm seus próximos LSNs de desfazer definidos como o registro de log anterior gravado pela transação. Ou seja, para um registro comum, o próximo LSN para desfazer e o LSN anterior são os mesmos.
Agora suponha que haja uma falha no 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-seguinte do registro 6 e descobre que ele aponta para o registro 4'. Os dados no registro 4' indicam que é um CLR, portanto, o código de recuperação não reverte a atualização 4'. Em vez disso, inspeciona o LSN próximo a desfazer do 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. As atualizações 5 e 4 não são revertidas durante a recuperação porque já foram revertidas durante o processamento normal. Por fim, o código de recuperação reverte as atualizações 2 e 1.
O diagrama a seguir ilustra como o undo-next LSN fornece um mecanismo que o código de recuperação pode usar para ignorar registros cujas atualizações já estão desfeitas.
