Renato Filho - Soluções para Banco de Dados Firebird Corrompidos

Soluções para banco de dados Firebird corrompidos

Instituto de Informática – Centro Universitário do Triângulo (UNITRI) Caixa Postal 309 – 38.411-106 – Uberlândia – MG – Brasil

renatoribeiro.udi@gmail.com, jonytme@gmail.com

Resumo. Este artigo apresenta um pouco da história sobre o Firebird,

soluções para banco de dados corrompidos, demonstrando o que ocasiona esse corrompimento, maneiras alternativas de prevenção desse problema para o Firebird, bem como quais os modos para se tentar solucionar e reparar um banco já corrompido de maneira fácil e eficaz, minimizando, assim, ao máximo a perda de dados. O estudo foi realizado com bases reais em produção, com situações diferentes de corrompimento.

1. Introdução

O Firebird é um SGBD (Sistema Gerenciador de Banco de Dados) robusto que preenche um nicho de mercado onde são necessárias bases locais para guardar dados de diversos tipos de aplicações, assim, tendo evoluído consideravelmente nos últimos anos, haja vista que foram acrescentadas várias funcionalidades que propiciaram ao Firebird conquistar a popularidade de que hoje é alvo. Ele é um SGBD multiplataforma, de simples instalação – por exemplo, tem-se o mesmo completo com apenas 14MB –, em comparação a outros, que finalizam a instalação com ocupação superior a 100MB.

As empresas que trabalham com o Firebird geralmente têm ferramentas de auxílio na manutenção de banco de dados, na realização de back-up e na reparação de problemas relacionados à corrupção de dados. Ex: IBFirsID. Contudo, algumas não dispõem de tais funcionalidades; este artigo mostra uma maneira alternativa de fazer a reparação desses dados, sem qualquer custo, que, ainda que seja trabalhosa inicialmente, se torna simples à medida que se faz a manutenção continuamente e que se faz uso de maneiras de prevenção da corrupção de dados.

O início do Firebird deu-se com o lançamento do código fonte aberto do Interbase 6.0, pela empresa Borland Software Corporation. Nela, certos membros se uniram para dar continuidade ao trabalho descontinuado pela empresa e, assim, nasceu o Firebird, sucessor do Interbase.

Após certo tempo, como vários usuários conheciam somente o Interbase, os membros do novo projeto começaram a realizar a divulgação do novo SGBD que, então, era bastante instável e com vários bugs. Assim, a comunidade de desenvolvedores se interessou pelo projeto e começou a estudar seu código fonte, realizando melhorias e corrigindo diversos erros e falhas de segurança.

Como o Firebird foi se popularizando rapidamente, criou-se a Fundação Firebird, uma instituição sem fins lucrativos com o intuito de levantar fundos no mundo inteiro para conceder estrutura aos desenvolvedores que trabalhavam como o Firebird, para que estes pudessem criar novos recursos, testando e corrigindo o mesmo.

Com o empenho de diversas pessoas na melhoria do código fonte, deu-se origem ao Firebird 1.0, que, além de contemplar várias correções, podia ser até comparado a um Interbase com correções; contudo, há que se ressaltar o grande mérito dele em ser um projeto totalmente Open-Source e independente, que representa o trabalho de um grupo que se empenhou em compilar o código “C”, fixando diversos bugs e criando novos recursos, a saber:

- Select First X skip Y: seleciona registros os primeiros registros e pular outros certos registros, e voltar a selecionar os primeiros registros; usualmente, é parecido com os comandos TOP e LIMIT.

- Recreate Table: apaga e recriar uma tabela, a partir de um único comando. - 16k pages sizes: permitindo bando de dados maiores e aumentado o ajuste de performance.

- 64-Bit file support, Description UDFs (User Defined Functions) entre outros. A grande mudança que aconteceu foi com a vinda do Firebird 2.0, no qual os desenvolvedores alteraram o código fonte de “C” para “C++”, o que limpou consideravelmente o código e o preparou para contemplar próximas mudanças (Firebird 3.0), tais como:

- Aumento significativo na performance. - Segurança.

- Suporte a diversos idiomas.

- Novas funcionalidades SQL (Structured Query Language). - Procedures e Triggers.

O Firebird foi estruturado para ser executado em ambiente local, visto que existe uma deficiência em hospedar um banco de dados e tentar recuperar informações em outro ponto, além da complexidade de criar triggers para fazer a sincronização dos dados para cada tabela. [Cantu. A. 2002][Cantu. B. 2002].

