Especificando el archivo FIREBIRD.MSG que queremos usar

Deja un comentario

Este artículo está basado en el artículo:

http://www.firebase.com.br/fb/artigo.php?id=2644

Cuando instalamos al Firebird se copia en el disco duro un archivo llamado FIREBIRD.MSG que contiene los mensajes que mostrará el propio Servidor del Firebird y también algunos de los programas utilitarios que vienen incluidos en la instalación, tales como el GBAK.EXE, el GFIX.EXE, etc.

Si en la computadora hemos instalado solamente una versión del Firebird entonces no tendremos problema, siempre veremos los mensajes correctos, pero si hemos instalado al Firebird más de una vez entonces podremos encontrarnos con un mensaje similar al siguiente:

can't format message...

gbak: writing data for table @1
gbak:@1 records written

¿Qué significa eso?

Que no puede encontrar al archivo FIREBIRD.MSG o que el archivo FIREBIRD.MSG que encontró no corresponde a la versión del Firebird que se está ejecutando.

¿Cómo lo resolvemos?

Configurando a una variable de ambiente llamada FIREBIRD_MSG con la ruta completa al archivo FIREBIRD.MSG que queremos usar, así:

MSG1

Captura 1. Si haces clic en la imagen la verás más grande

Y a continuación podemos llamar al utilitario GBAK.EXE, al utilitario GFIX.EXE, etc. y todos los mensajes aparecerán correctamente formateados.

Alternativa:

La forma de resolverlo mostrada arriba siempre funcionará pero si queremos que funcione sin necesidad de configurar a la variable de ambiente FIREBIRD_MSG deberemos hacer lo siguiente:

  • Copiar el archivo FIREBIRD.MSG en la carpeta superior de donde se encuentra el archivo FBCLIENT.DLL

En Windows lo aconsejable es que el archivo FBCLIENT.DLL se encuentre en la misma carpeta en la cual se encuentra el .EXE de nuestra aplicación.

Por lo tanto, en la misma carpeta donde se encuentra nuestro ejecutable CONTA.EXE, STOCK.EXE, VENTAS.EXE, SUELDOS.EXE, etc. copiamos al archivo FBCLIENT.DLL y en la carpeta superior copiamos al archivo FIREBIRD.MSG

Artículos relacionados:

El índice del blog Firebird21

El foro del blog Firebird21

 

Anuncios

Mejorando el rendimiento de las bases de datos (3)

1 comentario

En artículos previos ya habíamos visto algunos métodos que podemos usar para mejorar el rendimiento de nuestras bases de datos ya que lo usual es que deseemos obtener más velocidad para todas las operaciones (inserciones, actualizaciones, borrados, consultas).

En cuando al Sistema Operativo a usar podemos leerlo en este enlace:

https://firebird21.wordpress.com/2013/08/15/cual-sistema-operativo-usar-en-el-servidor/

Administración:

En este apartado veremos lo que puede hacer el Administrador de la Base de Datos para que ésta funcione mejor. Una de las tantas cosas buenas que tiene Firebird es que no necesita de un Administrador dedicado exclusivamente a su tarea, como sí es el caso de Oracle o de SQL Server. Las bases de datos de Firebird requieren de un mantenimiento mínimo, pero de todas maneras requieren de mantenimiento, aunque sea de vez en cuando. Las tareas básicas del Administrador son:

  1. Detectar y eliminar las transacciones que demoran mucho en finalizar
  2. Hacer un barrido manual
  3. Hacer un backup y verificar que funcione
  4. Verificar los identificadores de las transacciones
  5. Verificar las estadísticas de los índices y reconstruirlos si es necesario

1. Detectando y eliminando transacciones que demoran mucho en finalizar

Lo que más puede degradar el rendimiento de las bases de datos es que se actualicen o se borren filas y que la transacción que actualizó o borró esas filas no termine con un COMMIT o con un ROLLBACK.

Una transacción que no terminó ni con un COMMIT ni con un ROLLBACK para el Firebird continúa activa, aunque hayan pasado días, semanas, o meses. Y continúa activa porque el Firebird no puede saber, no puede adivinar, si la transacción no finalizó porque el Desarrollador no quiere que finalice aún o porque el Desarrollador se olvidó de escribir un COMMIT o un ROLLBACK. Como el Firebird no es adivino entonces por las dudas mantiene a la transacción abierta, no la cierra por su propia cuenta ya que cerrar la transacción es competencia exclusiva del Desarrollador, no del Firebird.

Entonces, una de las tareas del Administrador de la Base de Datos es verificar si hay transacciones que están activas desde hace mucho tiempo. En una aplicación bien programada ninguna transacción debería tardar más de unos cientos de milisegundos en finalizar. Si una transacción tarda más de un segundo eso ya debería llamar la atención a cualquier Administrador competente. Y ni que hablar si hace horas o días que está activa. Para saber como detectar y eliminar las transacciones que están activas desde hace mucho tiempo puedes leer estos artículos:

https://firebird21.wordpress.com/2013/03/02/detectando-aplicaciones-y-usuarios-que-mantienen-las-transacciones-abiertas-durante-mucho-tiempo/

https://firebird21.wordpress.com/2013/05/07/detectando-una-consulta-que-esta-tardando-mucho/

Aunque el título del último artículo dice “detectando una consulta” en realidad se refiere a transacciones.

