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

Kelver Merlotti kmerlotti em gmail.com
Sex Set 6 13:49:14 -03 2013


Boa tarde galera!
Em "teoria", transações iniciadas implicitamente pelo DBX só vão permanecer
abertas se houver algum DataSet (sqlQuery, sqlDataSet, sqlStoredProc, etc)
ou DBXCommand aberto. Na teoria! Coisa que o uso do ClientDataSet+Provider
resolve, por se encarregarem de fechar os DataSets da ponta.
Mas vale lembrar que da teoria à prática podem haver "raras exceções",
carinhosamente conhecidas como "bugs"! :)
[]'s

*Kelver Merlotti*
Gerente de Serviços da Embarcadero do Brasil
Coordenador Editorial da Active Delphi
Twitter: http://www.twitter.com/kmerlotti


2013/9/6 Jéter Rabelo - GMail <jeter.rabelo em gmail.com>

> Boa tarde.
>
> Cleber, eu utilizo DBX e tenho um sistema com mais de 120 usuários
> simultâneos, BD em torno de 50Gb (Gb mesmo) e nunca tive problemas com
> processamento alto ou com transações pendentes.
>
> Porém, mantenho um controle rigoroso de todas as minhas transações, tudo
> manual. Não deixo nada a cargo do DBX.
>
> Sweep é desligado e feito todo dia de madrugada.
>
> Rodando FB2.5.1 desde o lançamento dessa versão. Nunca precisei recuperar
> um backup por corrupção ou qualquer outro problema.
>
> Instalado em W2K3, com 8gb de  memória.
>
> Esse é apenas um exemplo.
>
> Portanto posso te dizer que problemas com o DBX, comigo, não há.
>
> Reveja suas transações. Não deixe nada automático. Faça tudo "na unha"
> mesmo. Dá trabalho, mas o resultado é excelente.
>
> PS: Sistema desenvolvido originalmente em Delphi 2007, depois migrado para
> o XE2, sem nenhuma alteração quanto a DBX e etc.
>
> Atenciosamente,
> Jéter Rabelo Ferreira
>
> Em 06/09/2013 11:35, Cleber Amaral escreveu:
>
>  Olá Gladiston,
>>
>> Utilizamos a ferramenta Sinatica trial que nos ajudou muito a entender as
>> transações. Nossa conexão é feita via componentes DBX que parece confundir
>> conexão e transação fazendo tudo parecer igual especialmente por usarmos
>> modelo keepconnection.
>>
>> Parece que precisaremos fechar as conexões para que a transação seja
>> também
>> finalizada, estamos ensaiando modificações neste sentido para ver se
>> manteremos a performance.
>>
>> Vou incluir o nbackup na minha tasklist tb!
>>
>> 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 12:51, Gladiston Santana
>> <gladiston em vidy.com.br>**escreveu:
>>
>>  O backup pode e deve ser feito online, sempre.
>>> O bom do backup é que se houver erros na base, você já fica sabendo
>>> imediatamente.
>>> Pode ocorrer de ter coisas erradas no seu banco, mas ele continuar
>>> funcionando. O backup lhe mostra isso, e só quando o backup rodou 100% é
>>> que ele faz o sweep. Se tiver erros, o backup até vai ser completado
>>> algumas vezes, mas não tenho certeza de o sweep será feito. Sem o sweep,
>>> sua base cresce e pode causar problemas de performance, numa eventual
>>> sinistro voce terá um arquivo bem maior para perder ou para corromper.
>>>
>>> Aqui, o sweep é desligado e o backup roda de 2 em  2 horas.
>>> Na realidade tá na minha tasklist aprender a usar o nbackup que permite
>>> um
>>> backup incremental :
>>> http://www.firebirdsql.org/**manual/nbackup.html<http://www.firebirdsql.org/manual/nbackup.html>
>>>
>>> O restore só seria usado quando há falhas graves sistêmicas onde o banco
>>>>>> parou ou precisa ser parado de qualquer forma, daí a ideia de você
>>> escrever
>>> um documento contendo procedimentos aplicáveis a essa situação que possa
>>> colocar o banco de dados o mais rápido possível.
>>>
>>> Meu backup é rodado por script (vbs e bash) e agendado pelo próprio
>>> agendador do windows ou do Linux, o gbak tem uma opção de gerar o log num
>>> arquivo externo que depois eu analiso (na realidade, essa tarefa eu passo
>>> para outra pessoa), se houver erros então sigo alguns procedimentos.
>>>
>>> []´s
>>>
>>>
>>> Em 23 de agosto de 2013 11:42, Cleber Amaral <clebercbr em gmail.com>
>>> escreveu:
>>>
>>>  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?
>>>>
>>>>  ______________________________**________________
>>> 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<http://www.firebase.com.br/fb/artigo.php?id=1107>
>>> Para consultar mensagens antigas: http://firebase.com.br/**pesquisa<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<http://www.firebase.com.br/fb/artigo.php?id=1107>
>> Para consultar mensagens antigas: http://firebase.com.br/**pesquisa<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<http://www.firebase.com.br/fb/artigo.php?id=1107>
> Para consultar mensagens antigas: http://firebase.com.br/**pesquisa<http://firebase.com.br/pesquisa>
>



Mais detalhes sobre a lista de discussão lista