[firebase-br] Restore lento base de dados....

Fábio P. Santos fpsgyn em gmail.com
Seg Nov 19 11:30:44 -03 2012


Sim, realizei todas as comparações possíveis do restore feito via gbak e
jaybird e estão 100% iguais, tanto via gbak e jaybird o verbose está
setado, e em ambos os casos o backup/restore foi feito com máquinas de
teste sem acesso em produção... lembrando que o tempo via jaybird em torno
de 20 minutos via gbak 3 horas....

Estou pesquisando para ver o que pode estar acontecendo...

quanto a questão do Jaybird , nunca tive nenhum tipo de problema com ele,
tenho várias aplicações funcionando em JAVA 100% funcional....

Em 19 de novembro de 2012 11:16, Gladiston Santana
<gladiston em vidy.com.br>escreveu:

> Depois de realizar o primeiro backup, em geral, o segundo em seguida é mais
> rápido porque não tem tanto garbage para ser limpo, mesmo assim não
> reduziria o tempo em 75% para eu pergunta-lo se o backup com jaybird foi
> feito depoois do gbak. Poderia especular que o jaybird não faz verbose e
> seu gbak tá programado para fazer verbose ? neste caso a comparação não é
> justa, o verbose quando ligado consome mais tempo, contudo gera o log
> necessário para administrarmos a ocorrência de erro.
> E por ultimo, veja o estado da cpu enquanto o backup é executado, como o
> gbak foi feito para ser realizado online, ele não pode afogar a cpu em 100%
> senão seu banco de dados pára, talvez outro método de backup consoma 100%
> de cpu e ande mais rápido.
>
> Usando o gbak,ibexpert, jaybird,... chegaria ao mesmo resultado de tempo
> porque todos usam a mesma api e o mesmo client.
> Se é fato que o jaybird está sendo mais rápido sem uma justificativa,
> provavelmente o mesmo está usando um método diferente e se for este o caso,
> eu não recomendo, a menos que tenha sido homologado pelo time do firebird
> como foi o caso do nbackup. Alias, teste a restauração dos backups feitos e
> compare e veja se é realmente confiável esse conjunto que já criou com o
> jaybird e observe os blobs.
>
> Sobre ext4, olha é fato que algumas ferramentas no inicio não gostavam
> muito dele. O VirtualBox por exemplo, poderia corromper seu arquivo se
> fosse executado em ext4. Mas isso foi no inicio, hoje não há mais
> incompatibilidade. Contudo, o ext3 tinha ferramentas que poderiam recuperar
> arquivos acidentalmente apagados, já o ext4 pode demorar (como demorou o
> ext3) para ter ferramentas assim.
>
> No Linux, existem vários tipos de sistema de arquivos onde cada uma tem
> seus prós e contras, umas sabem criar arquivos rapidamente, mas perdem
> muita performance na sobregravacao, outros lidam rapidamente com arquivos
> pequenos, mas perdem com arquivos grandes e assim por diante. O ext é um
> pneu para lidar com vários tipos de estrada, mas existem pneus melhores que
> ele se a pista por exemplo de uma F1.  O ZFS do Solaris é tido por muitos
> como sendo o melhor sistema de arquivos do mundo, especialmente para banco
> de dados. Mas se for para armazenar arquivos de internet, o da EMC
> (proprietário) é considerado o melhor. Vê ? Não tem um vencedor para todas
> as situações.
>
> []´s
>
> Em 19 de novembro de 2012 09:54, Fábio P. Santos <fpsgyn em gmail.com
> >escreveu:
>
> > o gbak que estou rodando é diretamente no servidor linux (CENTOS) nesta
> > versão a partição está em ext3. ouvi dizer que com ext4 dá problema....
> >
> > Em 19 de novembro de 2012 09:33, Gladiston Santana
> > <gladiston em vidy.com.br>escreveu:
> >
> > > O gbak que você executa é no windows ou no linux, é diretamente no
> > servidor
> > > de dados ou através de uma estação ?
> > > Existe diferença na performance no windows e no linux, no Linux não há
> > > serviços soberbos rodando que possa comprometer a performance, já no
> > > windows ouve-se falar até de plugins para internet que comprometem
> > > performance.
> > >
> > >
> > > Em 19 de novembro de 2012 08:19, Fábio P. Santos <fpsgyn em gmail.com
> > > >escreveu:
> > >
> > > > Não sei se alguém já evidenciou este problema, mas a questão é a
> > > seguinte:
> > > > tenho uma base de dados em torno de 7 GB, quando vou realizar um
> backup
> > > que
> > > > leva em torno de 10 minutos, o restore chega a demorar mais de 4
> horas,
> > > > tudo isto via linha de comando utilizando o gbak, agora o
> interessante
> > é
> > > > que se na mesma máquina (linux) eu rodar um aplicação para backup /
> > > restore
> > > > feita em Java utilizando a classe FBBackupManager do Jaybird leva em
> > > torno
> > > > de 30 minutos, o que será que acontece de tão diferente entre as duas
> > > > formas de restore ?
> > > >
> > > > valeu...
> > > > ______________________________________________
> > > > 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
> > >
> > ______________________________________________
> > 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