Después de detectar y eliminar la transacción problemática hay que buscar y encontrar el motivo. ¿Por qué esa transacción demoró tanto? ¿Cuál es el programa que inició esa transacción? ¿por qué no finalizó ni con un COMMIT ni con un ROLLBACK?

Aquí, el Administrador debe comunicarse con el Desarrollador para informarle del problema que encontró y pedirle que lo solucione a la brevedad posible.

2. Haciendo un barrido manual

El barrido (sweep, en inglés) debe hacerse sí o sí cuando la diferencia entre la OST y la OAT es grande. Aquí, la palabra “grande” depende del contexto. Por defecto el Firebird inicia el sweep cuando esa diferencia es mayor que 20.000 pero ese número puede ser cambiado si se lo desea. Lo importante a recordar es que el sweep es un proceso que consume muchísimos recursos y en consecuencia todas las operaciones con la Base de Datos pueden volverse lentísimas. Es por ese motivo que la mayoría de los Administradores ponen el intervalo del sweep en 0 (cero) para realizarlo de forma manual, porque si se inicia de forma automática entorpecerá las actividades normales de los usuarios desde que empieza hasta que finaliza (según la conocida Ley de Murphy empezará en el peor momento posible, cuando más velocidad necesitan los usuarios), lo cual puede demorar horas en una Base de Datos muy grande y con mucha basura acumulada. Es por eso que muchos Administradores hacen el sweep en horarios en que nadie está usando la Base de Datos (y si eso no es posible, entonces en un día y hora en que muy pocas personas la están usando).

Puedes leer más sobre el sweep en este artículo:

https://firebird21.wordpress.com/2013/09/11/entendiendo-sweep-y-garbage-collection/

Resumiendo:

a) Si no se hace el sweep y la diferencia entre la OST y la OAT es grande entonces todas las operaciones se volverán muy lentas.

b) Mientras se está haciendo el sweep todas las operaciones se vuelven muy lentas

Recomendación:

Hacer el sweep cuando nadie está usando la Base de Datos o cuando muy pocas personas la están usando.

3. Haciendo un backup y verificando que funcione

Tener backups actualizados es algo tan elemental que supongo que no es necesario abundar sobre ese tema. Ningún profesional de la Informática tiene la menor duda al respecto.

Pero la tarea del Administrador no se limita a hacer backups, también debe verificar que ese backup pueda ser restaurado exitosamente. ¿Por qué? porque no hay algo peor que creer que se tiene un backup actualizado y a la hora de restaurarlo se descubre que no es posible lograrlo, que está dañado y es inútil e inservible.

Una regla muy conveniente para seguir es la siguiente:

    • Se hace un backup
    • Se lo restaura para asegurarse de que funciona
    • Se copia el backup en otro dispositivo y se lo lleva lejos de la computadora donde se encuentra el Servidor

De lo anterior se deduce que siempre tendremos al menos dos backups idénticos. Uno de ellos se mantendrá cerca del Servidor para poder restaurar rápidamente la Base de Datos en caso de ésta tener algún problema. El otro backup se mantendrá lejos del Servidor (en otro edificio o inclusive en otra localidad) para poder restaurar la Base de Datos en caso de catástrofe (terremoto, incendio, inundación, explosión de una bomba, robo de la computadora, etc). También es muy conveniente tener una copia en Internet. En esta época hay muchos sitios que permiten almacenar archivos grandes (MediaFire, Mega, RapidShare, DropBox, etc.) y tener el backup guardado en ellos es muy conveniente porque permiten que ese backup sea recuperado aún en el caso de ocurrir una catástrofe.

Si el backup se hace con el programa GBAK.EXE se tienen además otras ventajas:

    • El backup no tiene basura porque la basura no se  guarda en el backup
    • Cuando se restaura el backup se reconstruyen los índices así que al finalizar la restauración los índices estarán perfectos

4. Verificando los identificadores de las transacciones

Todo buen Administrador debe verificar periódicamente los identificadores de las transacciones porque como sabemos así se puede detectar si la Base de Datos tiene mucha basura. Puedes leer más en este artículo:

https://firebird21.wordpress.com/2013/09/08/entendiendo-los-identificadores-de-las-transacciones/

5. Verificando las estadísticas de los índices y reconstruyéndolos

Los índices pueden ir degradándose, eso ocurre frecuentemente cuando en una tabla se actualizaron o se borraron muchas filas. Por ese motivo es conveniente reconstruirlos de vez en cuando, puedes leer más en estos artículos:

https://firebird21.wordpress.com/2013/03/02/mantenimiento-de-indices/

https://firebird21.wordpress.com/2013/03/03/recreando-los-indices-de-las-tablas/

https://firebird21.wordpress.com/2013/03/09/selectividad-de-los-indices/

https://firebird21.wordpress.com/2013/08/24/usando-indices-en-firebird/

Conclusión:

Aunque afortunadamente Firebird no requiere que una persona trabaje exclusivamente como Administrador de las Bases de Datos, sí hay tareas que deben realizarse de vez en cuando para asegurarse de que las bases de datos se encuentren en un buen estado operativo, de lo contrario se irán degradando y el rendimiento decaerá. Si todo se realiza de la forma correcta, la tarea del Administrador no demorará más que unos cuantos minutos cada día e inclusive si la empresa u organización no es muy grande el trabajo podría ser de unos cuantos minutos a la semana o al mes.

