Consultor Eletrônico

Durante a truncagem do bi, existe um processo que é executado no qual é tratada toda a shared memory perdida pelo banco. É nesse processo que o banco sai efetivamente da memória.

Quando um banco sofreu alguma transação grande, a quantidade de dados registrada na hash table também será grande, conforme as capacidades de memória e buffer do servidor.

Quando é efetuada a solicitação de shutdown do banco, a shared memory por ele utilizada é liberada da memória. Caso o processo não consiga derrubar as informações de algum usuário, o espaço em shared memory utilizado por ele fica preso.

No momento da truncagem do bi, o processo lança sinais de encerramento de processos para eliminar efetivamente essas informações. Esse é o motivo da espera de 60 segundos antes do início da truncagem.

O tratamento da shared memory ocorre de forma a liberar blocos da shared memory para reaproveitamento, conforme sua LRU (List Recent Used).

Esse processo, conhecido como "eviction", é baseada em uma pesquisa para definir a posição de um dado na shared memory. O erro que ocorreu, significa que a pesquisa efetuado não apontou para a informação esperada. Dessa maneira o Progress detectou que o processo estava corrompido, podendo abortar essa operação.

Isso pode ocorrer quando se utiliza o parâmetro -G na truncagem do .bi, ou desligar o servidor antes de truncar o bi, não eliminando completamente a shared memory. Assim, no momento de truncá-lo, existem informações apontando para uma shared memory inexistente.

Também pode haver casos onde outros aplicativos acessem a memória utilizada pelo banco, podendo corrompê-la, ou mesmo alguma falha do Progress, o que nesse caso, consideramos mais difícil.

Caso não seja possível truncar o .bi novamente, deve ser feito um backup do banco, reiniciado o servidor e truncado o banco com o parâmetro -F. Se isso também não resolver, deve-se conectar esse banco em modo monousuário (-1) com os parâmetros -RO e -i, e proceder um dump-load dessa base.