Conectando a una Base de Datos desde dos servidores

2 comentarios

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

 

 

 

Anuncios

Error: database file appears corrupt

8 comentarios

Como seguramente sabes, debes revisar constantemente el archivo FIREBIRD.LOG que encontrarás en la carpeta donde instalaste al Firebird para descubrir cualquier error que haya ocurrido.

¿Qué significa el error: “database file appears corrupt“?

Que el archivo de la Base de Datos (el cual usualmente tiene la extensión .FDB) está dañado.

¿Por qué se dañó la Base de Datos?

La causa más común es porque hubo un corte de la energía eléctrica en la computadora donde se encuentra el Servidor mientras se estaba realizando una operación de INSERT, UPDATE, o DELETE.

A veces también podría ocurrir si hay una súbita alta tensión. O si algún descerebrado apagó el Servidor mientras la Base de Datos estaba siendo usada.

Entonces, el problema fue causado por dos motivos:

  1. Se estaba realizando una operación de INSERT, UPDATE, DELETE
  2. En ese instante se detuvo el Servidor del Firebird

Otra causa, tal como señaló Yván Acosta en la sección de comentarios, es que usando el Explorador de Windows o algún programa similar, se haya copiado la Base de Datos. Hay varios métodos seguros para realizar backups de las bases de datos, y alguno de esos métodos seguros hay que usar.

¿Cuál es la solución?

Usar el programa FirstAID (primera ayuda) de IBSurgeon, que encontrarás en www.ib-aid.com

¿Cómo evitar que el problema vuelva a ocurrir?

  1. Primero y elemental, colocarle una UPS (uninterruptible power supply) de buena capacidad a la computadora donde se encuentra el Servidor
  2. Verificar, al menos una vez a la semana que la UPS esté funcionando correctamente. Para ello, cuando nadie esté conectado a la Base de Datos, desenchufar la UPS del tomacorriente y anotar el tiempo que mantiene a la computadora encendida. Las UPS van disminuyendo el tiempo en que sus baterías proveen de carga eléctrica. Jamás hay que creer que una UPS que se instaló hace un año sigue funcionando como cuando era nueva. En la gran mayoría de los casos, eso es falso.
  3. Evitar que la computadora donde se encuentra el Servidor sea apagada.
  4. Evitar que el Servidor sea detenido, manualmente o por algún otro programa.

Con relación al punto 3. tengo una anécdota. En una empresa grande, que tiene decenas de computadoras, súbitamente todo el mundo se desconectó de la Base de Datos, había energía eléctrica, las luces estaban encendidas, las computadoras también, pero no había conexión a la Base de Datos, caos total. ¿Qué había ocurrido? Que la señora de la limpieza, con su escoba había desenchufado al Servidor, y siguió limpiando como si nada, no le importó lo más mínimo porque ni siquiera sabía la importancia de que ese cable estuviera enchufado. Al salir, cerró la puerta de la habitación y como se encuentra alejada de la Administración nadie se percató que unos minutos después la UPS empezó a chillar como loca. Se aprendió la lección, ahora el Servidor está en una habitación aparte y la puerta siempre se mantiene cerrada con llave, por las dudas. Y duplicados de esa llave solamente tienen las personas adecuadas, ninguna “señora de la limpieza” puede entrar.

Con relación al punto 4. hay que tener cuidado con los antivirus u otros programas similares porque podrían detener al Servidor. Es por ese motivo que fuertemente se aconseja que en la computadora donde se encuentra el Servidor del Firebird no se esté ejecutando ningún otro programa, ninguno, ni siquiera un antivirus.

Conclusión:

Una Base de Datos puede corromperse si el Servidor deja de funcionar mientras estaba realizando una operación de INSERT, UPDATE, o DELETE.

El problema puede solucionarse con el programa FirstAID de IBSurgeon, pero lo más conveniente es evitar que el problema ocurra. Para ello, jamás debe detenerse el Servidor si alguien está conectado a la Base de Datos.

Artículos relacionados:

FirstAID de IBSurgeon

Reparación de una Base de Datos corrupta

Manteniendo la Base de Datos en buen estado

Los métodos para hacer backup

El índice del blog Firebird21