Si todas las transacciones son cortas, todas las transacciones finalizan con un COMMIT o con un ROLLBACK, se hacen backups y restauraciones diarios, entonces nunca deberías tener problemas y todo debería funcionar de maravillas.

Pero no te olvides que tú o alguien más debe dedicarle un poco de tiempo a la tarea de Administrar la Base de Datos, solamente el ojo humano puede detectar fallas, eso es algo que no se puede automatizar.

Artículos relacionados:

¿Cual Sistema Operativo usar en el Servidor?

Detectando aplicaciones y usuarios que mantienen las transacciones abiertas durante mucho tiempo

Detectando una consulta que está tardando mucho

Entendiendo sweep y garbage collection

Entendiendo los identificadores de las transacciones

Mantenimiento de índices

Recreando los índices de las tablas

Recreando todos los índices de todas las tablas

Recreando índices y calculando estadísticas

Selectividad de los índices

Usando índices en Firebird

El índice del blog Firebird21

Manteniendo la Base de Datos en buen estado

2 comentarios

Las bases de datos de Firebird es difícil que se corrompan, pero no imposible. Después de todo se trata de archivos de computadora y no existe una fórmula mágica que las salve de la corrupción.

La corrupción puede deberse a:

  • Problemas de hardware
  • Problemas de software
  • Problemas de mantenimiento

Problemas de hardware

  1. Apagado anormal. Es muy raro pero puede ocurrir, sobre todo si FORCED WRITES está en OFF. En Windows siempre debería estar en ON porque el Windows puede tardar mucho tiempo en guardar físicamente en el disco lo que se le pidió que guarde físicamente en el disco. Ese “mucho tiempo” puede ser minutos, horas, e incluso días.
  2. Disco duro levemente dañado. Ocurre cuando solamente algunos clusters se dañan y tuviste la mala suerte de que tu Base de Datos esté usando algunos de esos clusters. El sistema operativo los marca como dañados y no lee el contenido. Esto provoca que algunas partes de la Base de Datos no puedan ser leídas. Por ejemplo, se pueden leer algunas filas de una tabla, pero no todas las filas.
  3. Disco duro fuertemente dañado. Quizás a causa de una fuerte caída, un incendio, cosas así. En estos casos puedes utilizar un programa como R-Studio que encontrarás en: http://www.data-recovery-software.net/ o llevar el disco duro a alguna empresa que se especializa en recuperar discos duros dañados, pero el problema con esta última opción es que puede ser muy cara, nunca cobran por debajo de los 1.000 dólares por su servicio.
  4. Memoria RAM dañada. Esta es la peor de todas las posibilidades, porque es aleatoria. Un día todo puede funcionar perfecto (porque la Base de Datos no se alojó en la parte de la RAM que está dañada) y otro día tienes problemas a cada rato (porque la Base de Datos se alojó justo en la parte de la RAM que está dañada) para que al siguiente día todo parezca estar normal nuevamente. Además, cuando el problema está en el disco duro es toda una página la que se torna inaccesible pero en el caso de la RAM puede ser solamente un bit que cambió de 0 a 1 ó viceversa. Eso hace que pueda pasar muchísimo tiempo hasta que detectes que algo está mal. ¿Qué implica esto? que en general solamente descubres el problema cuando el daño ya es demasiado grande, cuando ya se volvió crítico.
  5. Insuficiente espacio en el disco duro para la Base de Datos. Esto ya es total responsabilidad del Administrador de la Base de Datos, no puede jamás permitir que tal cosa ocurra. El problema aparece cuando el Servidor quiere agregarle más páginas a la Base de Datos pero no hay suficiente espacio libre en el disco duro o en la partición. La situación más peligrosa sucede cuando la falta de espacio en el disco duro es combinada con un caché muy grande y con FORCED WRITES en OFF porque el sistema operativo trata de guardar muchos datos en el disco duro y falla porque no le alcanza el espacio libre.
  6. Insuficiente espacio en el disco duro para los archivos temporales. Nuevamente, esto es total responsabilidad del Administrador de la Base de Datos. Firebird utiliza archivos temporales para ordenar los resultados de las consultas, esos archivos temporales solamente existen mientras se está ordenando y luego desaparecen pero si el ordenamiento envuelve a millones de filas, pueden requerir de mucho espacio en el disco duro.
  7. Insuficiente espacio en el disco duro para el archivo FIREBIRD.LOG. En este archivo se guardan los mensajes relacionados con el funcionamiento de Firebird, puede tener miles y miles de filas y si la Base de Datos tiene algún problema esas filas con mensajes se multiplican.

Problemas de software

  1. Creando y borrando tablas mientras la Base de Datos está siendo usada. Esta es la forma más fácil de corromper una Base de Datos porque el Firebird puede confundirse y escribir en las páginas del sistema (usadas para crear y borrar tablas) lo que debería escribir en las páginas de datos. O viceversa.

Problemas de mantenimiento

  1. Se borró la Base de Datos. Si nadie la está usando puede ser borrada, al igual que cualquier otro archivo de la computadora. A veces ocurre lo siguiente: se hace un backup, y se borra la Base de Datos original, confiando en el backup. Pero el backup por alguna razón está corrupto y entonces no sirve y tampoco se puede usar la Base de Datos original porque ya fue borrada.

Detectando problemas

