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

Cleber Amaral clebercbr em gmail.com
Qui Ago 22 19:28:17 -03 2013


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


--
Cleber Jorge Amaral
克莱贝尔
-----------------------------------------------------------------
Celular: (48) 8426-9006 - Skype: clebercbr
MSN: clebercbr em msn.com
gTalk: clebercbr em gmail.com
Twitter: twitter.com/clebercbr
-----------------------------------------------------------------
Antes de imprimir, pense em sua
responsabilidade com o MEIO AMBIENTE.
-----------------------------------------------------------------


Em 22 de agosto de 2013 09:53, Rodrigo Gomes da Silva
<rodrgomes em gmail.com>escreveu:

> Esta diferenca entre o OIT (Oldest Interesting Transaction) e Next
> Transaction não causa problemas graves, apenas perda de desempenho. O fato
> do OIT estar baixo, é que a transacao indicada pelo OST (Oldest Snapshot
> Transaction) esta aberta a um periodo grande criando este gap de transacoes
> entre a mais antiga valida e a atual.
>
> Resumindo, o problema deve ser com algum programa usando o firebird que
> iniciou uma transação e esta com ela aberta a dias... Para diminuir o gap
> de modo rapido basta reiniciar o firebird que ira aumentar a OST e a OAT
> para a proxima transcacao. Apos disto caso o OIT continuar baixo e o sweep
> automatico estiver desligado basta rodar um sweep manual que elimina o gap.
>
> Esta seria uma solução só pra tirar este gap grande q se formou. Se tem
> esta transacao aberta é bem possivel que seja algo com a aplicação que
> teria de ser alterada para nao deixar esta transacao aberta por tempo
> indefinido e o problema pode voltar a ocorrer.
>
>
>
> Em 21 de agosto de 2013 00:15, Cleber Amaral <clebercbr em gmail.com>
> escreveu:
>
> > Prezados,
> >
> > Estamos experimentando o FBDataGuard e estamos com algumas dúvidas
> > para aprimoramento de nossa aplicação.
> >
> > Estamos tendo muito problema com o banco a ponto de estarmos realmente
> > preocupados se o FB é adequado a nossa aplicação. Hoje usamos o 2.1.
> > Tenho em especial um cliente que possui nosso sistema que é composto
> > por um serviço windows que se comunica com dispositivos eletrônicos
> > via TCP, há 115 dispositivos (tratados individualmente em threads) e
> > mais a interface de software do servidor e algumas poucas máquinas
> > clientes. Isso faz com que tenhamos uma média de 120 conexões
> > simultâneas e os dispositivos acessam o banco com frequencia, são
> > usados em catracas e portas para controle de acesso de usuários em
> > tempo real. Há algumas semanas o banco estava corrompendo muito
> > facilmente durante a aplicação, foi quando alteramos o pagesize de 4
> > pra 8k (o que já estava em tempo pelo que descobrimos!).
> >
> > Estamos acompanhando agora o log do dataguard para vermos o que mais
> > podemos fazer. Passar pro 2.5 e aumentar o pagesize pra 16 será
> > testado agora. Mas acredito que o dataguard já possa estar nos
> > alertando sobre mais riscos.
> >
> > O sistema está alertando sobre um gap muito alto em transações
> > conforme exemplo de msg:
> > Transactions: IMPORTANT [Last run: 47 sec ago]
> > OIT: 5972059, OST: 5972059, OAT: 32038364
> > Next: 32070795, Active: 4, Gap: 26098736
> > A diferenзa entre a Prуxima transaзгo e os outros marcadores de
> > transaзгo estб atipicamente alto (26.098.736).
> > Verifique o controle transacional nas suas aplicaзхes.
> >
> > O que seria este parâmetro? O que podemos fazer para nos prevenir
> > deste risco? Que outras ações nos sugerem?
> >
> > Abs
> > --
> > Cleber Jorge Amaral
> > 克莱贝尔
> > -----------------------------------------------------------------
> > Celular: (48) 8426-9006 - Skype: clebercbr
> > MSN: clebercbr em msn.com
> > gTalk: clebercbr em gmail.com
> > Twitter: twitter.com/clebercbr
> > -----------------------------------------------------------------
> > Antes de imprimir, pense em sua
> > responsabilidade com o MEIO AMBIENTE.
> > -----------------------------------------------------------------
> >
> > ______________________________________________
> > FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> > Para saber como gerenciar/excluir seu cadastro na lista, use:
> > http://www.firebase.com.br/fb/artigo.php?id=1107
> > Para consultar mensagens antigas: http://firebase.com.br/pesquisa
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para saber como gerenciar/excluir seu cadastro na lista, use:
> http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa



Mais detalhes sobre a lista de discussão lista