[firebase-br] Alerta FB DataGuard - Gap muito alto em transações

[Gladiston Santana]

Cleber, não exista nada dentro do firebird ou em suas configurações que
faça o firebird corromper.
O corromper só ocorre por falhas do SO ou do Hardware, incluindo interfaces
de rede.

Existe algumas situações que podem tornar viáveis as corrupções frequentes,
por exemplo, essa diferença entre que relatou entre a transação mais velha
ativa e a próxima podem causar perda de dados quando algo inesperado
ocorre. Então quanto menor essa diferença, melhor, tanto a segurança quanto
a performance.

Não tente fazer o sweep automático ou manual, isso não resolve o problema,
na realidade é o contrário, você limpa a possibilidade do próprio FB de
corrigir a si próprio usando o que ficou no limbo.
O sweep se limpa sozinho quando se realiza o backup com o gbak, pois
restaurar um backup é melhor do que contar com informações que ficaram no
limbo.

Deve haver um plano para tratar uma situação de corrupção, as vezes até com
um script automatizado salvando uma cópia do arquivo de dados e depois os
comandos para fazer o restore.

Sim, existem situações de programação que são perigosas. Por exemplo, já vi
alguns programas só fazerem o soft commit e ficam abertos por todo o
expediente do camarada dando um mundo de possibilidades para perda de
dados. Num exemplo recente, o programa era do jeito que falei e só  fazia
um hard commit (.Commit) ao ser fechado, contudo o programador não testou a
possibilidade do programa ser finalizado sem o fechamento convencional,
pois alguns de seus funcionários ao encerrar o expediente "dormiam" o
computador, enquanto outros optavam por desligar e deixavam o windows
encerrar os programas automaticamente. Isso só foi descoberto olhando o log
do servidor e observando umas conexões perdidas. É muito difícil
diagnosticar erros de lógica assim.

Na minha experiência, corrupção de dados tá ligado mais a hardware e
SO/programas. Voce se lembra de uma atualização da Microsoft que tirou
vários Windows do ar, e a culpa foi um plugin de banco? Pois é, a vida é
assim, qualquer programa instalado em seu servidor pode causar falhas em
outros, é por isso que Oracle, MSSQL dentre outros imploram por servidor
dedicado.

[]´s

Em 22 de agosto de 2013 19:28, Cleber Amaral <clebercbr em gmail.com> escreveu:

> Olá Rodrigo,
>
> Obrigado pela pronta resposta, estou monitorando o caso para entender
> melhor agora com esta explicação.
>
> Me corrija se estiver errado, não estou certo de que o sweep pode ajudar. O
> que compreendi é que este comando remove transações já finalizadas (entendo
> que são as que que deixaram o limbo). A OIT pensei ser uma transação ainda
> ativa, uma aplicação que abriu e não finalizou, que ainda estaria no limbo
> e não será removida pelo sweep.
>
> De qualquer forma um gap grande aponta uma provável falha na implementação
> de meu software. Me procupo também com o impacto disso nos ciclos de
> transações. Há pouco tempo estava utilizando o pagesize de 4k que limita as
> transações a 534 249 472, minha questão é: se cheguei a um gap de 26
> milhões, em vários meses de uso facilmente entre abrir e encerrar os
> incrementos absolutos já devem ter estourado o limite de 543 milhões e
> provavelmente o FB não trata bem quando o ponteiro NEXT alcança o OIT após
> girar o ciclo, provavelmente gerando corrução de dados.
>
> Bom, de imediato já estou aumentando o pagesize pra 8k em alguns clientes e
> iniciando a utilização de 16k também. Vou averiguar que transação pode
> estar ficando aberta por todo este tempo.
>
> Muito grato pela colaboração!
>
> Abs
>
>