2. Minimizar a Incidência de Dados Corrompidos

Tratando-se de base de dados Firebird, os desenvolvedores que optem por essa tecnologia devem tomar certos cuidados quanto à corrupção de sua base de dados. Dado o SGBD ser aparentemente simples, o que não significa a falta de recursos para ele, muito menos instabilidade, é necessário estar atentos para alguns aspectos, procurando-se evitar que sua baprocurando-se corrompa dados, o que pode procurando-ser ocasionado por diversos fatores.

Como se trata de um software, o Firebird também está sujeito a diversos empecilhos que a virtualização oferece, incluindo-se as ‘travadas’, queda de energia, raios, falha de hardware, falha no disco rígido, vírus etc.

Como visto acima, há várias maneiras de intervir no bom funcionamento do banco de dados; assim, não se podem poupar esforços para circular todos esses problemas que, no meio comercial, ocasionam maiores dificuldades se não se atentar aos detalhes que garantam a boa funcionalidade da base de dados.

Abaixo, lista-se, simplificadamente, quais fatores devem ser atentados no plano de contingência para proteger os dados:

1. Tenha sempre um Backup :

Não se pode começar de outra forma. Todo e qualquer banco de dados deve ter uma rotina de backup, o que, praticamente, é frequentemente ignorado pelos profissionais na área de informática e pelos próprios usuários. Esta rotina pode livrá-los de grandes problemas, caso a base de dados seja alvo de alguma anomalia sistêmica; é importante salientar que, junto da instalação do Firebird, já é disponibilizado o GBAK, um aplicativo que não é acessado diretamente pela instância, ou seja, é necessário comandos no Prompt (caso seja Windows) para inicializar a funcionalidade desse aplicativo, que realiza Backup da base de dados. Posteriormente serão visualizados esses comandos.

2. No Break :

Além de evitar a queda súbita do sistema, evitará com que algum dado que esteja sendo gravado naquele instante em sua base de dados falhe. Caso ocorra a queda do sistema, há uma grande possibilidade de que o banco de dados seja corrompido. Há, no Firebird, a opção de configurar o Forced Writes ON, no arquivo firebird.conf, ou no próprio GFIX, que será decisivo para garantir a integridade do seu banco de dados. Com essa opção habilitada, o Firebird será obrigatoriamente forçado a gravar imediatamente os dados da aplicação diretamente no disco, reduzindo, desse modo, drasticamente o risco de corrupção caso o servidor seja desligado inesperadamente. Caso contrário, com o Forced Writes OFF, no qual os dados são guardados em cachê do sistema, e, como ainda não foram gravados em disco e são manipulados a critério do Sistema Operacional, se perdem na gravação e ocorre o corrompimento. São explicitados detalhes sobre essa configuração posteriormente.

3. Sistema Operacional :

É de extrema importância saber o Sistema Operacional a ser utilizado antes de colocar seu banco de dados exposto a qualquer tipo de ameaça, levando em consideração a segurança e estabilidade do S.O. Como o Firebird é um SGDB multi-plataforma, ou seja, executa praticamente em qualquer S.O (Windows, Linux, Solaris, etc.), isso permite que o desenvolvedor tenha um leque de opções, mas se deve levar em consideração a popularidade desse S.O; e, caso seja necessário fazer alguma manutenção no seu servidor, pode-se perguntar: haverá alguém com total domínio sobre a tecnologia? É uma questão a se levar em consideração, mas é importante informar que as configurações (Forced Whites) do Firebird não surtirão efeitos no Windows 95, 98 e ME, portanto, devem ser retirados da lista de opções.

4. Rede Confiável e Servidor Dedicado :

Embora seja ignorado por muitos, a necessidade de um servidor de dados dedicado, em se tratando de proteção a dados, é muito importante. Comumente vê-se base de dados Firebird sendo gerenciadas em computadores de uso diário, assim sujeitos a diversos perigos, como discriminado acima. Tendo um servidor dedicado ganha-se em performance, pois o servidor não precisará dividir o processamento com

nenhum outro aplicativo e, também, evita-se que usuários tenham acesso ao computador podendo infectá-lo de várias maneiras ou até mesmo travando o computador servidor.