La forma más rápida de detectar problemas es revisando el archivo FIREBIRD.LOG, si allí encontramos cualquier cosa inusual (por ejemplo, errores 10054) entonces hay algo mal en la Base de Datos y debemos solucionarlo lo antes posible.

¿Qué significa esto?

Que todos los días deberíamos echarle un vistazo al archivo FIREBIRD.LOG porque cuanto más rápido detectemos los problemas menos daños causarán.

También podemos utilizar programas especializados, como el IBSurgeon FirstAid

Solucionando problemas

Si encuentras que una Base de Datos está dañada, esto es lo que debes hacer:

  1. Detener el Servidor del Firebird. Porque más accesos y operaciones en la Base de Datos dañada solamente pueden provocar más daños, nunca menos daños
  2. Hacer un backup de la Base de Datos. Haz este backup con programas como 7Zip, WinZip, WinRar, etc.
  3. Utilizar el backup para intentar la recuperación. Siempre debes mantener el archivo original a salvo, trabaja con el backup
  4. Escribe los siguientes comandos para intentar repararla. Estos son los comandos estándar que se usan para reparar bases de datos dañadas.

Para validar la Base de Datos (recuerda que debes usar el archivo de backup, no el archivo original):

gfix –v –full –user SYSDBA -password MiPassword MiBaseDatosCorrupta.FDB

Si el comando de arriba detectó algún problema entonces debemos eliminar esos problemas:

gfix –mend –user SYSDBA –password MiPassword MiBaseDatosCorrupta.FDB

Repetir los dos comandos anteriores hasta que ya no se detecten problemas. Cuando está todo ok hay que hacerle un backup, porque al hacer un backup pueden detectarse otros problemas:

gbak –b –v -ig –user SYSDBA –password MiPassword MiBaseDatosCorrupta.FDB MiBackup.FBK

Si apareció algún error entonces debemos realizar otro backup, pero sin la recolección de basura:

gbak –b –v -ig –g -user SYSDBA –password MiPassword MiBaseDatosCorrupta.FDB MiBackup.FBK

A veces hacer que la Base de Datos sea de solo lectura (o sea: read only) puede ayudar a recuperarla.

gfix –mode read_only  –user SYSDBA -password MiPassword MiBaseDatosCorrupta.FDB

Si el backup finalizó exitosamente, entonces se lo restaura desde la copia:

gbak –c –user SYSDBA –password MiPassword MiBaseDatosCorrupta.FDB MiBaseDatosRestaurada.FDB

Conclusión:

Las bases de datos de Firebird son archivos de computadora y como cualquier otro archivo pueden dañarse. Los causantes pueden ser problemas de hardware, problemas de software o un mantenimiento inadecuado. Sea cual sea la razón, si detectamos que una Base de Datos está dañada debemos intentar repararla lo antes posible porque si se la continúa usando eso solamente ocasionará más daños.

No siempre se puede reparar una Base de Datos. Por lo tanto es importantísimo que al menos una vez por día se haga un backup de la misma para que la pérdida no sea muy grande si se concluye que es imposible repararla.

Artículo relacionado:

El índice del blog Firebird21

Forced writes

1 comentario

En cada una de nuestras bases de datos podemos determinar si los cambios que se realizan en ella se escribirán inmediatamente en el disco duro (FORCED WRITES = ON) o si se escribirán después de un tiempo (FORCED WRITES = OFF)

Si Forced Writes está en ON entonces tenemos dos ventajas:

  1. Los cambios se guardan en forma permanente. Un corte de la energía eléctrica no afectará a los datos ya guardados
  2. Los cambios se guardan siempre en el orden correcto. Por ejemplo, primero se guarda el registro y luego se guarda la entrada del índice que corresponde a ese registro

Si Forced Writes está en OFF tenemos una ventaja:

  1. Los datos se guardan mucho más rápidamente

Entonces ¿cuál es más conveniente?

En general, tener a Forced Writes en ON es lo mejor, esto es aún más notorio en Windows que en Linux. Porque cuando está en ON nos aseguramos que nunca haya pérdida de datos y que la Base de Datos siempre tenga consistencia. Si está en OFF, un corte de la energía eléctrica casi con seguridad hará que la Base de Datos se corrompa. Esa corrupción podría solucionarse, hay programas especializados en esa tarea, pero de todas maneras provocará molestias, inconvenientes y pérdida de tiempo y de dinero.

Podríamos tener Forced Writes en OFF solamente en casos especiales y muy puntuales, por ejemplo para insertar millones de filas desde una tabla externa. Una vez que esa inserción masiva ha finalizado volvemos a colocar Forced Writes en ON.

¿Cómo podemos saber si nuestra Base de Datos tiene Forced Writes en ON o en OFF?

Ejecutando el programa GSTAT.EXE que se encuentra en la carpeta \BIN de donde instalaste el Servidor del Firebird. A ese programa le pones como parámetros el nombre completo o el alias de la Base de Datos que deseas verificar y en la entrada Attributes te mostrará el estado actual de Forced Writes.

FORCED1

Captura 1. Si haces clic en la imagen la verás más grande

Después de escribir GSTAT y el alias de una Base de Datos se puede ver el estado de Forced Writes, que en este caso está en ON. O sea, que es lo correcto durante el uso normal.

¿Cómo se puede cambiar el estado de Forced Writes?

Mediante el programa GFIX.EXE, el cual tiene una opción llamada -write que puede ser sync (para que Forced Writes esté en ON) o async (para que Forced Writes esté en OFF)

