Início / dba / Perguntas / 278782
Accepted
Andrei Orlov
Asked: 2020-10-28 18:45:19 +0800 CST

É seguro confiar em transações no Firebird 2.5 Embedded DB em caso de queda de energia?

  • 772

Como é seguro dizer que a lista de ações a seguir nunca será refletida no banco de dados em caso de queda de energia em algum lugar no meio da linha 2, antes que a transação seja confirmada?

#1 begin transaction
#2 delete record in table A that cascade deletes another record in table B
#3 update another record in table C
#4 commit transaction
transaction firebird

1 respostas

  1. Best Answer

    Isso geralmente é seguro. O Firebird usa uma arquitetura MVCC (Multi-Version Concurrency Control). As atualizações (e exclusões) são gravadas como uma versão anterior e uma nova versão. A nova versão substitui a versão anterior e a versão anterior é um delta para recriar a versão anterior do registro da nova versão do registro. As exclusões são gravadas como uma versão de registro 'stub' que marca o registro como excluído.

    Cada versão é marcada com a transação que criou originalmente a versão do registro. Se essa transação não for confirmada, essa versão do registro não ficará visível. O Firebird seguirá a cadeia de ponteiros de versões anteriores do registro para encontrar a versão que é visível para a transação e reconstruir essa versão.

    Após uma falha ou outro encerramento abrupto, o Firebird em algum momento detectará que a transação não está ativa e a transação será marcada como revertida. Nesse momento, ou em algum momento posterior durante a coleta de lixo, o Firebird irá reescrever as versões de registro para tornar a última versão confirmada a 'nova' versão e eliminar versões anteriores desnecessárias.

    O fato de você ter uma exclusão em cascata em seu exemplo não é realmente relevante, desde que a consistência de registros individuais esteja correta.

    Como uma transação pode passar de Ativa para Revertida se sair de forma anormal?

    Isso pode acontecer de duas maneiras.

    1. Quando uma transação é iniciada, ela bloqueia seu próprio id de transação. Se uma transação (B) tentar atualizar ou excluir um registro e descobrir que a versão mais recente do registro foi criada por uma transação (A) cujo estado TIP é ACTIVE, a transação B tenta obter um bloqueio conflitante no ID de transação de A. Uma transação ativa mantém um bloqueio exclusivo em seu próprio id, e o gerenciador de bloqueio pode testar um bloqueio para ver se o proprietário ainda está ativo. Se o bloqueio for concedido, então B sabe que A morreu e altera o estado TIP de A de Ativo para Revertido.
    2. Quando uma transação é iniciada, ele verifica se pode obter um bloqueio exclusivo no banco de dados - se puder, nenhuma outra transação está ativa. Cada transação ativa possui um bloqueio compartilhado no banco de dados. Se obtiver um bloqueio exclusivo, ele converte todas as entradas de TIP Ativas em Revertidas.

    (de: Firebird for the Database Expert: Episódio 4 - OAT, OIT e Sweep )

    Para evitar a perda de dados, o Firebird emprega o que é chamado de estratégia de "gravação cuidadosa" para garantir consistência no disco, garantindo que os dados sejam gravados em uma ordem que mantenha as dependências entre as páginas de dados (e versões).

    O novo registro é escrito no mesmo lugar que o antigo, enquanto a versão anterior é escrita para reconstruir o antigo registro. Existem basicamente dois cenários:

    1. A nova versão e sua versão anterior se encaixam na mesma página de dados.

      Tanto a versão nova quanto a versão anterior são gravadas na imagem na memória da página e a página é gravada no disco.

      Nessa situação, o único modo de 'falha' real seria que a gravação do disco em si seja feita apenas parcialmente quando a energia falhar. Esse problema pode ser resolvido usando controladores de disco com uma unidade de bateria de backup (BBU) ou solução semelhante.

    2. A versão de trás não cabe na mesma página, e tem que ir em outra página de dados.

      A versão anterior e a nova versão são gravadas na imagem na memória de suas respectivas páginas. Como a nova versão depende da versão anterior (ela aponta para a versão anterior), a página com a versão anterior é gravada primeiro no disco, depois a página com a nova versão é gravada no disco.

      Se o processo terminar depois que a versão anterior for gravada, a versão anterior ficará órfã, mas a versão anterior do registro ainda estará intacta. Ele também tem o mesmo modo de falha que o anterior.

    Assim, em caso de falta de energia, ou outro tipo de encerramento do processo Firebird, isso significa que você possivelmente tem páginas órfãs (páginas alocadas mas ainda não cadastradas, ou páginas liberadas mas ainda não marcadas como disponíveis), ou registros órfãos ( uma versão anterior escrita, mas ainda não vinculada corretamente em uma cadeia de registros de versões). Essas páginas órfãs ou versões anteriores desperdiçam espaço, mas não afetam a consistência. Pode ser necessário usar o gfix para corrigir e recuperar o espaço desperdiçado dessa maneira.

    Dito isso, além de ter falhas no meio da gravação e sem BBU, acredito que haja cenários em que uma queda de energia deixa o banco de dados em um estado em que primeiro precisa ser reparado usando gfix, mas eu mesmo não encontrei esses cenários e posso realmente não penso em um agora.

    Tudo isso pressupõe que você tenha gravações síncronas (gravações forçadas) habilitadas em seu banco de dados Firebird (o padrão). Se você desabilitar as gravações síncronas, a gravação de páginas em disco é deixada para seu sistema operacional, e isso pode resultar em perda de dados, pois as páginas podem ser gravadas em uma ordem diferente, por exemplo, a nova versão foi gravada no disco, mas a versão anterior ainda não no momento da interrupção, então você perdeu essencialmente a versão confirmada da linha, as versões anteriores anteriores órfãs e o ponteiro da versão anterior da nova versão aponta para o lixo.

    Leitura adicional:

    • 2

relate perguntas