El foro del blog Firebird21

Verificando la salud de la Base de Datos

16 comentarios

Como seguramente sabes, una Base de Datos puede dañarse (corromperse) por diversas razones si hay problemas en el hardware, en el software o en el manejo humano de ella.

Es por lo tanto importante que de vez en cuando verifiques que se encuentra operativa y en buen estado.

Los pasos a seguir son los siguientes:

1. Abrir la ventanita “Símbolo del sistema”

2. Escribir los comandos: SET ISC_USER=SYSDBA y SET ISC_PASSWORD=masterkey (o la que sea la contraseña del usuario SYSDBA)

VERIFICANDO1(si haces clic en la imagen la verás más grande)

La utilidad de esos SET es evitar tener que escribir el nombre del usuario (en este caso: SYSDBA) y la contraseña del usuario (en este caso: masterkey) en los comandos GFIX y GBAK que se usarán a continuación. En otras palabras, si escribimos los SET de arriba entonces no necesitaremos escribir nombre de usuario y contraseña ni en GFIX ni en GBAK.

3. Copia tu Base de Datos con otro nombre, porque la verificación se hará en la copia, no en la Base de Datos original. 

IMPORTANTE: No intentes copiar la Base de Datos directamente usando el Explorador del Windows, WinZip, WinRar, 7Zip o programas similares o lo que obtendrás será una Base de Datos corrupta. La forma correcta de realizar la copia (backup) se explica en este artículo: https://firebird21.wordpress.com/2013/07/03/los-metodos-para-hacer-backup/

NOTA: De ser posible, todos los pasos que vienen a continuación hazlos en otra computadora

4. Valida la Base de Datos

GFIX -validate -full MiBaseDatos.fdb

5. Si se encontró algún error, prueba con mend

GFIX -mend -full -ignore MiBaseDatos.fdb

6. Vuelve a validar la Base de Datos

GFIX -validate -full MiBaseDatos.fdb

7. Si hay algún error, prueba con GBAK

GBAK -backup -verbose -ignore -garbage MiBaseDatos.fdb MiBackup.fdk

8. Finalmente, intenta restaurar el backup

GBAK -create -verbose MiBackup.fdk MiBaseDatos.fdb

9. Si hay errores, pero puedes conectarte a la Base de Datos extrae una tabla por vez para detectar cual tabla (o tablas) está con errores. Si usas el programa EMS SQL Manager puedes conseguirlo ubicándote sobre el nombre de la tabla y luego haciendo clic con el botón derecho:

VERIFICANDO2

(si haces clic en la imagen la verás más grande)

Luego trata de hacer un SELECT sobre esa tabla, primero sin usar un índice, la segunda vez usando un índice ascendente y la tercera vez usando un índice descendente. De esta manera podrás saber cuales son las filas que están dañadas ya que los SELECT te mostrarán las filas que están ok y se detendrán en las que estén con errores.

NOTA: Los índices deben ser simples, o sea de una sola columna, no uses índices compuestos por varias columnas para esta verificación.

IMPORTANTÍSIMO:

Si descubres que una Base de Datos está corrupta debes detener su utilización INMEDIATAMENTE porque nuevas operaciones en ella (INSERT, UPDATE, DELETE, FETCH) solamente conducirán a más corrupción.

Artículos relacionados:

Los métodos para hacer backup

El índice del blog Firebird21

Detectando y evitando errores en las bases de datos

1 comentario

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

Page 99999 is an orphan

1 comentario

Si encuentras este error (por ejemplo, en el archivo FIREBIRD.LOG que se encuentra en la carpeta donde instalaste el Firebird) el problema es el siguiente:

  • Un índice está corrupto

En general ocurre cuando hay intensivos insert/delete/update en una sola transacción.

Deshabilitar los índices antes de intensivos insert/delete/update es bueno por dos razones:

  1. Las operaciones de insert/delete/update serán mucho más rápidas
  2. No se corromperán los índices

Al finalizar las operaciones de insert/delete/update hay que volver a habilitar los índices.

Observación: el número 99999 del título representa a cualquier número entero. Por ejemplo en tu caso podrías encontrar el mensaje: “Page 124062 is an orphan”