Atualmente os intrusos (hackers) são uma preocupação constante, de modo que proteger seus dados de um invasor pode ser uma tarefa fácil. Como o Firebird usa a porta 3050, pode-se configurar no Firewall para liberar acesso somente aos computadores que forem acessar a base de dados, assim dificultando a vida de algum invasor que queira obter dados sigilosos em sua base Firebird.

Algumas precauções que pode-se realizar para evitar problemas com a base de dados foram apresentadas; seguindo tais instruções, dificilmente acontecerá a perda de dados, usando o Firebird. [Cantu. C. 2002][IBSurgeon. B. 2002].

2.1. Minizando a Perda de Dados com Forced Whites

A palavra Forced-Whites, vem do inglês: Escrita Forçada. Nessa configuração, o Firebird interpreta se é para gravar os dados imediatamente na base de dados (Forced-Whites ON), ou em memória e, quando o Sistema Operacional decidir melhor, gravar os dados presentes em memória cache, no arquivo de base de dados (Forced-Whites OFF).

Veja Um exemplo do comportamento do Firebird se tratando da situação da opção Forced-Whites ON, conforme figura 1:

Figura 1. Forced Whites Ligado

Configurando como ligado como mostra a figura 1, minimiza-se o risco de perda de dados por alguma falha inesperada.

Figura 2. Forced Whites desligado.

Configurando como desligado como mostra a figura 2, é visivelmente perigoso, visto que se houver alguma falha inesperada do servidor, a base de dados entrará em um estado inválido, conhecido como base corrompida, e, como esses dados estavam acumulados em memória, mesmo realizando o processo de recuperação da base de dados, certamente essas informações estarão perdidas.

Usualmente o Firebird já vem com a opção Forced-Whites ligada, mas há desenvolvedores que optam em desligar a opção, pelo seguinte motivo:

- Com a opção ligada, em uma base de dados que terá uma atividade grande de gravação de dados, aumentará muito a carga no seu servidor, o que pode ser compensado por um disco mais potente. Contudo, lembrando que essa opção é altamente arriscada mantê-la desligada, devido à grande possibilidade de perda de dados por alguma falha inesperada.

A habilitação e a desabilitação dessa opção pode ser realizada com um simples comando. Segue um exemplo usando o S.O Windows:

- Habilitar: C:\ProgramFiles\Firebird\Bin\Gfix –white sync suabase.fdb –user <usuário_da_base> –pass <password_da_base>

- Desabilitar: C:\ProgramFiles\Firebird\Bin\Gfix –white async suabase.fdb –user <usuário_da_base> –pass <password_da_base>

O comando é padrão do Firebird, o que diferencia a execução do mesmo é o diretório onde o Firebird se encontra instalado. [Cantu. D. 2002].

2.2 Proteção de dados com Shadow

Shadow é uma funcionalidade do Firebird que faz uma cópia espelho da base atual, caso venha a ocorrer uma falha por hardware (disco) ou acidental (exclusão da base de dados). Entretanto, caso ocorra uma falha lógica (software), conseqüentemente ela será replicada para a cópia.

Quando se usa Shadow a maior desvantagem é a perda de performance, que pode variar de operação para operação e pelo tamanho das transações, mas que fica em torno de 15 a 20%; uma perda significativa que, porém, pode facilmente ser compensada, quando se utilizam HDs rápidos, que hoje em dia não é um problema.

Em relação ás vantagens, destaca-se:

- O disco danificou, ou aconteceu alguma falha e ele não está mais acessível, Shadow é a melhor opção para solucionar um problema assim, pois diferentemente do backup, os dados são atualizados, o que faz a diferença nessa hora.

- Facilidade de criação: nada de softwares extras e não necessita de manutenção ou administração.

- A aplicação não para, caso o HD venha a sofrer alguma falha.

Uma Shadow da base de dados pode ser configurada, seguindo-se os passos: - Conecte-se na base de dados através de algum aplicativo de manutenção de dados, Ex: IBExpert.

- A Shadow deverá conter uma extensão diferente da base atual, para facilitar sua localização, já que o nome da base de dados é o mesmo. Se a base de dados for minhabase.FDB especifique a Shadow como minhabase.FBK, diferenciando a extensão, depois, trata-se somente de renomear a Shadow para o nome normal da base.

- Seguindo a lógica anterior, executa-se o Script:

 create shadow 1 auto conditional 'C:\Base\minhabase.FBK

