post icon

Pérdida de Datos en Firebird (Experiencias…)

El texto es largo, pero es una experiencia que podría ayudar a evitar que se repitan situaciones similares nuevamente.

Como todos conocen, Firebird, uno de los motores de Base de Datos Libres de auge en los últimos años, es un motor de Base de Datos de amplia aceptación entre los desarrolladores de Delphi, y ciertas aplicaciones en Java u otros lenguajes de programación.

También es conocido que las facilidades de uso y administración que provee el Firebird a los DBA’s y usuarios, muchas veces nos lleva a situaciones donde hay corrupción de información, y pérdida de datos (estos podrían ser registros sencillos, estructuras, y tablas con datos completas). Algunas de las formas más comunes por las cuales uno podría perder datos, se encuentran en la Documentación del Firebird mismo, cuya versión Web es accesible desde este link (Inglés requerido).

Lo que hoy les comentaré, no es una  de las situaciones “normales” donde la información se corrompe, al contrario, es una mezcla de situaciones particulares, que pueden llevar a la perdida de datos de una forma irrecuperable.

Primero, una breve descripción de como trabaja el servicio del Firebird a nivel Windows… luego de su instalación, el Firebird levanta 2 aplicaciones a memoria, el servicio en sí, y el Guardián, que se encarga de mantener el servicio arriba, y de la misma forma el servicio se encarga de que el Guardián se ejecute en memoria de manera constante.

Estos servicios son los que controlan que cuando un usuario esta intentando reemplazar el archivo FDB de la Base de Datos desde el Sistema Operativo reciba los mensajes de que el archivo está en uso, y no puede ser reemplazado, y esto permanecerá de esta forma, mientras exista al menos 1 conexión existente con la Base de Datos.

Ahora, llevemos el mismo ambiente al entorno Linux, y tenemos una serie de extras que no suceden en el entorno Windows.

En Linux, el servicio/demonio que ejecuta el Firebird, a diferencia de Windows, bajo ciertas circunstancias permiten sobreescribir una base de datos en uso por el usuario (sea por Copiar/Pegar, o Restore Database). Porque permite esto?

Durante la ejecución del servicio, y apertura de una conexión a la Base de Datos, si la misma no es grande, es copiada en su totalidad al área de SWAP del Sist. Operativo, y se guarda una referencia al I-Nodo original del mismo. Mientras la Base de Datos este en uso, las transacciones y operaciones realizadas se escribirán primero en el SWAP y luego por la referencia del I-Nodo, se buscará el archivo original y se escribirán los datos en él, por lotes.

¿Que sucede al reemplazar (sobreescribir) un archivo FDB en uso? Algo sencillo, y a la vez, fatal: el Linux administra las conexiones entrantes de los usuarios, y las direcciona a la versión existente en el SWAP de la Base de Datos, y cuando intenta escribir los datos al disco, el I-Nodo de referencia resulta ser incorrecto, ¿entonces que pasa?

No se pueden escribir los datos al disco duro desde el momento en que la DB fue reemplazada, y como nuestros datos se quedan en el SWAP, al cerrarse todas las conexiones a la Base de Datos Firebird, el Linux elimina el archivo que está en el SWAP  porque ya no hay conexiones que lo utilicen, y nuestra versión en el disco duro, permanece inalterada desde el momento en que se sobreescribió al disco.

Esta situación puede afectar seriamente el funcionamiento de la empresa donde acontece el inconveniente, ya que conlleva a una perdida de información permamente e irrecuperable. En la web (varios casos que se pueden googlear en inglés) se pueden apreciar pérdidas de datos de varios días, y la más extensa que pude encontrar, perdida de 1 año y medio de datos de una base de datos multi-volúmen.

¿Se puede evitar esta clase de problemas? Tal vez sí… una de las opciones que hace que los datos se escriban al disco duro de forma obligada y constante, es “Forced Writes” (habilitable por la herramienta “gfix”) y por default, la misma está deshabilitada en entornos Linux (en Windows, viene activada por default).

¿Pudo un Backup (copia de seguridad) salvarnos del problema? Lastimosamente al recrear el error en un ambiente controlado, uno se da cuenta que aún una política de backups bien armada, hubiese sido inútil, ya que el comando del archivo ejecutable “gbak” se ejecuta sobre la versión existente en el disco duro, y por la forma en que se desarrolla el inconveniente, estos datos no serán distintos a los que verán los usuarios luego de reabrirles las conexiones.

Si bien, no hay una solución real al problema, el post es para que la gente que administra Bases de Datos Firebird, no deje de lado las buenas prácticas de la Administración de Servidores de Bases de Datos, y tenga especial atención en la configuración de trabajo del Servidor, para evitar situaciones como la presentada en las lineas anteriores.

Comentarios desde Facebook:

  1. avatar
    mongaru PARAGUAY Google Chrome Windows
    8 junio 2010 at 10:38 #

    una opcion a este problema no seria hacer bkps con archivios sql?

    Una pregunta concreta. Si se deja de usar la bd y se copia el archivo de base de datos (ya que en firebird es uno solo) o se utiliza el gbak el problema persiste?

    gracias

    • avatar
      GeekZero PARAGUAY Mozilla Firefox Windows
      8 junio 2010 at 12:40 #

      Hola Mongaru, lo correcto sería dejar la BD en modo "Single User" con el gfix, y luego generar un backup con el gbak.

      Ahora si queres copiar la BD tal cual [proceso que deberia no permitir] debes dejar en Single User, y forzar la escritura del swap al disco, también con el gfix.

Responder