Um dos grandes pontos fortes do Firebird sempre foi a facilidade de instalação, configuração e uso. Enquanto muitos bancos de dados famosos necessitam de administração constante, definição de espaço para armazenamento, etc… o Firebird quase que não tem configuração alguma !
A aparente simplicidade não significa no entanto falta de recursos ou baixa performance, muito menos instabilidade. Tenho bancos de dados Firebird rodando há vários anos com um volume considerável de informação, sem nunca ter tido necessidade de utillizar qualquer tipo de ferramenta de recuperação de dados.
No entanto, como qualquer outro software, o Firebird está sujeito à todos os intempéries da informática, incluindo-se aí as “travadas”, GPFs, quedas de energia, falhas de hardware, raios, etc… Sendo assim, é necessário que alguns cuidados sejam tomados para prevenir o pior. A seguir listarei alguns passos que devem ser seguidos para que possamos ter uma saída menos traumática no caso de alguma coisa dar errado :
1. TENHA SEMPRE BACKUPs
Sim, é isso mesmo. Eu não poderia começar essa lista de outra forma. O velho conselho muitas vezes ignorado por usuários e profissionais de informática é sem dúvida nenhuma o melhor método para se sair bem de um desastre. É muito importante manter cópias do banco de dados, sejam elas em forma de backups feitos através do GBAK ou uma simples cópia física do arquivo FDB (lembrando de que para garantir a integridade do arquivo deve-se dar um shutdown no servidor antes da cópia, ou utilizar o nBackup presente no FB >= 2.0).
Atenção: Caso decida utilizar o nBackup para fazer backups incrementais, tenha certeza de estar usando uma versão atualizada do Firebird, pois vários bugs no nBackup foram descobertos após o lançamento do Firebird 2, e foram corrigidos nas versões mais recentes.
2. O SISTEMA OPERACIONAL DEFINITIVAMENTE É IMPORTANTE
O Firebird é um dos poucos servidores SQL que rodam em diversas plataformas e sistemas operacionais (Windows 9x, NT, 2000, Linux, HP UX, Solaris, etc…). Isso permite ao desenvolvedor uma certa liberdade de escolha de que sistema operacional utilizar, levando-se em conta principalmente a estabilidade e a segurança.
Entre todos os sistemas operacionais suportados pelo FB, sem dúvida nenhuma os mais estáveis e seguros são os derivados do UNIX. O (Li)UNIX já tem uma tradição consolidada como um sistema operacional voltado à servidores e caso você tenha essa opção, recomendo que seja o sistema operacional escolhido. O Windows 2000 ou 2003 também podem ser utilizados pois são mais estáveis que seus antecessores e contam com a facilidade da interface com o usuário, apesar de que o Linux vem chegando cada vez mais perto ao Windows nessa categoria.
Usando um sistema operacional estável você diminui e muito as chances de ter seu banco de dados corrompido devido à instabilidade e travadas do mesmo.
3. NO BREAK
Tão importante quantos as opções já mencionadas é o uso de Nobreaks, ao menos no servidor. Se houver uma falha de energia no servidor enquanto o Firebird tentava gravar informações no disco há uma grande possibilidade de que seu banco seja corrompido, até mesmo ao ponto de não poder ser recuperado, fazendo com que sua única opção seja recorrer à um backup.
A opção Forced Writes (que pode ser configurada individualmente para cada FDB através do gfix, ou globalmente através do arquivo firebird.conf) também é um fator decisivo para a integridade dos dados. Ela diz ao Firebird se ele deve gravar as informações diretamente no HD ou deve deixar que o cache do Sistema Operacional decida quando fazê-lo. Com Forced Writes ON seus dados são gravados imediatamente e portanto as chances de serem perdidos devido à uma queda de energia é reduzida. O default do Firebird no Linux é ter o Forced Writes OFF e nos outros sistemas operacionais é ON.
É claro que tudo tem um preço e manter a opção Forced Writes ON pode implicar em uma perda de performance principalmente em aplicativos que façam gravações de dados em massa. Clique aqui para ver um artigo sobre Forced Writes. Note que até o Firebird 2.0, a opção de ativar o Forced Writes no Linux não tinha qualquer efeito. Isso foi descoberto e corrigido no FB 2.1
4. USO DE SERVIDORES DEDICADOS
Ora, já que qualquer “travada” pode ter consequencias não muito agradáveis no seu banco de dados, rodar o Firebird em um servidor dedicado com certeza é uma ótima escolha. Não só pela segurança, mas também pelo ganho de performance pois o servidor não precisa dividir seu processamento com mais ninguém.
5. REDE CONFIÁVEL
Não adianta seu servidor estar em ponto de bala se o seu Hub ou seus cabos de rede estão “detonando” as informações enquanto elas viajam pela rede. Procure usar equipamentos confiáveis e seguir os padrões recomendados pelos comitês de normas técnicas.
6. TOME CUIDADO COM OS BUGS
Como qualquer software existente no mundo, o Firebird/InterBase não está livre de bugs e alguns deles podem ter consequências desastrosas para o BD. Podemos citar como exemplo um bug presente na versão 6.0 do IB onde se você acessar o mesmo banco de dados (GDB) utilizando PATHs diferentes pode fazer com que seu banco seja irreparavelmente danificado. Ex:
Servidor:c:\dados\banco.FDB <=> Servidor:c:dados\banco.FDB
7. EM ÚLTIMO CASO, LEMBRE-SE DO GFIX
O Firebird vem acompanhado de um utilitário de reparação de dados chamado GFIX. Com ele você pode recuperar na maioria das vezes bancos de dados que foram corrompidos pelos mais variados motivos. No site da FireBase há um artigo completo mostrando como usar o GFIX.
8. CUIDADO COM OS PENETRAS
Manter os intrusos (hackers) longe é uma preocupação cada vez mais constante, principalmente na atualidade onde os ataques são cada vez mais frequentes. O Firebird utiliza a porta 3050 do TCP/IP para se comunicar com os clientes na rede. Ataques através dessa porta pode de alguma maneira afetar seu banco de dados. Você pode tomar algumas medidas de precaução, como utilizar um Firewall e limitar o acesso à porta 3050 apenas aos computadores pertencentes à uma rede confiável (como sua rede interna por exemplo), bem como checar e limitar o número de tentativas de login frustradas.
9. CUIDADOS COM AS UDFS
As UDFs, ou Funções Definidas pelo Usuário, são um dos recursos mais poderosos do Firebird. Elas permitem uma grande liberdade em termos de funções desenvolvidas, mas você deve tomar cuidado quando desenvolver uma UDF. Apesar de teoricamente possível, não se deve fazer com que uma UDF interaja diretamente com o banco de dados, ou seja, nunca faça uma UDF manipular dados diretamente no Banco. Cuidado também com UDFs que nunca retornam. Lembre-se que enquanto a UDF não retorna um valor ao FB, o processamento no servidor para a conexão fica interrompido!
10. QUANDO NADA MAIS ADIANTAR E O BACKUP NÃO FOR UMA OPÇÃO…
…você pode recorrer ao nosso suporte especializado na recuperação de bases de dados corrompidas.
Conclusão
Seguindo os conselhos contidos nesse artigo você dificilmente irá ter problemas de perda de dados com o Firebird.