Banco de dados Ib danificados, são difíceis de se encontrar graças a estabilidade desse SGDB, no meu caso por exemplo eu tenho contato com aproximadamente 8 a 15 banco de dados e alguns deles com mais de 700 MB simultaneamente acessados por pelo menos 08 usuários.
   
    Esse documento não estaria sendo escrito se não fosse um desses 8 bancos, e estou falando de um banco com quase 500MB, 478MB hoje (nov 2001), onde o meu usuário insiste em não fazer backup e ainda como se não bastasse ele "reseta" o servidor com estações conectadas (uug!). Bom, para meu espanto apenas 2 vezes o banco se danificou. Mas vamos falar da solução do problema que é o mais importante aqui.
   
    O nosso maior objetivo quando um banco está danificado no interbase, é justamente fazermos um backup / restore desse banco da melhor forma possível. Não é possível fornecer garantias de que esse backup (após o dano) estaria refletindo todo o banco de dados na sua posição anterior ao sinistro.
   
    http://www.ibphoenix.com/ibp_db_corr.html, é um excelente artigo sobre recuperação de banco de dados , vamos analisar alguns pontos desse artigo.
   
    Como primeiro passo o artigo sugere a modificação da forma de gravação do Interbase ( síncrona ou assíncrona ) para assíncrona. Onde o Interbase 6.0 tem como default a gravação síncrona o autor também se refere à gravação síncrona como "careful writes" que o interbase descarrega as paginas modificadas para o disco e ira gravar - las na ordem correta o que minimiza a possibilidade de perda dos dados porem degrada a velocidade (nada com que se preocupar pois essa degradação é muito pequena).
   
    Já a forma assíncrona certamente é um "force write" não tão cauteloso gravando as paginas descarregadas da memória em qualquer ordem. Esse método também pode ser usado para aumento de performance porem, é ressaltada pelo autor a necessidade de uma boa estratégia de backup quando esse método é usado.
   
    Primeiro Comando:
    gfix -write async database.gdb
   
    A Atenção para esse método assíncrono é que ele não tem sentido nos windows 3.1, 95, 98. Já no Unix e no NT ele assume a forma de gravação do próprio sistema operacional e seu método de cachê de disco.
   
    Para facilitar o trabalho, e realmente facilita muito, são as variáveis de memória.
   
   Set ISC_USER=sysdba
   Set ISC_PASSWORD=masterkey
   
   
    Cauteloso o autor sugere que seja feita uma copia do banco danificado pelo sistema operacional com o comando copy, e que seja essa copia a que vamos trabalhar.
   
   gfix -v -full database.gdb
   
    Esse comando irá validar e tentar recuperar o banco de dados, (como resultado ele nos mostra onde e qual é o problema do banco)
   
   gfix -mend -full -ignore database.gdb
   
    Com o parâmetro mend nos estamos agora tentando corrigir de qualquer forma o banco de dados, não há a partir desse momento nenhuma garantia de recuperação de todas as informações. Quando esse comando foi executado em uma das minhas “aventuras” ele aparentemente descartou mais de 17.000 registros de uma tabela de 18.000. (claro que isso foi reversível pois estávamos trabalhando em uma copia do banco).
   
   gfix -v -full database.gdb
   
    Agora para analisar se o banco está sem erros. O passo anterior (mend) e o (validade) devem ser usados repetitivamente até que o banco esteja recuperado (hummm bem digamos , sem erros). Mas é claro que nem tudo que está na documentação acontece na realidade, minha experiência me mostrou que 20% dos erros foram retirados nesse processo alem da perda de registros descrita anteriormente.
   
   gbak -backup -v -ignore database.gdb database.gbk
   
   gbak -backup -v -ignore -garbage database.gdb database.gbk
   
   gbak -backup -v -ignore -garbage -limbo database.gdb database.gbk
   
   
    Agora sim vamos para a primeira tentativa de backup os três comandos, são para cada uma das possibilidades -garbage para problemas com garbage collection, e -limbo para problemas com versão de registros.
   
   
   gbak -create -v database.gbk database.gdb
   
   
    A operação tão esperada de restore do banco de dados, mas ainda pode ser que você não esteja livre do problema, pois problemas de relacionado a índices podem persistir, e você terá que restaurar com os índices inativos (-inactive) e se o caso for ruim mesmo você ainda tem a possibilidade de restaurar uma tabela de cada vez ( -one_at_a_time), que ira fazer um commit no novo banco a cada tabela restaurada.
   
    Bem na maioria dos casos esses procedimentos acima irão recuperar o banco de dados com uma confiabilidade de sucesso bastante alta. Mas eu diria que devemos considerar o fator SORTE nesse caso, pois ainda dependemos da extensão do dano no banco de dados, que com sorte pode ser pequeno.
   
    Mas esse artigo não seria completo se eu não demonstrasse como foi que recuperei aqueles 17.000 registros perdidos na tentativa anterior de restauração. Bem os passos que segui foram os sequintes.
   
    Se é possível uma conexão no banco de dados vamos utilizar a seguinte estratégia.
   
   Recriar o banco de dados
    Fazendo um Backup apenas do metadata do banco
   
   Gbak -b -metadata database.gdb database.gbk
   
    E recriando ele novamente
   
    Gbak -r database.gbk database.gdb
   
   
    E agora vamos trazer os dados do Banco de dados Antigo ( danificado ) para o novo , lembrem-se nessa etapa eu não usei o banco de dados em que foi executado o utilitário gfix -mend, mas eu diria que o bom censo deve prevalecer aqui verifiquem qual banco está em melhores condições, uma outra copia do banco danificado ou o que foi passado gfix.
   
   
    Agora com um utilitário bastante versátil e excelente naquilo que se dispõe a fazer WIB_ISQL da Ibobjects http://www.ibobjects.com/ abra uma conexão com o novo banco de dados (aquele que acabamos de criar);
   
    Com essa conexão agora vamos utilizar um utilitário pouco conhecido do Data Pump, que podemos achar um help (aqui um help dele).
   
   
   Figura 1;
   
   
    Esta opção serve exatamente, para copiarmos os dados de um banco de dados ( neste caso um banco danificado ) para outro banco de dados ( neste caso um banco de dados novo com a mesma estrutura ); a operação dele é bastante simples.
   
    A primeira palheta do utilitário ScrDataSetSql ( Sql do DataSet Source ), nos da a opção de escolhermos um outro banco de dados para ser o fonte de dados, no botão (Select DataBase ) uma nova secção do WIB_ISQL irá ser aberta pronta para que seja apontado um banco de dados Fonte;
   
    O Espaço abaixo é dedicado para uma pesquisa no banco de dados fonte, esta pesquisa é para retornar os dados que desejamos para inserir no banco de dados destino, como no exemplo Figura 1 , eu estou trazendo todos os campos da tabela de registros do banco de dados danificado;
   
   Figura 2;
   
   
    A palheta DstStatmentSql é exatamente uma Expressão Select, para retornar quais são as tabelas e campos que serão afetados na inclusão dos registros , o botão select database, ainda se mantem, mas como o banco de dados destino já foi aberto na primeira secção do Wib_ISQL, não é nescessária a sua alteração;
   
   
   Figura 3;
   
   
    A palheta DSTLinks é agora o mecanismo de atribuição , que campo fonte será atribuído a que campo destino , essa palheta é gerada automaticamente, se os campos das 2 tabelas fonte e destino forem iguais, se não , não é tão trabalhoso assim escrever-las;
   
   
   A próxima Palheta, não utilizei , mas deve ter no help
   
   Na palheta Items Actions, após o botão prepare, ser clicado :
   Figura 4;
   
   
   
   Já a palheta Execute , com todo o historio da execução
   Figura 5;
   
   
   
    Foi com esse aplicativo, que eu entendo ser pouco conhecido a opção de datapump , pelos usuários do Interbase, que eu consegui recuperar +- 17.000 registros que estavam perdidos, pelo sistema gfix e gbak, essa é a minha modesta contribuição aos usuários Ib.
   
    Colabore voce tambem envie o seu artigo sobre qualquer assunto pelo email : mailto:colaboracao@santoandrea.com.br