Firebird

Estamos com problemas no controle transacional e isso faz com que o trabalho para o garbage colector cresça cada vez mais, utilizamos a ferramenta sinática monitor que nos mostra o andamento do garbage colector, visto que quando a diferença entre OAT (Oldest Active Transaction) e a OIT (Oldest Interesting Transaction) chega (por incrível que pareça) na casa dos 120.000 o telefone começa a tocar com reclamações de lentidão, então como de praxe ação tomada é:
01 – Resolver o problema;
02 – Resolver a causa do problema;
Enquanto uma equipe estuda as causas deste problema para ter uma solução definitiva, a solução temporária aplicada foi usar o SQL:
SELECT * FROM MON$ATTACHMENTS WHERE MON$ATTACHMENTS.MON$STATE = 0
Para listar as conexões que estavam inativas, tentávamos avisar aos usuários para fechar o sistema, mas na maioria dos casos não localizamos os mesmos, sendo assim, estes que ainda mantinham a conexão usávamos o SQL:
DELETE
FROM MON$ATTACHMENTS WHERE MON$ATTACHMENT_ID = :IDCONEXAO
Para finalizar esta conexão, porém ocorreu que após algum tempo o sistema ficou MUITO LENTO a ponto de uma nova conexão levar cerca de 20 minutos para estabelecer por sorte este problema começou as 16:30 sendo assim este caos durou 01:30, ou seja, as 18:00 a empresa fechou, ai começamos o trabalho árduo para descobrir a causa e solucionar, sem ter embasamento técnico para afirmar resolvemos apostar na idéia de que o uso “constante” do “delete from mon$attachments” ocasionou algum problema com a base, portanto tomamos algumas ações que foram:
1) Realizar backup da base;
2) Trocar o sistema operacional do servidor de 32 para 64 bits;
3) Instalar o firebird na versão 64bits;
4) Restaurar a base de dados usando a versão 64bits do firebird;
Bom, com estas ações no dia seguinte conseguimos uma melhora considerável, mas ainda longe do que desejamos, sendo assim, os estudos continuaram; rodamos o comando: gstat banco.fdb -a -r -user sysdba -pas xxxx > stat.txt