Fórum Backup/Restore .gdb 7 giga #56218

Colega,

Como eu ainda não tenho um arquivo de banco de dados tão grande, o máximo que posso fazer sugerir-lhe algumas alternativas sem ter certeza que surtirão efeito. Inclusive, se você puder retornar se obteve alguma melhora de desempenho com as sugestões, visto que o seu BD é o maior BD IB/FB que já tive notícia ´de perto´:

1. Utilizar o GBAK ao invés de uma aplicação GUI. Utilitários de linha de comando, normalmente, são mais rápidos além do fato de ser um utilitário ´oficial´ de backup do IB/FB.

2. Utilizar o parametro [b:685532d446]-g[/b:685532d446] na linha comando. Se o ponto crítico é segurança e não diminuição do banco após o restore, pode ser uma boa opção.

3. Utilizar o parametro [b:685532d446]-ig[/b:685532d446] para ignorar erros de checksum. Eu não tenho certeza se ele apenas ignora eventuais erros ou deixa de fazer a verificação. Se deixar de fazer a verificação, você pode ganhar algum tempo. Se apenas ignorar os erros porém continuar a checar, você não deverá ter ganho. Em ambos os casos, pode não ser uma boa alternativa visto que você poderia estar fazendo backup de dados corrompidos sem saber... talvez não valha a pena o risco.

4. Utilizar o parametro [b:685532d446]-l[/b:685532d446] para ignorar transações no limbo. Esta pode ser uma boa alternativa se além de grande, seu BD é muito concorrido. Normalmente, quanto mais concorrido, mais transações no limbo existem.

5. Se espaço para o backup não for problema, tente utilizar o parametro [b:685532d446]-e[/b:685532d446] para que o arquivo de backup não seja comprimido. Isto deverá lhe dar um bom ganho de tempo.

6. Efetuar o backup para múltiplos arquivos. Isto pode ´facilitar a vida´ do S.O no trabalho com o arquivo de backup e pode lhe dar algum retorno. Talvez melhor ainda se aliado a sugestão 5.

7. Se não for necessário, não utilizar a opção [b:685532d446]-t[/b:685532d446] para que o arquivo de backup não seja transportável entre plataformas.

8. Em um eventual restore, utilizar o parametro [b:685532d446]-i[/b:685532d446] para restaurar os índices como inativos. Porém, você terá que ativá-los após a operação. É possível que somando-se os tempos de restore + ativação de índices você não tenha nenhuma vantagem.

9 e última. Verificar ser o hardware do servidor pode ser melhorado. Recentemente, um cliente substituiu o servidor por recomendação minha e o tempo de backup de seu banco reduziu-se de 1,5 horas para cerca 25 minutos. Se bem me lembro, este banco tinha +/- 3GB na ocasião e eu não utilizo nenhuma das opções ´extras´ para o GBAK que lhe sugeri acima.
- Antigo: Pentium 4 1.4 Ghz, 512MB RAM, discos IDE 5.400 RPM, S.O Linux Suse 8 c/ sistema de arquivos Ext2.
- Novo: Pentium 4 630 3.0 Ghz, 2GB RAM, 2 discos SATA 7.200 RPM sem RAID (um disco só para o BD), S.O Linux Slackware 10.2 c/ sistema de arquivos ReiserFS.
O Servidor novo é um Dell PowerEdge 830 de cerca de R$6.000... nada de tão e$pecial assim.

Vide um pequeno ´guia rápido´ para o GBAK [url=http://www.destructor.de/firebird/gbak.htm]neste link[/url].

Espero que as sugestões sejam válidas de alguma forma...