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

[Cleber Amaral]

Gladiston,

Obrigado pelos esclarecimentos.

Desculpe, sobre o procedimento de backup/restore é possível e como devo
proceder se meu banco não pode parar de rodar?

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 23 de agosto de 2013 11:35, Gladiston Santana
<gladiston em vidy.com.br>escreveu:

> 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
> >
> >
> ______________________________________________
> 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
>