Temos uma política bastante restritiva em relação a anúncios no site. Eles nunca irão te atrapalhar!
Além disso, usamos banners para lhe informar de assuntos importantes. Os bloqueadores de anúncios impedem que esses banners sejam visualizados.
Sendo assim, para continuar, é importante que você desligue o bloqueador de anúncio e recarregue a página. Obrigado!

Previnir é sempre o melhor remédio, especialmente com BDs grandes!

Data da última atualização: 07/04/2017

Sendo parceiro da IBSurgeon no Brasil já há vários anos, trabalhei na recuperação de bases de dados corrompidas, dos mais diferentes tamanhos. Geralmente, o motivo da corrupção está sempre associado a fatores externos, como quedas de energia, falhas físicas de disco (hd), memória RAM corrompida, bem como pela não utilização do Forced Writes, que quando está ativo, diminui consideravelmente o risco de corrupção na ocorrência dessas anomalias.

Apesar da grande maioria dos casos terem sido resolvidos com grande sucesso e perda mínima dos dados, o tempo para recuperar uma base de dados é um fator primordial para muitos negócios, e geralmente está relacionado principalmente a dois fatores:

1. Gravidade e tipo de corrupção
2. Tamanho da base de dados

Sendo assim, mesmo que seja possível recuperar a base de dados, o tempo que isso pode levar é um fator decisivo para a viabilidade do serviço. Muitas empresas não podem ficar paradas por mais que algumas horas. Algumas preferem voltar algum backup antigo, e reinserir as informações perdidas manualmente, mas as vezes nem isso é possível, pela falta das informações, ou ainda pior, pela falta de backups.

Enquanto bases de dados menores, de até 10GB, geralmente podem ser recuperadas em algumas horas, bases maiores, com dezenas ou centenas de gigabytes, podem levar dias até a finalização do processo, um tempo muitas vezes inaceitável.

Meu conselho para empresas com bases de dados grandes, e que prezam pela disponibilidade das informações, é para que se previnam de forma a evitar o pior. Para bases grandes, a única forma realmente eficaz de prevenção é replicar a base de dados de produção em uma base réplica, localizada em outro servidor, preferencialmente dentro da mesma rede local. Apesar do Firebird ainda não ter replicação nativa (a replicação unidirecional será lançada no Firebird 4), você pode desenvolver sua própria solução de replicação, ou então usar replicadores de terceiros, que existem tanto gratuitamente como comercialmente.

Entre as soluções de replicação comerciais disponíveis no momento, a mais efetiva e fácil de ser implementada é o HQBird, uma distribuição avançada do Firebird, criada pela IBSurgeon. Entre as ferramentas que compõe o pacote HQBird, está uma versão do Firebird (2.5 ou 3.0) que disponibiliza replicação nativa de forma síncrona ou assíncrona. O mais interessante é que esse "Firebird turbinado" é totalmente compatível com o Firebird que você já conhece, ou seja, ao usar a replicação do HQBird, você não perde a compatibilidade com o Firebird padrão. Além disso, a replicação é feita de forma nativa, portanto, sem a necessidade da criação de triggers para esse trabalho!

O HQBird é vendido em 3 versões: Standard, Professional e Enterprise. Apenas a Enterprise possui o recurso de replicação nativa. Observe também que ele inclui diversas outras ferramentas de monitoramento e otimização de servidores e bases de dados Firebird. Considero essas ferramentas essenciais para empresas que zelam pela disponibilidade dos seus dados. Lembrando também que os brasileiros podem adquirir o HQBird com desconto especial, somente através dos links disponíveis aqui.

Você pode baixar uma versão demonstração do HQBird e testa-lo durante alguns dias! Existem diversos vídeos com tutoriais em português sobre algumas ferramentas do pacote.

Fica a dica!

Carlos H. Cantu