Será criada uma base idêntica a atual no caminho que se especificar, no caso ‘C:\Base\’, mas o recomendado é ter um HD separado para guardar a Shadow; dessa forma somente se exemplifica, com o comando acima, que toda informação atualizada na base original é atualizada na cópia.

- Para a Shadow substituir a base atual, deve-se somente acessar o diretório onde salvou sua Shadow e renomear a base para a extensão normal, com todos os usuários desconectados da aplicação.

Ao colocar a Shadow para substituir a base, não será criado automaticamente outra Shadow da base atualmente iniciada. Por isso, é necessário executar o Script novamente na base atual para criar uma nova Shadow. [Borrie 2012][Cantu. E 2002] [IBExpert. 2013].

3. Métodos de Descorrupção de Base de Dados

Sempre se está sujeito a qualquer tipo de falha ocasionadas por Hardware ou Software. Demonstrou-se anteriormente alguns métodos para minimizar a incidência destas.

Mas, mesmo aplicando os métodos de contingência citados, caso a base de dados infelizmente foi corrompida, ao iniciar a aplicação, normalmente, é retornado o seguinte erro:

Figura 3. Típico erro reportado com indícios de base corrompida.

Com o erro reportado como mostra a figura 3, o próximo passo é pausar o serviço do Firebird e iniciá-lo novamente para cortar qualquer acesso pendente à base.

Existem duas situações de corrupção para determinarmos em qual tipo de procedimento deve-se seguir para efetuar um reparo eficiente da base de dados:

- 1ª Situação: A base de dados se conecta a algum aplicativo de gerenciamento de dados (IBExpert).

- 2ª Situação: A base de dados não se conecta a qualquer aplicativo, que necessite uma conexão por usuário e senha.

Normalmente a base de dados Firebird apresenta mensagens de erro básicas por meio das quais se pode distinguir a gravidade do problema; são elas:

 Internal gds software consistency check (cannot find tip page (165)). Esta mensagem diz que a transação com a página de inventário (TIP 165) foi interrompida, assim a base de dados encontra-se com referências nulas impedindo que a base de dados seja conectada.

 Internal gds software consistency check (wrong record length (183)...). Esta mensagem diz um ou mais registros na base de dados estão corrompidos e necessita da exportação dos dados da base (Extract Metadata).

 Database file appears corrupt. Wrong page type. Page of wrong type. Esta mensagem diz que a base está com uma série de problemas, refere-se a registros corrompidos dentro de uma tabela de registros. [IBPhoenix. B. 2012].

3.1 Descorrompendo da Base de Dados

Neste se enquadra a 1ª Situação, se a base de dados se conecta ao IBExpert, vê-se que o problema não vê-será tão difícil assim de resolver.

Em qualquer condição que a base de dados estiver, tem-se que inicialmente executar o assistente de reparo de base de dados, o GFIX, que se encontra dentro da pasta de instalação do Firebird, na sub-pasta bin.

Primeiramente deve-se saber que o aplicativo GFIX somente pode ser iniciado através de linha de comando (CMD), então pode ser executado o Prompt de Comando (Windows). Mas inicialmente precisa ser localizado o diretório da base de dados no Prompt escrevendo o comando “cd\”, para direcionar para o diretório raiz C; e, em

seguida o comando “cd Base”, em que Base é o diretório onde a base de dados se encontra, e escrever a seguinte linha (Sintaxe):

 \ProgramFiles(x86)\Firebird\bin\GFIX [opções] [nome_base.extensão] –user <usuário_da_base> –pass <password_da_base> e aperte Enter.

No exemplo acima para Windows 64Bits, 32Bits é somente \ProgramFiles\. No diretório \ProgramFiles(x86)\Firebird\bin\ encontram-se alguns aplicativos que são nativamente da instalação do Firebird que disponibiliza o GFIX, GBAK, GSEC, GSTAT, ISQL etc. Cada um deles tem uma funcionalidade diferente em que podem ser detalhadamente especificados em (Firebird Foundation 2000). Seguindo o propósito nesse artigo, exemplifica-se com os aplicativos GFIX e GBAK.

O GFIX dispõe de várias opções de manipuladores de dados onde estão relacionados em (Firebird Foundation 2000), mas o que interessa nesse caso são os comandos –v –full e em seguida –m –f –i; anexando esses comandos a Sintaxe estabelecida acima, tem-se:

 \ProgramFiles(x86)\Firebird\bin\GFIX –v –full minhabase.FDB –user <usuário_da_base> –pass <senha_da_base> e Enter.

 \ProgramFiles(x86)\Firebird\bin\GFIX –m –f –i minhabase.FDB –user <usuário_da_base> –pass <senha_da_base> e Enter.