FORCED2

 

Captura 2. Si haces clic en la imagen la verás más grande

Como puedes ver, al usar la opción -writes async del programa GFIX.EXE (flecha 1) el estado de Forced Writes se cambió a OFF como nos muestra el programa GSTAT.EXE (flecha 2) porque a continuación de Attributes no hay algo escrito.

Conclusión:

En general, lo conveniente es que Forced Writes esté en ON porque eso nos asegura que todos los datos se guarden y que se guarden en el orden correcto. Un corte de la energía eléctrica no ocasionará pérdidas de datos. Poner a Forced Writes en OFF puede ser muy útil cuando debemos realizar una entrada masiva de datos, pero no debemos olvidarnos de volver a ponerlo en ON apenas esa entrada masiva de datos finalice.

Artículo relacionado:

El índice del blog Firebird21

 

 

 

Entendiendo sweep y garbage collection

7 comentarios

Como habíamos visto en este artículo:

https://firebird21.wordpress.com/2013/06/14/la-arquitectura-mga/

cuando se actualiza (UPDATE) o se borra (DELETE) un registro el Firebird guarda en la Base de Datos la versión anterior de ese registro. ¿Para qué hace eso? Para poder revertir al registro original cuando se hace un ROLLBACK.

Un ROLLBACK se hace si ocurrió un error o si el usuario cambió de idea y no quiere guardar lo último que hizo, o si se cerró anormalmente la conexión.

Por lo tanto, cada comando UPDATE y cada comando DELETE le agrega un registro a la tabla respectiva (en el caso del DELETE el nuevo registro solamente tiene un marca que le indica al Firebird que ese registro está “borrado”).

Veamos un ejemplo de UPDATE:

El precio de “Televisor Toshiba de 20 pulgadas” es de 120 dólares. Como se está vendiendo poco ya que la mayoría de la gente ahora prefiere televisores de más pulgadas se decidió disminuir su precio a 100 dólares, tratando de conseguir que aumenten las ventas al disminuir el precio.

Entonces, en nuestra tabla de PRODUCTOS, luego del correspondiente UPDATE, tendríamos:

SWEEP1

Captura 1. Si haces clic en la imagen la verás más grande

Ahora hay dos posibilidades:

  1. Que la transacción termine con un COMMIT exitoso
  2. Que la transacción termine con un ROLLBACK

Si la transacción terminó con un COMMIT exitoso entonces el registro antiguo, el que tiene el TID 143 ya no sirve, es inútil. Pero el Firebird no lo elimina de la Base de Datos, lo deja ahí. Y eso implica que está ocupando espacio inútilmente.

Si la transacción terminó con un ROLLBACK entonces el registro nuevo, el que tiene el TID 279 ya no sirve, es inútil. Pero el Firebird no lo elimina de la Base de Datos, lo deja ahí. Y eso implica que está ocupando espacio inútilmente.

De lo anterior se deduce que cada vez que escribes el comando UPDATE dejas un registro inservible dentro de la Base de Datos. O el original queda inservible o el actualizado queda inservible.

Hay por lo tanto dos tipos de registros inservibles:

  • Los dejados por los COMMIT
  • Los dejados por los ROLLBACK

¿Hay diferencia si el registro inservible fue dejado por un COMMIT o por un ROLLBACK?

Sí, la diferencia es que los registros inservibles dejados por los COMMIT pueden ser eliminados automáticamente durante la recolección de la basura (ver más abajo), en cambio los dejados inservibles por los ROLLBACK nunca son eliminados automáticamente.

¿Qué es la “basura”?

Esos registros inservibles, inútiles, que fueron dejados por los UPDATE o por los DELETE siguen ocupando espacio dentro de la Base de Datos, pero como ya son inservibles y totalmente inútiles se les llama “basura”.

¿Cuál es el problema con la basura?

Que ocupa espacio inútilmente dentro de la Base de Datos y por lo tanto ésta es más grande de lo que debería ser y además se vuelve cada vez más lenta.

¿Qué significa “garbage collection”?

En castellano: recolección de la basura. Cuando se recolecta la basura todos esos registros inservibles dejados por los COMMIT son eliminados permanentemente y definitivamente de la Base de Datos. Como consecuencia de ello, la Base de Datos queda con espacio reutilizable y además las operaciones dentro de ella (INSERT, UPDATE, DELETE, FETCH, SELECT) se realizan más rápidamente.

¿Cuándo se realiza la “garbage collection”?

Cada vez que un registro es “tocado” por un SELECT toda la basura relacionada con ese registro como consecuencia de los COMMIT es eliminada. En otras palabras, si al escribir un SELECT un registro está en el resultado obtenido entonces toda la basura relacionada con ese registro, producida por los  COMMIT, es eliminada.

Fíjate que solamente el SELECT elimina a la basura, los demás comandos: INSERT, UPDATE, DELETE, no la eliminan, la dejan así mismo como estaba.

¿Cuál es la forma más rápida de eliminar toda la basura de una tabla?

Escribir el comando:

SELECT
   COUNT(*)
FROM
   MiTabla

Lo que hace ese comando es contar la cantidad de registros que tiene la tabla pero para hacerlo debe recorrer la tabla desde el primer registro hasta el último registro porque el Firebird no guarda en alguna parte la cantidad de registros de la tabla. Por lo tanto, todos los registros de esa tabla están involucrados en el SELECT y por consiguiente en todos esos registros es recolectada la basura. Si la tabla tiene 12.000 registros entonces SELECT COUNT(*) recorre los 12.000 registros y el “garbage collection” elimina toda la basura que haya encontrado en cualquiera de esos 12.000 registros.

