Si tu intención es corromper, destruir, destrozar internamente, a una Base de Datos del Firebird, esta es una de las formas más seguras de conseguirlo.

Así que si tu intención es mantener a la Base de Datos en muy buen estado de conservación, jamás hagas algo así.

Veamos un poco más detalladamente lo que sucedería si intentas conectarte a una misma Base de Datos desde dos (o más) servidores de Firebird al mismo tiempo.

Como recordarás, Firebird tiene tres arquitecturas: Classic, SuperClassic, SuperServer.

Classic y SuperClassic son ejecutados a través de un programa que se llama FB_INET_SERVER.EXE y realizan los bloqueos correctos usando el proceso FB_LOCK_MGR.

Entonces, aunque cada conexión usando Classic y SuperClassic se hace mediante servidores distintos (cada instancia ejecuta a un FB_INET_SERVER.EXE), el proceso FB_LOCK_MGR se encarga de gestionar esas conexiones asegurándose de que la Base de Datos no se corrompa.

SuperServer por otro lado es ejecutado a través de un programa que se llama FBSERVER.EXE, el cual requiere acceso exclusivo a la Base de Datos así que resulta imposible que otro Servidor pueda acceder a una Base de Datos a la cual alguien ya se conectó usando SuperServer. Y también que si alguien ya se conectó a una Base de Datos (usando Classic, SuperClassic, o SuperServer)  alguien más pueda conectarse a ella usando otro Servidor SuperServer.

Entonces la situación es la siguiente:

  • Si alguien se conectó a una Base de Datos usando SuperServer, nadie más podrá conectarse a esa Base de Datos usando otro Servidor (sea Classic, SuperClassic, o SuperServer dicho Servidor).
  • Si alguien se conectó a una Base de Datos (usando Classic, SuperClassic, o SuperServer), conectarse a esa Base de Datos usando otro Servidor, que sea SuperServer, será imposible.
  • Si alguien se conectó a una Base de Datos usando Classic o SuperClassic conectarse a esa Base de Datos usando otro Servidor que sea Classic o SuperClassic, sí es posible … pero corromperá a la Base de Datos.

El último punto es el peligroso.

¿Y por qué se corromperá la Base de Datos?

Hay dos cosas que pueden salir mal, muy mal.

Primero. Los índices estarán corruptos. Si desde el Servidor 1 se están insertando filas a una tabla y desde el Servidor 2 también se están insertando filas a esa misma tabla, cada Servidor actualizará los índices de la tabla, al mismo tiempo, y eso ocasionará un desbarajuste mayúsculo. Esto es solucionable. Cuando ningún Servidor está insertando ni borrando ni modificando filas de esa tabla se reconstruyen los índices y asunto solucionado. Pero si se trata de una tabla que tiene muchos movimientos tantas reconstrucciones de índices afectarán gravemente al rendimiento y además mientras tanto las consultas mostrarán datos incorrectos y los procesos también realizarán actualizaciones incorrectas.

Segundo. Un Servidor sobre-escribe las páginas del otro Servidor. Esto es gravísimo porque causará corrupción en el 100% de los casos. Como recordarás, Firebird guarda todo, absolutamente todo lo que se hace en una Base de Datos en bloques de bytes llamados páginas. Si hay dos servidores accediendo a una misma Base de Datos, no se tendrá una buena administración de esas páginas porque cada Servidor llamará a un proceso FB_LOCK_MGR diferente. Y cada uno de esos procesos guarda el estado actual de las páginas de la Base de Datos en una porción de memoria RAM a la cual tiene acceso exclusivo.Por ejemplo: el Servidor 1 necesita una nueva página para datos de la tabla VENTAS, ve que la página número 123456 está libre y marca esa página para contener datos de la tabla VENTAS. Todo bien hasta ahí. Pero el Servidor 2 también necesita una nueva página, en este caso para guardar los índices de la tabla PRODUCTOS, ve que la página número 123456 está libre y marca a esa página para contener los índices de la tabla PRODUCTOS. ¿Consecuencia? Que las ventas que se guardaron en la página 123456 se perdieron totalmente. Y que los índices que correspondían a esas ventas están huérfanos. Los productos no tendrán problemas, pero las ventas se corrompieron. Por supuesto que más adelante la situación puede ser a la inversa y los datos corruptos son los correspondientes a la tabla de PRODUCTOS. El problema por lo tanto es que si dos o más servidores están conectados a una misma Base de Datos la correcta administración de las páginas de esa Base de Datos será imposible, y la corrupción no tardará en llegar.

Conclusión:

Conectarse a una misma Base de Datos usando dos servidores, siendo al menos uno de esos servidores SuperServer, es imposible.

Si los servidores son Classic o SuperClassic la conexión sí es posible, pero con toda seguridad causará corrupción a la Base de Datos.

¿Por qué se corromperá la Base de Datos?

Un problema se tendrá con los índices, y aunque esto es solucionable será muy molesto porque se tendrá que reconstruirlos constantemente y eso hará que todas las operaciones se vuelvan muy lentas, o que las consultas muestren datos inconsistentes.

Pero el problema realmente grave se tendrá con las páginas de datos que fueron escritas por uno de los servidores y sobre-escritas por el otro Servidor. Esto ocurrirá porque cada Servidor guarda en una porción de la memoria RAM  (que es de su uso exclusivo) el estado de las páginas de la Base de Datos. Por lo tanto, lo que hace un Servidor el otro Servidor no lo sabe, lo ignora completamente.

Y claro, un Servidor marca una página para que guarde algo, y el otro Servidor marca a esa misma página para que guarde otra cosa. ¿Consecuencia? Corrupción asegurada, 100% asegurada.

Artículos relacionados:

Entendiendo las páginas de la Base de Datos

Eligiendo el tamaño adecuado de las páginas de la Base de Datos

El índice del blog Firebird21

El foro del blog Firebird21