Executando essas linhas de comando, a base de dados está livre de problemas e já pode ser executada a outra parte da manutenção, o GBAK, utilitário para realizar BackUp e Restore de bases Firebird, como na seguinte linha de comando (Sintaxe).

 \ProgramFiles(x86)\Firebird\bin\GBAK [opções] [base.extensão] [backup.FBK] –user <usuário_da_base> –password <senha> e aperte Enter.

Não muito diferente do GFIX, o GBAK usa o mesmo diretório, porém não as opções de BackUp e Restore. Estes são detalhadamente explicadas e exemplificadas em (Firebird Foundation 2000). Seguindo o objetivo desse estudo, as opções que lhe interessam são os comandos -b -v -ignore -garbage –limbo; anexando-os à Sintaxe estabelecida acima, fica:

 \ProgramFiles(x86)\Firebird\bin\GBAK -b -v -ignore -garbage –limbo base.FDB backup.FBK –user <usuário_da_base> –pass <senha> e Enter.

Efetuando todo o processo, a base de dados está reparada e se terá o seu backup. Agora cria-se a nova base, a partir do backup existente:

 \ProgramFiles(x86)\Firebird\bin\GBAK -c -v backup.FBK nova_base.FDB –user <usuário_da_base> –pass <senha> e Enter. E finaliza-se realizando o Extract Metadata da base de dados para criar-se outra base nova, com o intuito de prevenção de possíveis problemas que possam ocorrer nos índices das páginas da base de dados.

Agora se estabelece a conexão com a base de dados no IBExpert, indo no Menu > Tools > Extract Metadata; com a tela aberta, no campo File Name, especifica-se o

destino onde se salvará o arquivo. Logo abaixo na aba Meta Objects, marca-se a caixa Extract All, e na próxima aba Data Tables, passa-se todas as tabelas do Availabe Tables para o lado direito descrito como Selected Tables, e finaliza-se o processo apertando F9.

O processo demora alguns minutos, dependendo do tamanho da base de dados, onde será criado um arquivo.sql, e será executada na nova base a ser criada.

A seguir, desconecta-se da base atual e cria-se uma nova base no: Menu > Database > Create Database, abrirá uma tela, na opção Server seleciona-se Local, na opção Database especifica-se o nome e destino da nova base, na opção username informa-se sysdba, na opção password masterkey, que são as do padrão Firebird e finaliza-se clicando em OK.

Abrirá a tela para estabelecer conexão com a nova base recém criada e após isso, deve-se direcionar a Menu > Tools > Executive Script, que será aberto outra tela; nela pressione CTRL+L, seleciona-se o arquivo.sql criado anteriormente, marca-se a flag Use current connect, aperta-se F9, clica-se em Yes e aguarda-se a finalização da execução do script. Ao terminar, desconecta-se da base no IBExpert, navega-se até o diretório onde foi a mesma foi criada e renomeia-se a base antiga para Ex: base_antiga, e coloca-se o nome da nova basem, igual ao nome da base antiga. E, conectando-se base a ser utilizada, cria-se a Shadow, como se descreveu no início do artigo, habilitando a opção Forced-Whites.

Estes são os procedimentos por linha de comando que podem ser executados para se ter sucesso e possivelmente descorromper a base de dados. Mas há casos mais sérios onde mesmo executando todo o procedimento, a base não permite a reparação por comandos, assim tem-se que utilizar a ferramenta, IBSurgeonViewer. [IBPhoenix. A. 2012][Borrie. 2012][Cantu. F. 2002].

4. Método Avançado de Descorrupção de Base de Dados

Neste se enquadra a 2ª Situação, utiliza-se o IBSurgeon, esta ferramenta não necessita de conexões normais por usuário e senha à base de dados, nem depende de um serviço do Firebird estar instalado na máquina para ser executado, pois ele captura direto os dados em linguagem de baixo nível (Nível Físico), acessando os dados binários da base de dados no disco e permitindo alterações em páginas de inventário. Geralmente existem N soluções e N problemas que podem variar de situação a situação, mas existe uma maneira comum de resolver estes problemas alterando os valores das transações gravadas na base de dados.