Recuerda que esta forma de eliminar a la basura solamente elimina a la basura que dejaron los COMMIT, la basura dejada por los ROLLBACK no se puede eliminar así.

¿Cuál es el problema con recolectar la basura usando SELECT?

Que para recolectar la basura de todas las tablas debes hacer SELECT COUNT(*) en todas las tablas o esperar que algún SELECT involucre a los registros que tienen basura. A veces, puede ocurrir que se hizo el UPDATE de un registro pero nunca se hizo un SELECT que involucre a ese registro y por lo tanto la basura que dejó el UPDATE permanece dentro de la Base de Datos.

Además, no te olvides que cuando se ejecuta un SELECT solamente se recolecta la basura que dejaron los COMMIT, la basura dejada por los ROLLBACK continúa allí.

¿Qué es el sweep?

El sweep (en castellano: barrido, de barrer con una escoba) es un proceso que recorre toda la Base de Datos y elimina toda la basura que se encuentra en ella, tanto la proveniente de los COMMIT como la proveniente de los ROLLBACK. Cuando el sweep finaliza la Base de Datos está bien limpia, sin basura.

¿Cuándo se realiza el sweep?

El sweep se puede realizar automáticamente o manualmente. Automáticamente es cuando lo inicia el propio Firebird y manualmente es cuando lo inicia un programa (por ejemplo: GFIX y GBAK pueden iniciar el sweep).

Sweep automático

Cada Base de Datos tiene una entrada denominada “sweep interval” o sea intervalo del sweep. Es un número de tipo INTEGER  y por lo tanto su valor puede estar entre 0 y 2.147.483.647. Por defecto su valor es 20.000.

Cuando la diferencia entre la OST y la OAT es mayor que el intervalo del sweep, se inicia el sweep. Por ejemplo:

OST = 45.201

OAT = 25.200

Sweep interval = 20.000

Diferencia = OST – OAT = 45.201 – 25.200 = 20.001

Como la diferencia es mayor que el intervalo del sweep, se inicia el sweep automático.

Si no se quiere realizar un sweep automático entonces el intervalo del sweep debe ser 0 (cero)

¿Cuál es el problema con el sweep?

Que este proceso de recorrer toda la Base de Datos y de eliminar toda la basura que hay en ella es lento, en algunos casos extremadamente lento y los usuarios se quejan de que todas las operaciones (INSERT, UPDATE, DELETE, FETCH, SELECT) se realizan muy despaciosamente. Y por supuesto podría ocurrir que el sweep automático se inicie cuando los usuarios están más apurados, más impacientes y por culpa del sweep todas sus transacciones son más lentas que una tortuga con tres patas. Es por lo tanto normal que el DBA (Administrador de la Base de Datos) ponga el intervalo del sweep en 0 (cero) y de esa manera realizará el sweep manualmente, en momentos en que nadie está usando la Base de Datos (o cuando muy pocos usuarios la están usando).

Pero …. a veces el DBA se olvida de que dejó el intervalo del sweep en cero y la Base de Datos se va volviendo cada vez más grande y más lenta por toda la basura que tiene acumulada.

En otras palabras, se necesita un DBA con cerebro, algo que no siempre se consigue.

Aprovechar el backup para hacer el sweep

Cuando haces un backup usando el programa GBAK tienes la opción de que también se haga el sweep de la Base de Datos. Esa es la opción por defecto y la recomendable. Así, cuando finaliza el programa GBAK puedes estar seguro de que el archivo de backup generado no tiene basura. Recuerda: la Base de Datos original continúa con toda la basura que tenía, el backup generado es el que no tiene basura.

Usando el programa GFIX para hacer el sweep

Una de las opciones de este programa nos permite pedirle que haga el sweep:

GFIX -sweep -user SYSDBA -password masterkey MiBaseDatos

Un pequeño “defecto” que tiene el programa GFIX es que no te avisa que finalizó exitosamente y eso confunde a los principiantes. O sea, si termina sin ningún mensaje significa que todo estuvo ok, si ocurrió algún problema entonces termina con un mensaje de error.

Conclusión:

El uso normal de la Base de Datos va dejando basura dentro de ella. Esa basura debe ser eliminada en algún momento porque de no eliminarse solamente causará que la Base de Datos tenga un tamaño mayor que el necesario y además que todas las transacciones sean más lentas de lo que deberían. La eliminación de la basura puede hacerse en forma automática (cuando el intervalo del sweep es mayor que cero y la diferencia entre la OST y la OAT es mayor que ese intervalo) o en forma manual (cuando el intervalo del sweep es cero y en ese caso hay que ejecutar el programa GFIX). También se elimina la basura cuando se hace un backup usando el programa GBAK y no se especifica la opción -garbage collection.

Artículos relacionados:

La arquitectura MGA

Entendiendo a las transacciones

Entendiendo a los identificadores de las transacciones

El índice del blog Firebird21

Un archivo de lotes para mantenimiento de la Base de Datos

2 comentarios

Por el uso (y abuso) diario las bases de datos normalmente van perdiendo performance, volviéndose más lentas todas las operaciones que se realizan en ellas. Una forma de mantener a la Base de Datos saludable es a través del siguiente archivo .BAT

