Caso seu banco de dados esteja muito corrompido, e os procedimentos abaixo não forem suficientes para recuperá-lo, verifique nosso serviço de recuperação de base de dados. Um número grande de tipos de corrupções podem ser reparadas através dos utilitários gfix e gbak. No entanto, é possível que em alguns casos raros o arquivo de banco de dados esteja corrompido de tal maneira que seja impossível para esses utilitários restaura-lo. Nesses casos, medidas mais drásticas podem ser necessárias para colocar o BD on-line novamente. Se voce não conseguir recuperar seu BD, entre em contato conosco e nós veremos o que poderemos fazer para ajudar.
A causa mais freqüente de corrupção é a queda de energia no servidor de banco de dados. Cortar a energia quando uma aplicação está em processo de gravação no Banco de Dados pode resultar que dados incompletos ou corrompidos sejam gravados no arquivo de Banco de Dados. Em todos os casos, o usuário e o administrador de sistema deve tomar todos os cuidados necessários para que isso não aconteça.
O InterBase tem dois modos de escrita (escrita forçada), síncrono e assíncrono. Nas versões anteriores do IB, o modo de escrita padrão era síncrona.
gfix -write sync database.gdb
No IB 6.0, a escrita padrão é assíncrona :
gfix -write async database.gdb
A escrita síncrona também é conhecida como "escrita cuidadosa" e nela o Interbase irá gravar as páginas alteradas assim que a transação for commitada, e retorna-las ao BD na ordem correta (em se tratando do servidor). Esse tipo de escrita funciona bem em ambientes Linux ou Unix, mas causam alguns problemas no Windows e no NT. Esses sistemas ignoram as instruções de escrita do Interbase e, mesmo as páginas tendo sido commitadas e gravadas, elas somente serão realmente gravadas quando o sistema operacional achar que é melhor faze-lo, mesmo com a opção de escrita-forçada ligada. Portanto, apesar da corrupção de arquivos ser rara, o Windows é o sistema mais suscetível à uma possível corrupção.
Geralmente a maioria dos usuários deixam a opção de escrita-forçada desligada devido ao ganho de performance que se pode obter deixando que o Sistema Operacional gerencie seu cache de dados automaticamente. Se voce está usando escrita assíncrona, tome muito cuidado com sua estratégia de backup, no caso do pior acontecer.
Nas versões anteriores do IB 6.0, o aplicativo Server Manager oferecia alguns recursos de validação de um BD, assim como o atual IBConsole, no entanto, eu recomendo o uso do utilitário GFIX para essa função devido ao seu maior número de opções e flexibilidade.
A corrupção de um BD que pode ser reparada geralmente poderá ser recuperada usando o gfix ou uma combinação do gfix e do gbak.
1. Defina as seguints variáveis para tornar o processo mais fácil pois voce não terá que digitar toda hora o usuário e a senha.
SET ISC_USER=SYSDBA
SET ISC_PASSWORD=masterkey
2. Sempre tenha certeza de estar trabalhando com uma cópia do BD e não o arquivo original. Use o sistema operacional para fazer uma cópia do arquivo. Voce deve ter acesso exclusivo ao BD para fazer isso.
copy employee.gdb database.gdb
3.Agora confira se o BD está corrompido. Voce precisa ter acesso exclusivo ao BD para fazer isso, mas como voce está trabalhando com uma cópia do BD original, isso não é problema.
gfix -v -full database.gdb
4. Se o comando anterior indicou que há um problema com o BD, agora nós devemos repara-lo.
gfix -mend -full -ignore database.gdb
5.O próximo passo é conferir se o BD foi reparado.
gfix -v -full database.gdb
6. Se o BD continua com erros, voce deve fazer um backup completo e restaura-lo. No seu estilo mais simples, a linha de comando do backup pode ser :
gbak -backup -v -ignore database.gdb database.gbk
7. No entanto, se o gbak falhar porque está tendo problemas com garbage collection, então use o seguinte comando :
gbak -backup -v -ignore -garbage database.gdb database.gbk
8. Se houver corrupção nas versões dos registros de uma transação em limbo, então voce deve incluir a opção -limbo :
gbak -backup -v -ignore -garbage -limbo database.gdb database.gbk
9. Agora crie um novo BD do backup:
gbak -create -v atlas.gbk atlas_new.gdb
10. Se houver problemas durante o restore, considere usar as seguintes opções.
-inactive, se houver problemas de índices, isso irá restaurar o BD mas não irá ativar nenhum índice, depois voce poderá ativar os índices manualmente um de cada vez.
-one_at_a_time, isso irá restaurar o BD uma tabela por vez, e commitar as tabelas restauradas, se houver um problema maior pelo menos voce terá uma parte dos dados.
Caso os passos indicados não resolvam o seu problema, e você não consiga nem mesmo conectar o banco de dados, verifique o nosso serviço de recuperação de bases de dados (veja mais informações neste link).
Data da última atualização: 12/09/2002Atualizada e revisada em 29 Setembro 2000 por Paul Beach
Tradução/adaptação : Carlos H. Cantu (www.firebase.com.br)