Executa-se o programa como Administrador e na aba File > Open DataBase, seleciona-se a base em que será efetuado o processo de descorrupção.

O programa carregará informações sobre a base de dados em diversas páginas; contudo, a que interessa para esse processo é somente a Database Header Page, que é a primeira página carregada pelo sistema.

Na figura 4, está indicando a página e realizando um duplo clique na página, abrirá o seu conteúdo.

Figura 4. Aplicação IBSurgeon inicializada e conectada à base de dados corrompida. Como identificado na figura 4, devem-se atentar aos valores dos indicadores:

1. Oldest Interesting Transaction 2. Oldest Transaction Thought Active 3. Next Transaction Id

4. Oldest Snapshot of Active Transactions

Cada um deles representa o status de uma transação na base de dados e a modificação dos mesmos para valores anteriores, aos atualmente exibidos, retornará sua base de dados a um estado anterior ao momento da corrupção.

Os valores apresentados são do momento da transação em que a base de dados detectou o conflito de bits, páginas nulas ou dados corrompidos, e que entrou em estado de inválida. Para se voltar a base a um estado válido deve-se acessar a guia HEX

Header Editor como especificado na figura 4.

As numerações apresentadas são respectivas aos identificadores mencionados acima, alterando o hexadecimal sinalizado como “1” na figura 5, reciprocamente estará alterando o indicador Oldest Interesting Transaction, e assim sucessivamente.

Figura 5. Mostra-se os Hexadecimais das Páginas de Transações da base corrompida. Para se saber o valor a ser adicionado no respectivo Hexadecimal, sinalizado na figura 5, deve-se converter o número sinalizado na figura 4. Para isso usa-se o métodos de conversão de bases, para exemplificar, o valor apresentado no campo Oldest

Interesting Transaction da figura 4, o número que consta é “467576”, converte-se este

valor e conterá o Hexadecimal: “07 97 A8”. Nota-se que a conversão o Decimal apresentado na figura 4, resultará em exatamente o inverso do Hexadecimal apresentado pelo IBSurgeon como na figura 5, “A8 97 07”. Destaca-se que estão sendo marcados quatro pares de Hexadecimais na figura 5, pois, dependendo do tamanho da informação do identificador, indicado na figura 4, usa-se os quatro pares de Hexadecimais apontados na figura 5, no caso em específico, somente foi utilizado três pares.

Sabendo-se da maneira de atribuir os valores aos devidos campos indicadores, passa-se à atribuição dos valores nos campos para voltar o banco de dados para um estado válido. Logicamente os valores contidos nos campos indicadores são os que atualmente estão colocando a base de dados em um estado inválido, assim informa-se um número inferior ao existente no campo indicado na figura 4, por exemplo: “467476”, ou seja, 100 (cem) transações atrás do indicador Oldest Interesting

Transaction; o mesmo deve ser feito para os demais campos indicadores apontados. O

resultado obtido na conversão do site é: “07 22 14”. Será lançado no Hexadecimal do IBSurgeon “14 22 07” pois, como especificado anteriormente, no programa coloca-se o inverso da seqüência obtida, e assim serão atribuídos os mesmos detalhes aos demais indicadores, lembrando que deverão ser todos eles modificados. Após a modificação, clica-se no disquete para salvar as informações atualizadas.

Dirija-se ao File > Close Base, e execute o comando de GFIX com as opções –m –f. Se retornar o mesmo erro de corrupção, significa que a mesma afetou as transações dos números recém-atualizados nos indicadores, ou seja, será necessário atribuir um número ainda mais inferior ao atualmente salvo. Repita o processo e execute o GFIX; quando o executar, note se apresenta o resultado:

Figura 6. Retorno da execução do GFIX na base após descorrupção.

Dessa forma a base encontra-se em um estado válido, não considera-se exatamente os números apresentados na figura 6, como base de comparação, mas sim o contexto do retorno, assim neste estado a base permite ser conectada através do IBExpert. Agora realiza-se o GFIX e GBAK na base e realizar o procedimento de Extract Metadata pelo IBExpert, criando nova base e aplicando o script gerado, como descrito anteriormente.

Geralmente os fatores que levam a uma base de dados entrar em estado de corrupção são quedas de energia, falha de memória, falha de disco rígido.

Executando corretamente os procedimentos de descorrupção citados acima tem-se uma grande chance de recuperar a batem-se de dados, porém, em alguns casos mais