CLS

@ECHO OFF

ECHO IMPORTANTE: El nombre de la Base de Datos NO DEBE TENER LA EXTENSION para que este archivo .BAT funcione bien.

@ECHO ON

SET ISC_USER=SYSDBA

SET ISC_PASSWORD=masterkey

SET CarpetaFirebird=C:\Program Files\Firebird\Firebird_2_5\bin\

SET CarpetaBaseDatos=E:\SQL\DATABASES\

SET CarpetaBackup=E:\SQL\BACKUPS\

SET NombreBaseDatos=INTEGRAL

C:

CD "%CarpetaFirebird%"

GFIX "%CarpetaBaseDatos%%NombreBaseDatos%.FDB" -shut single -force 0

GFIX "%CarpetaBaseDatos%%NombreBaseDatos%.FDB" -validate -full -ignore

GFIX "%CarpetaBaseDatos%%NombreBaseDatos%.FDB" -mend -ignore

GFIX "%CarpetaBaseDatos%%NombreBaseDatos%.FDB" -online

IF EXIST "%CarpetaBackup%%NombreBaseDatos%_GBAK.LOG" DEL "%CarpetaBackup%%NombreBaseDatos%_GBAK.LOG"

GBAK "%CarpetaBaseDatos%%NombreBaseDatos%.FDB" "%CarpetaBackup%%NombreBaseDatos%.FBK" -e -g -ig -l -nt -b -v -y "%CarpetaBackup%%NombreBaseDatos%_GBAK.LOG"

IF EXIST "%CarpetaBackup%%NombreBaseDatos%_GBAK2.LOG" DEL "%CarpetaBackup%%NombreBaseDatos%_GBAK2.LOG"

IF EXIST "%CarpetaBaseDatos%%NombreBaseDatos%_NEW.FDB" DEL "%CarpetaBaseDatos%%NombreBaseDatos%_NEW.FDB"

GBAK "%CarpetaBackup%%NombreBaseDatos%.FBK" "%CarpetaBaseDatos%%NombreBaseDatos%_NEW.FDB" -o -r -v -REP -y "%CarpetaBackup%%NombreBaseDatos%_GBAK2.LOG"

GFIX "%CarpetaBaseDatos%%NombreBaseDatos%.FDB" -shut -force 0

E:

IF EXIST "%NombreBaseDatos%_ANTERIOR.FDB" DEL "%NombreBaseDatos%_ANTERIOR.FDB"

RENAME "%NombreBaseDatos%.FDB" "%NombreBaseDatos%_ANTERIOR.FDB"

IF EXIST "%NombreBaseDatos%.FDB" DEL "%NombreBaseDatos%.FDB"

RENAME "%NombreBaseDatos%_NEW.FDB" "%NombreBaseDatos%.FDB"

C:

GFIX "%CarpetaBaseDatos%%NombreBaseDatos%.FDB" -online

@PAUSE

Como seguramente ya sabes, los archivos .BAT son los archivos de lotes (batch, en inglés) del antiguo Sistema Operativo D.O.S. y que el Windows ha heredado. En estos archivos .BAT puedes escribir varios comandos, los cuales se ejecutarán en el mismo orden establecido.

Este archivo .BAT realiza las siguientes tareas:

  1. Borra la pantalla
  2. Muestra un mensaje al usuario
  3. Establece las variables de entorno. Son todas las que empiezan con la palabra SET. Fíjate que para no estar escribiendo el nombre del usuario y su password en cada comando GFIX y GBAK que hay más abajo, se asignaron sus valores a dos variables. No es obligatorio hacer así, pero se escribe menos.
  4. El nombre de la Base de Datos debe escribirse sin la extensión (o sea, sin el .FDB). Por eso, aunque el nombre real de la Base de Datos usada en este ejemplo es INTEGRAL.FDB en la variable se escribió solamente INTEGRAL
  5. El comando GFIX -shut single -force 0 permite que solamente el usuario SYSDBA pueda estar conectado a la Base de Datos, nadie más. El -force 0 cerrará inmediatamente todas las conexiones. ¿Qué implica eso? Que este archivo .BAT solamente debe ejecutarse cuando nadie está usando la Base de Datos. De lo contrario, los usuarios que estén conectados perderán la conexión y posiblemente el trabajo que estaban haciendo.
  6. Los siguientes dos comandos GFIX sirven para validar y corregir errores en la Base de Datos
  7. El cuarto comando GFIX vuelve a permitir que otros usuarios se conecten a la Base de Datos
  8. Antes de realizar el backup se verifica si existe el archivo LOG (en los archivos de LOG se guarda información con respecto a la ejecución de un comando). Si existe, se lo borra
  9. Se realiza el backup y las tareas que realizó se guardan en un archivo de LOG, que es un archivo de texto que puede ser revisado en cualquier momento
  10. Idénticamente, antes de restaurar el backup se verifica si existen su archivo de LOG y un archivo con el mismo nombre del que será restaurado. Si existen, se los borra
  11. Se realiza la restauración del backup
  12. Nuevamente se desconecta a todos los usuarios. Esto es necesario para que el nombre de la Base de Datos pueda ser cambiado, si alguien la estuviera usando, su nombre no podría cambiarse
  13. Se cambian los nombres de dos archivos
  14. Y finalmente, se vuelve a permitir que todos los usuarios puedan conectarse a la Base de Datos

