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

[Carlos H. Cantu]

Sugiro que vc leia os artigos e o faq da FireBase, que explicam o que
é OIT, o que faz um Sweep, etc.

[]s
Carlos H. Cantu
www.FireBase.com.br - www.firebirdnews.org
www.warmboot.com.br - blog.firebase.com.br

CA> Olá Rodrigo,

CA> Obrigado pela pronta resposta, estou monitorando o caso para entender
CA> melhor agora com esta explicação.

CA> Me corrija se estiver errado, não estou certo de que o sweep pode ajudar. O
CA> que compreendi é que este comando remove transações já finalizadas (entendo
CA> que são as que que deixaram o limbo). A OIT pensei ser uma transação ainda
CA> ativa, uma aplicação que abriu e não finalizou, que ainda estaria no limbo
CA> e não será removida pelo sweep.

CA> De qualquer forma um gap grande aponta uma provável falha na implementação
CA> de meu software. Me procupo também com o impacto disso nos ciclos de
CA> transações. Há pouco tempo estava utilizando o pagesize de 4k que limita as
CA> transações a 534 249 472, minha questão é: se cheguei a um gap de 26
CA> milhões, em vários meses de uso facilmente entre abrir e encerrar os
CA> incrementos absolutos já devem ter estourado o limite de 543 milhões e
CA> provavelmente o FB não trata bem quando o ponteiro NEXT alcança o OIT após
CA> girar o ciclo, provavelmente gerando corrução de dados.

CA> Bom, de imediato já estou aumentando o pagesize pra 8k em alguns clientes e
CA> iniciando a utilização de 16k também. Vou averiguar que transação pode
CA> estar ficando aberta por todo este tempo.

CA> Muito grato pela colaboração!

CA> Abs


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


CA> Em 22 de agosto de 2013 09:53, Rodrigo Gomes da Silva
CA> <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