Aunque las bases de datos de Firebird son muy seguras siguen siendo archivos de computadora y por lo tanto pasibles de corrupción, como cualquier otro archivo, cuando no se toman las medidas apropiadas.

Por lo tanto, lo importante es detectar si están corruptas y tomar las debidas precauciones para disminuir la probabilidad de que tal cosa ocurra.

Razones típicas que provocan corrupción en las bases de datos

  1. Se hace el backup de forma inapropiada. O sea, sin usar GBAK, NBACKUP, sin previamente haber ejecutado el comando ALTER DATABASE … BEGIN BACKUP o sin detener el Servidor
  2. Antivirus. Si realizan su tarea mientras la Base de Datos está en uso potencialmente podrían provocar errores
  3. Fallas en el disco duro. Si justo se dañó el disco duro donde se encuentra alojada la Base de Datos. Cuanto mayor sea el tamaño de ésta es mayor la probabilidad de que tal problema ocurra.
  4. Cuelgue del Servidor teniendo “forced writes” inactivo. Este problema se da principalmente bajo Windows.
  5. Detención del Servidor mientras se estaban cambiando los metadatos. Si el cambio era en los datos, solamente se podrían perder los últimos ingresados, pero si era en los metadatos la corrupción es posible.

Precauciones para evitar esas razones típicas

  1. Si usas un programa automatizado para hacer backup, excluye la carpeta donde se encuentran las bases de datos y también todas las carpetas donde se guardan los archivos temporales (definidas en la entrada TempDirectories del archivo FIREBIRD.CONF). Esas carpetas no deben ser compartidas para evitar que sean accedidas desde otras computadoras. Excluye también la carpeta donde instalaste el Firebird. Instruye a tus usuarios para que jamás copien las bases de datos con programas como el Explorador del Windows, WinZip, WinRar, 7Zip, etc.
  2. Si el antivirus examina a la Base de Datos mientras está siendo usada puede dañarla. Por lo tanto hay que configurar a los antivirus para que ignoren a las bases de datos y también a los archivos temporales del Firebird
  3. Las fallas en el disco duro son relativamente frecuentes. Los discos duros no son eternos aunque muchos usuarios así lo crean. A mayor tamaño de la Base de Datos, mayor probabilidad de que una parte de ella se encuentre en la parte dañada del disco duro. Por lo tanto, discos duros mucho más grandes que el tamaño total estimado de las bases de datos es una buena medida. También la verificación periódica del estado del disco duro.
  4. Si se “cuelga” el Servidor y se tiene forced writes en OFF la corrupción de la Base de Datos está garantizada. Este problema se da principalmente en Windows porque cuando está en OFF él graba los datos en el disco duro cuando se le ocurre, pueden pasar horas e inclusive días. En cambio cuando está en ON la grabación se efectúa inmediatamente. La ventaja de estar en OFF es que las operaciones de INSERT, UPDATE, DELETE son más rápidas, la desventaja es que si se cuelga el Servidor…terminas con una Base de Datos corrupta.
  5. Si se detiene el Servidor mientras los usuarios están insertando, actualizando o borrando datos lo peor que podría ocurrir es que lo último que hicieron no se haya grabado en la Base de Datos. Pero si se detiene el Servidor mientras se estaban actualizando los metadatos (tablas, índices, stored procedures, triggers, etc.) entonces sí podría haber corrupción.

Conclusión:

En un entorno configurado apropiadamente y con un hardware saludable las corrupciones no ocurren.

Hay una sola causa física (falla del disco duro) que puede conducir a corrupción de las bases de datos. No es mucho lo que podamos hacer para evitarla aunque por supuesto debemos periódicamente verificar el estado en el que se encuentra el disco duro.

Todas las otras causas son problemas de software o de procedimientos humanos y sí pueden ser evitadas.

En otras palabras, simples y sencillas: si la Base de Datos se corrompe y no fue debido a falla del disco duro … la culpa es toda tuya.

Artículos relacionados:

Los métodos para hacer backup

El índice del blog Firebird21