Si en el punto 14. obtienes un error, no te preocupes, significa que todos ya podían conectarse y le volviste a pedir que todos se pudieran conectar.

Algunos puntos importantes a recordar:

  1. Este archivo .BAT debe estar en la computadora del Servidor, no funcionará remotamente
  2. Debes crear un archivo de texto con la extensión .BAT para que funcione. Para mayor facilidad, puedes colocar un acceso directo en el escritorio.
  3. Si ejecutas este archivo .BAT periódicamente, te asegurarás que tu Base de Datos siempre se encuentre en buen estado y que todas las operaciones en ella sean lo más rápidas posibles
  4. Debes ejecutarlo solamente cuando estás seguro que nadie está conectado a la Base de Datos, porque este archivo .BAT desconectará automáticamente a todos quienes estén conectados y eso les podría ocasionar pérdida de sus trabajos
  5. La carpeta BACKUPS debe existir, si no existe obtendrás un mensaje de error y este .BAT no cumplirá su misión
  6. Debes establecer los valores de las variables de entorno (las que empiezan con SET) acordemente a tu situación particular. Las que ves aquí son solamente un ejemplo
  7. Antes de renombrar los archivos (casi al final del .BAT) se cambia a la unidad E:, porque en esa unidad tengo yo mis bases de datos. En tu caso, debes colocar allí la letra que corresponda (C:, D:, E:, F:, la que sea)

Artículo relacionado:

El índice del blog Firebird21

Backup y restore a una versión más nueva del Firebird

3 comentarios

A veces puedes necesitar que una Base de Datos creada con una versión anterior del Firebird sea usada con una versión más reciente.

Si no necesitas las características adicionales que introdujo la versión más reciente entonces te puedes conectar a esa Base de Datos sin problema.

Sin embargo, a veces necesitas de las características adicionales y en ese caso debes efectuar un ciclo backup/restore

Ejemplo:

MiBaseDatos.fdb fue creada con la versión 1.5 y ahora queremos usarla con la versión 2.5

Caso 1. No necesitamos de las nuevas características introducidas por la versión 2.5

Nos conectamos a la Base de Datos desde la versión 2.5 y podremos usarla sin problemas

Caso 2. Necesitamos algunas de las características introducidas por la versión 2.5 (que es el caso más común)

Aquí, debemos hacer un ciclo backup/restore para agregarle a la Base de Datos toda la funcionalidad de la versión 2.5

Primero, usando el Servidor del Firebird 1.5, en la ventana “Símbolo del sistema” del Windows escribimos:

SET ISC_USER=SYSDBA

SET ISC_PASSWORD=masterkey

GFIX -validate -full MiBaseDatos.fdb

GFIX -mend -full -ignore MiBaseDatos.fdb

GFIX -sweep MiBaseDatos.fdb

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

Los dos SET (ISC_USER e ISC_PASSWORD) sirven para decirle al Windows que queremos usar esas variables y en consecuencia en los comandos GFIX y GBAK no necesitaremos estar introduciendo el usuario ni la contraseña. Es opcional, si prefieres escribir el usuario y la contraseña en cada comando GFIX y GBAK, entonces puedes obviar los dos SET

Si no usas un alias entonces debes escribir la ruta completa a tu Base de Datos, por ejemplo: D:\DATABASES\MiBaseDatos.fdb

Si usas un alias, entonces puedes escribir solamente el alias, por ejemplo: CONTA

El nombre del archivo de backup debe ser escrito con la ruta completa, por ejemplo: D:\BACKUPS\MiBackup.fbk

La opción -validate busca errores en la Base de Datos, los muestra y los repara

La opción -full se usa con la opción -validate para examinar todas las páginas y todos los registros y para liberar fragmentos de registro que no están asignados

La opción -mend marca a los registros corruptos para que al hacer el backup no sean copiados. De esta manera solamente los registros que están en buen estado son enviados al archivo de backup

La opción -ignore ignora los errores de checksum

La opción -sweep realiza el sweep inmediatamente

La opción -backup es opcional, sirve para aclarar (a nosotros, los humanos) que se quiere hacer un backup y no un restore

La opción -verbose muestra lo que está haciendo el programa GBAK

La opción -garbage no realiza la recolección de basura durante el backup y por lo tanto el backup terminará más rápido. Se la usa cuando tienes planeado hacer el restore o el sweep después del backup

 Ahora que nos aseguramos que nuestra Base de Datos está en buen estado y que hemos creado el archivo de backup pasamos al siguiente paso: restaurar el archivo de backup en una versión más reciente del Firebird

Para eso, usando la versión más reciente, escribimos:

GBAK -create -verbose -page_size 16384 MiBackp.fbk MiBaseDatos.fdb

La opción -create creará el archivo MiBaseDatos.fdb y éste no debe existir.

La opción -verbose muestra lo que está haciendo el programa GBAK

La opción -page_size cambia el tamaño de la página. Debes tener en cuenta que si aumentas el tamaño de la página (por ejemplo: la Base de Datos original tenía un tamaño de página de 4096 y se la restaura con un tamaño de página de 16384) aumentará también el tamaño de tu Base de Datos restaurada.

Al finalizar la restauración ya tendremos una nueva Base de Datos, completamente funcional y con todas las características de la versión más reciente del Firebird.

Artículo relacionado:

El índice del blog Firebird21