sérios, não é possível recupera-la, e tem-se que recorrer à existência de um backup ou a uma Shadow. [IBSurgeon. A.2002].

5. Conclusão

O Firebird preenche a um nicho de mercado onde são necessárias bases locais para salvar dados de aplicações, onde a utilização de um SGBD mais robusto como (Postgres, MySQL), não resolveriam o problema, pois estão sujeitos aos mesmos problemas, e optar por um banco de dados mais simples, o que não caracteriza instabilidade, seria uma boa opção, como o Firebird, este é relativamente frágil, porém seguindo métodos de contingência adequados, dificilmente teremos maiores problemas.

O estudo relacionado nesse artigo foi baseado em fatos reais, com bases de dados de produção reais, com situações diferentes de corrupção, de seis (6) bases coletadas para análise, segundo os procedimentos, cinco (5) foram recuperadas, ou seja, houve sucesso em 83,33% dos casos. Em uma delas a reparação comum por GFIX e GBAK tivemos sucesso, mas as outras quatro, somente executando os procedimentos de reparação pelo IBSugeon resolveu-se o problema Parte dos procedimentos relacionados foram elaborados após várias horas de análise, estudos e testes.

Espera-se que através desse trabalho sejam esclarecidas mais informações a respeito de um assunto pouco desvendado sobre o Firebird, e que possa conduzir os interessados a conhecer mais sobre o SGBD, solucionar problemas e incentivar novos estudos sobre técnicas manuais de reparação de base de dados Firebird.

6. Referências

Borrie. (2012), “Tehe Firebird Book Second Edition – For Database Developers”, 1038pp. Publisher edition 2012, 2013.

Cantu. A. (2002), “Firebird 1.0”. Disponível em: < <http://www.firebase.com.br/fb/artigo.php?id=154>. Acessado em: 10 de Agosto de 2013.

Cantu. B. (2002), “Firebird e InterBase - mesma origem, caminhos distintos”. Disponível em: < <http://www.firebase.com.br/fb/artigo.php?id=256>. Acessado em: 12 de Agosto de 2013.

Cantu. C. (2002), “10 Dicas Para Evitar Dores de Cabeça com Corrupção de Dados”. Disponível em: <http://www.firebase.com.br/fb/artigo.php?id=246>. Acessado em: 13 de Agosto de 2013.

Cantu. D. (2002), “Firebase Artigos”. Disponível em: < <http://www.firebase.com.br/fb/artigo.php?id=1971>. Acessado em: 15 de Agosto de 2013.

Cantu. E. (2002), “Forced Writes”. Disponível em: < <http://www.firebase.com.br/fb/artigo.php?id=1344>. Acessado em: 16 de Agosto de 2013.

Cantu. F. (2002), “Diagnosticando e Reparando Banco de Dados Corrompidos”. Disponível em: < <http://www.firebase.com.br/fb/artigo.php?id=3>. Acessado em: 20 de Agosto de 2013.

Firebird Foundation. (2000), “Reference Manual”. Disponível em: <http://www.firebirdsql.org/en/reference-manuals/>. Acessado em: 01 de Setembro de 2013.

IBExpert. (2013). Ibexpert.exe: Database Adminstrator Tool. Disponível em: < <http://www.ibexpert.net/downloadcenter/>. Acessado em: 02 de Setembro de 2013. IBPhoenix. A. (2012). ibsurgeonviewer-1.0.2.exe: Tool for Investigation of Internal

Database Structure. Disponível em:

<http://www.ibphoenix.com/files/ibsurgeonviewer-1.0.2.exe>. Acessado em: 02 de Setembro de 2013.

IBPhoenix. B. (2002), “Firebird and InterBase Errors and Problems”. Disponível em: <http://www.ibphoenix.com/products/software/ibfirstaid/page_16>. Acessado em: 03 de Setembro de 2013.

IBSurgeon. A. (2002), “InterBase database structure”. Disponível em: < http://www.ib-aid.com/articles/item75>. Acessado em: 05 de Setembro de 2013.

IBSurgeon. B. (2002), “Firebird and InterBase corruptions reasons”. Disponível em: <http://ib-aid.com/articles/item70>. Acessado em: 07 de Setembro de 2013.

IBSurgeon. C. (2002), “InterBase and Firebird recovery guide”. Disponível em: <http://www.ib-aid.com/articles/item73>. Acessado em: 10 de Setembro de 2013.