Este parâmetro está disponível para utilização apenas em caso de emergência, e não deveria ser necessário. O objetivo de sua existência é permitir que seja extraída de um banco danificado tanta informação quanto possível, que de outra maneira estaria perdida.
Sua utilização deve ser considerada apenas se a opção de retorno do backup do banco não for possível.
Neste post não será abordado o efeito da utilização do parâmetro –F em conjunto com o proshut ou com o promon.
Um banco Progress sempre deve ser considerado como a soma dos arquivos de dados .db (.db, .d1, .d2, etc), dos arquivos de before image (.bi, .b1, .b2, etc), e dos dados que estão em memória.
Quando um banco é fechado de maneira anormal (ex., queda de energia), os dados que estavam em memória são perdidos, juntamente com as atualizações que ainda não haviam sido gravadas em disco.
Quando o banco é iniciado novamente o processo de rollback é executado. Este processo é executado em 2 partes:
- Redo phase:
Em virtude do Progress se utilizar da técnica de write-ahead logging para otimizar as gravações em disco dos arquivos de dados do banco (.d1, .d2,etc), algumas transações que já foram concluídas quando o crash do banco ocorreu já podem ter sido gravadas nos arquivos de before image (.b1, .b2, etc), porém não nos arquivos de dados do banco. Isto é o comportamento normal. Durante o processo de redo o gerenciador do banco progress percorre os 2 clusters mais recentes do before image para garantir que todas as transações concluídas foram gravadas nos arquivos de dados do banco. Mensagens de início e finalização do processo de redo são gravadas no arquivo de log.
- Rollback:
Concluído o processo de redo, o Progress percorre o arquivo de before image em sentido contrário procurando por transações que foram inciadas, porém, não foram concluídas antes da queda do banco. Toda transação incompleta é desfeita, sendo que isto é possível graças às informações registradas no before image.
Utilizar o parâmetro –F:
Quando o acesso ao banco é forçado, as fases de redo e rollback são desconsideradas; e o arquivo de befeore image é reconstruído do zero, de maneira que as informações necessárias para as fases de redo e rollback são permanentemente perdidas.
Podemos então concluir que o banco de dados está em um estado inconsistente:
- como a fase de redo foi desconsiderada, algumas transações que estavam concluídas quando o crash do banco aconteceu podem não ter sido gravadas nos arquivos em disco do banco de dados. Pior do que isso seria o fato de terem sido apenas parcialmente gravadas.
- como a fase de rollback também foi desconsiderada, transações que ainda não haviam sido concluídas no momento em que o crash aconteceu não serão desfeitas. As consequências incluem:
. registros não atualizados de maneira completa
. registros parcialmente excluídos
. fragmentos de registro fazendo referência a outros fragmentos não existentes
. registros que não estão nos índices
. índices fazendo referência a registros que não existem
. incosistência nas listas de blocos RM (utilizadas para alocar espaço para novos registros)
. Inconsistências lógicas devido a gravação parcial de transações. Estas situações nem sempre são visíveis de imediato. Por exemplo, a existência de um registro que foi apenas parcialmente criado apenas é revelada quando ele é acessado e um erro é apresentado.
Inconsistências lógicas podem ser reparadas apenas através de uma revisão de todos os valores em todos os registros avaliando se estão corretos, se não falta nenhum registro, e se não existem registros duplicados. Isto, em geral, consome muito tempo para ser realizado.
. Inconsistências físicas nas estruturas de índice podem ser consertadas pela reconstrução dos índices utilizando a reindexação offline. Neste processo os blocos de índice são primeiramente eliminados , sendo em seguida recriados utilizando os valores das chaves de registros.
No entanto, índices do metaschema do banco não podem ser reconstruídos desta maneira. O fato é que com o schema corrompido as informações do banco não podem ser exportadas com confiança, nem pelo processo de dump. Este é o pior cenário, mas é possível.
Porém, inconsistências físicas em registros de dados (inclusive nos registros que descrevem as tabelas do dicionário) não podem ser reparadas. Nestes casos, quando possível, é necessário remover manualmente os registros danificados.
Considerando o que foi exposto, voltar um backup é uma opção muito melhor do que tentar reparar um banco utilizando o parâmetro –F.
Este post foi criado com base no Kbase Progress P24330 em complemento à série “Como funciona o arquivo primário de recuperação (BI)”.
Assinar feeds (RSS)