Artigo SQL Magazine 39 - Estratégias de recuperação de “desastres” no Firebird - Principais problemas e como evitar/solucionar

Estratégias de recuperação de “desastres” no Firebird

Principais problemas e como evitar/solucionar

Numa rápida procura no Google, conversando com alunos e professores de instituições de ensino superior, ou participando de listas de discussões sobre os mais variados assuntos ligados ao desenvolvimento de software ou banco de dados, vemos comumente pessoas reclamando de corrupção de dados com Firebird 1.X. Mas porque isto acontece? Como uma base de dados corrompe? O que são os tão temidos “internal gds software consistency check” e “Database file appears corrupt”? E principalmente: como evitar?

Problemas comuns

Talvez o leitor não acredite, mas o Firebird é um dos SGBDs mais fantásticos que conheço. Isto por que a maioria dos SGBDs disponível no mercado (Oracle, MS SQL Server, DB/2, PostgreSQL) não funcionaria ou suportaria um terço das desventuras que muitos candidatos à DBA em Firebird realizam. Sem maiores rodeios, vejamos as fontes de problemas mais comuns em bases de dados Firebird.

Equipamento Precário / Falhas de Hardware

Parece piada, mas há realmente casos de pessoas utilizando Windows 95 com 16 MB de RAM como servidor de rede; pessoas trabalhando há meses (ou anos) sem fazer um backup; ou sequer cogitar a compra de um UPS (no-break); pessoas utilizando jogos 3D no servidor (por ser a melhor máquina, e reiniciando indiscriminadamente ao primeiro sintoma de lentidão ou travamento); pessoas que desligam o cabo do servidor do HUB ou switch porque a internet está lenta (internet compartilhada). Tudo isto enquanto os demais tentam utilizar normalmente o banco de dados.

Isto sem contar aqueles casos de máquinas com memórias de qualidade duvidosa, discos defeituosos, processadores superaquecidos, sistemas operacionais com arquivos corrompidos ou danificados, servidores com vírus, rede mal projetada, HUBS “inteligentes” (de marcas conhecidas por produzirem equipamentos de baixo custo) que travam com um fluxo de dados relativamente baixo, cabos de força, telefone e rede passando na mesma tubulação, etc.

Em resumo, se houver algum hardware problemático, as chances de acontecerem falhas no banco de dados aumentam muito.

Alterações em Tabelas de Sistema

Existe um temor que rodeia a alteração de tabelas de sistema. Esta operação, no Firebird, está se tornando natural. Ferramentas como o IBExpert possibilitam operações não suportadas nativamente via SQL (inclusive em alguns momentos “mentindo” para o seu utilizador exibindo comandos que não existem) alterando diretamente as tabelas de sistema sem avisar aos candidatos a DBA (ou vítima, como preferirem) os reais riscos e problemas possíveis. Sendo assim, alterações aparentemente simples para o desenvolvedor e extremamente comuns durante o processo de modelagem e desenvolvimento, como trocar a obrigatoriedade ou não de um campo, podem danificar profundamente uma base de dados." [...] continue lendo...