Firebird 3: usando bases de datos anteriores

6 comentarios

Ok, ya hemos instalado a Firebird 3, ahora queremos empezar a utilizarlo. ¿Cómo lo hacemos?

Lo más probable es que tengamos bases de datos creadas con versiones anteriores de Firebird. Entonces hay que convertir esas bases de datos al formato que usa Firebird 3.

El Firebird utiliza un número interno llamado ODS (On Disk Structure) para saber con cual versión de Firebird fue creada una Base de Datos. Cada versión del Firebird tiene un número único de ODS. Esos números son:

FIREBIRD3_15

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

Si no coincide la ODS de una Base de Datos con la versión del Servidor del Firebird entonces no podremos conectarnos a esa Base de Datos.

¿Cómo cambiamos la ODS de una Base de Datos?

Mediante un ciclo backup/restore. Hacemos el backup con la versión actual y el restore con la nueva versión.

IMPORTANTE: Esto solamente funciona en una dirección: de una ODS menor a una ODS mayor.

Ejemplo: Usar una Base de Datos creada con Firebird 2.5 en Firebird 3

firebird3_16

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

Como podemos ver en la Captura 2. la conexión falló porque la ODS de la Base de Datos es 11.2 y la ODS que reconoce el Servidor del Firebird es 12.0

Entonces lo que debemos hacer es convertir la ODS de esa Base de Datos a 12.0, para que pueda ser reconocida. Para ello necesitaremos realizar un ciclo backup/restore.

FIREBIRD3_17

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

En la Captura 3. hicimos el backup con la versión 2.5 del Firebird ¿cómo sabemos eso? Por dos pistas: a) la carpeta donde se encuentra el programa GBAK.EXE y b) el puerto que usamos para conectarnos a la Base de Datos. En nuestros ejemplos usamos el puerto 3050 para Firebird 2.5 y el puerto 3053 para Firebird 3.

Ahora que ya tenemos el backup realizado el siguiente paso es restaurarlo. Para ello, nos ubicamos en la carpeta donde instalamos al Firebird 3 y escribimos:

FIREBIRD3_18

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

Cuando la restauración finalice tendremos una nueva Base de Datos, de nombre PRUEBA1-3.FDB y cuya ODS será 12.0 y por lo tanto nos podremos conectar a ella usando Firebird 3.

FIREBIRD3_19

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

Como podemos ver en la Captura 5. no fue necesario especificar el puerto 3053 ¿por qué no? porque para la conexión usamos el programa ISQL.EXE que se instala junto con el Firebird 3. Sin embargo, en otros casos sí necesitaremos especificar dicho puerto:

FIREBIRD3_20

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

En el string de conexión que vemos en la Captura 6. indicamos la dirección IP de la computadora donde se encuentra la Base de Datos y también el puerto de esa computadora que usa el Servidor del Firebird 3.

Como siempre, hay que indicar además el path completo a la Base de Datos (ese path es desde el punto de vista del Servidor), el nombre de un usuario, y la contraseña de ese usuario.

Conclusión:

Para que en Firebird 3 podamos usar una Base de Datos creada con una versión anterior del Firebird debemos hacer un ciclo backup/restore. El backup lo hacemos con la versión anterior del Firebird y el restore lo hacemos con Firebird 3.

Para conectarnos a la Base de Datos restaurada a veces será necesario especificar el puerto que utiliza el Firebird 3.

Artículos relacionados:

Instalando Firebird 3 (1)

Instalando Firebird 3 (2)

El índice del blog Firebird21

El foro del blog Firebird21

Anuncios

Haciendo backups con GBAK (1)

2 comentarios

El Firebird nos permite realizar copias de seguridad (generalmente llamadas backups) de nuestras bases de datos de varias formas diferentes, tal como ya habíamos visto en:

https://firebird21.wordpress.com/2013/07/03/los-metodos-para-hacer-backup/

Cada uno de esos métodos tiene sus ventajas y sus desventajas, ninguno es perfecto (evidentemente, porque si uno fuera perfecto ¿para qué tendríamos los demás?).

En el presente artículo empezaremos a ver como hacer backups usando para ello el programa GBAK. Como el tema es muy largo, lo trataremos en varios artículos.

¿Qué es el ciclo backup/restore?

Todos sabemos que debemos realizar frecuentemente copias de seguridad de nuestra Base de Datos porque si ocurre un accidente (como el disco duro dañado), la única forma rápida y confiable de recuperar su contenido en todo o en gran parte es a través de una copia de seguridad actualizada. Este proceso tiene dos partes:

  1. Copiar todo el contenido de la Base de Datos en un archivo. A este paso se le llama realizar el backup.
  2. Usar el archivo de backup para obtener una Base de Datos operativa, a ese paso se le llama restaurar la Base de Datos.

Por lo tanto, el ciclo backup/restore significa: crear un archivo de backup y luego restaurarlo.

Hay que enfatizar que el proceso no está completo si solamente se realiza el backup. Hay que realizar ambos, sí o sí: el backup y el restore. O sea: la copia de seguridad y la restauración de esa copia.

¿Qué programa usaremos para realizar el ciclo backup/restore?

El programa se llama GBAK.EXE, y con él podremos:

  • Realizar el backup
  • Restaurar la Base de Datos

¿Qué tareas realiza GBAK.EXE?

Cuando hace el backup:

  • Lee todo el contenido de una Base de Datos y copia ese contenido en otro archivo. Pero no lo copia completo. Los índices por ejemplo no son copiados. Gracias a eso el tamaño de la copia es menor de lo que sería si los hubiera copiado.
  • No copia la basura en el backup (la Base de Datos original continúa con toda la basura que tenía)

Cuando restaura la Base de Datos:

  • Pone el TID de cada fila de cada tabla en 1. (El TID es un número que identifica a la transacción que creó la fila). Por lo tanto es como si todas las millones y millones de filas de las tablas hubieran sido insertadas por una sola transacción.
  • Verifica que cada fila tenga datos válidos
  • Crea los índices
  • Calcula las estadísticas de los índices

¿Dónde se encuentra el programa GBAK.EXE?

En la sub-carpeta \BIN de la carpeta donde está instalado el Firebird, por ejemplo en:

C:\Archivos de Programa\Firebird\Firebird_2_5\Bin\

¿Es necesario que el programa GBAK.EXE se encuentre ahí para hacer un backup?

No. Puedes tener una copia del programa GBAK.EXE en cualquier carpeta de tu disco duro. Por ejemplo si tienes un programa de contabilidad en la carpeta:

D:\MisSistemas\Contabilidad\

en esa misma carpeta podrías tener una copia de GBAK.EXE y entonces tu programa ejecutable (por ejemplo: CONTA.EXE) podría buscarlo a GBAK.EXE allí mismo. O sea que si lo deseas podrías tener a GBAK.EXE en la misma carpeta donde tienes a CONTA.EXE

¿Qué versión de GBAK.EXE debo utilizar?

La misma versión que el Servidor del Firebird. Si por ejemplo tu versión del Firebird es la 2.5.4, entonces deberías siempre usar el programa GBAK.EXE que viene incluido en esa versión.

¿Y si no coincide la versión del Servidor del Firebird con la versión de GBAK.EXE?

Hmmmmmmm, eso no es recomendable. Podría funcionar bien pero … también podrían ocurrir errores, no hay garantías.

Una buena posibilidad para que no ocurran errores es tener al programa GBAK.EXE en una carpeta compartida. Y asegurándote que corresponde a la versión del Firebird que se está usando. Para no confundirte, puedes renombrar a GBAK.EXE para que te indique su versión, algo como: GBAK_2_5_4.EXE para saber que es el correspondiente a la versión 2.5.4 del Firebird.

Ejemplo:

  • En la carpeta compartida D:\EJECUTABLES\ tienes una copia de GBAK.EXE
  • Esa copia de GBAK.EXE coincide con la versión del Firebird que utilizas
  • Como tu versión del Firebird es la 2.5.4 entonces lo renombras como GBAK_2_5_4.EXE
  • Tus programas ejecutables que se encuentran distribuidos en un montón de computadoras (en nuestro ejemplo: CONTA.EXE) cuando necesitan hacer un backup llaman al programa D:\EJECUTABLES\GBAK_2_5_4.EXE

¿Cuáles son las ventajas de usar GBAK.EXE para hacer los backups?

  • Se obtiene una copia completa de la Base de Datos
  • Los usuarios pueden continuar trabajando normalmente mientras se realiza el backup
  • Al restaurar el backup se reconstruyen los índices y sus estadísticas
  • Al restaurar el backup se puede cambiar el tamaño de la página
  • En la Base de Datos restaurada se ha recolectado la basura y se ha realizado el barrido (sweep)
  • Se puede ver que tarea está realizando el programa
  • En el disco duro la Base de Datos restaurada se encuentra (generalmente) menos fragmentada que la Base de Datos original, y por lo tanto todos los accesos son más rápidos

¿Cuáles son las desventajas de usar GBAK.EXE para hacer los backups?

  • El archivo generado no puede ser utilizado directamente, debe ser restaurado con la misma versión de GBAK o con una versión posterior, para poder ser utilizado
  • Si la Base de Datos es muy grande, tanto hacer el backup como la restauración demoran mucho tiempo
  • Si la Base de Datos es muy grande, el archivo de backup también lo será
  • Si la Base de Datos es muy grande, habrá un período de muchos minutos (desde que empezó la ejecución del programa GBAK.EXE hasta que terminó) en que no se contará con un backup actualizado. De todo lo que haya ocurrido dentro de la Base de Datos en ese período no se tendrá un backup.

¿Cuáles son las consecuencias de usar GBAK para hacer backups?

  • La Base de Datos restaurada (si no ocurrieron errores durante la restauración) se encuentra en perfecto estado de salud. Eso significa: índices perfectamente balanceados, estadísticas correctas, nada de basura.
  • En la Base de Datos restaurada todas las filas de todas las tablas que se encontraban en la Base de Datos original ahora tienen un TID (identificador de la transacción) igual a 1.
  • Los identificadores de las transacciones (OAT, OIT, OST, NT) ahora tienen valores muy pequeños. NT (next transaction) no es igual a 1 porque al restaurar se realizan algunas tareas dentro de la Base de Datos y esas tareas inician transacciones. Pero de todas maneras el valor de NT siempre es pequeño, típicamente menos que 100.

¿Por qué en la Base de Datos restaurada algunas consultas son más lentas que en la Base de Datos original?

Uno supondría que en la Base de Datos restaurada, como su salud es perfecta todos los SELECT serían más rápidos que en la Base de Datos original pero … no siempre sucede así.

¿Por qué?

Bien, uno de los métodos que utiliza el Firebird para que las consultas sean muy rápidas es guardar en el caché de la computadora donde se encuentra el Servidor las filas retornadas por los últimos SELECTs.

Si el Servidor se apaga, todo el contenido del caché desaparece (porque se encuentra en memoria RAM, la cual es volátil). Pero en las organizaciones que nunca apagan el Servidor el contenido del caché sirve para agilizar de gran manera a las consultas. Si las filas que solicita un usuario ya se encontraban en el caché entonces desde allí le son entregadas, y eso es muchísimo más rápido que leerlas desde el disco duro.

Sin embargo, al restaurar una Base de Datos el caché se vacía (porque los identificadores de las transacciones cambiaron, ahora ya son todos 1) y entonces hay que reiniciar el proceso de ir cargando el caché.

Como consecuencia, algunas consultas (no todas, solamente las que tenían filas en el caché) serán más lentas en la Base de Datos restaurada que en la Base de Datos original. Claro que esto será solamente durante un corto tiempo, luego será distinto.

¿GBAK siempre realiza el backup correctamente?

No. Y esto es algo súper importante para recordar. Al hacer el backup, GBAK no verifica si los datos que está copiando tienen errores o no. Eso solamente se puede descubrir en el momento de la restauración, nunca en el momento del backup.

Por lo tanto, el backup que realizó GBAK …. puede ser totalmente inservible.

¿Terrible?

Sí, así mismo, eso es. Terrible.

Por ejemplo, una columna definida como NOT NULL tiene valores NULL. Tal cosa no debería ocurrir pero a veces la Base de Datos se corrompe y sucede. GBAK copia esas filas sin ningún aviso, ninguna advertencia, ningún mensaje de error. Sin embargo, al querer restaurar ese backup allí sí se enojará … y finalizará la restauración. El archivo que estaba generando se muere ahí mismo, se vuelve completamente inservible.

Hay métodos para solventar ese problema (que veremos en otro artículo) pero lo importante a recordar es:

JAMÁS SE DEBE CONFIAR EN EL BACKUP. JAMÁS

¿Cómo se puede saber si un backup está correcto?

Ya vimos que al hacer el backup GBAK no nos avisa si la Base de Datos tiene errores. Solamente nos avisa cuando está restaurando, así que por lo tanto….

La única manera de verificar que un backup está ok es restaurándolo.

No hay otra forma.

¿Cuál es la mejor manera de hacer y verificar un backup?

Escribiendo un comando que apenas termine el backup lo restaure, de esa manera enseguida sabremos si nuestro backup es confiable o si por el contrario es inútil (y por lo tanto debemos corregir los errores que tiene y realizar otro backup).

Ese comando es el siguiente:

GBAK -b -user SYSDBA -password masterkey MiBaseDatos.FDB stdout | GBAK -r -user SYSDBA -password masterkey stdin Restaurada.FDB

¿Qué hace este comando?

En lugar de crear un archivo de backup en el disco duro (que es lo normal), lo crea en la salida estándar (stdout). Luego realiza la restauración, tomando como archivo de entrada del segundo GBAK el archivo generado por el primer GBAK.

¿Consecuencia?

Que así hacemos un backup y también una restauración. Y si al restaurar ocurre algún error entonces lo sabremos al instante y podremos corregirlo.

Conclusión:

En el Firebird hay varios métodos para hacer backups, usar el programa GBAK.EXE es uno de esos métodos. Como todo, tiene algunas ventajas y algunas desventajas. Nunca jamás hay que confiar en que el backup está correcto y sin errores porque a veces sí tiene errores. Esos errores solamente pueden descubrirse cuando se está restaurando el backup, es el único momento en que se puede saber si el backup está correcto o no. Por lo tanto, una muy buena política administrativa es apenas terminado el backup intentar la restauración. Si el backup no se puede restaurar es inservible e inútil.

Artículos relacionados:

Los métodos para hacer backup

Backup y restauración al mismo tiempo

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

Entendiendo los identificadores de las transacciones

Entendiendo sweep y garbage collection

La Next Transaction después de un ciclo backup/restore

El ciclo backup/restore usando GBAK

El índice del blog Firebird21

El foro del blog Firebird21

Trabajando con grandes bases de datos

4 comentarios

Los problemas con los cuales nos encontramos al trabajar con bases de datos grandes son distintos a los problemas que tienen las bases de datos pequeñas.

Como las empresas constantemente están almacenando más y más datos las tablas van creciendo de tamaño diariamente, quizás minuto a minuto. Llega un momento en que la Base de Datos ya puede considerarse “grande”.

¿Cuándo una Base de Datos es grande?

Como muchas otras cosas en Informática, ésta también depende del punto de vista. Para alguien podría ser grande y para otros pequeña, aunque en general se considera “grande” a las bases de datos que alcanzan o superan un tamaño de 10 Gigabytes. En este blog se considera que:

  • Pequeña. Es una Base de Datos con tamaño menor a 1 Gb
  • Mediana. Es una Base de Datos cuyo tamaño está entre 1 Gb y 10 Gb
  • Grande. Es una Base de Datos cuyo tamaño es mayor que 10 Gb

Normalmente, si no se almacena multimedia (archivos gráficos, de sonido, de vídeo, etc.) las bases de datos van creciendo a un ritmo bastante parejo y predecible, por ejemplo podríamos tener una que crece alrededor de 1 Megabyte por día. Desde luego que algunos días crece más y algunos días crece menos, pero siempre está por ahí cerca.

Problemas típicos con las bases de datos pequeñas

  • Consultas lentas
  • Stored procedures o triggers lentos

Soluciones típicas a esos problemas

  • Optimizar las instrucciones SQL.
  • Realizar un ciclo backup/restore con el programa GBAK

El optimizar las instrucciones SQL (principalmente las cuatro principales: INSERT, UPDATE, DELETE, SELECT) conduce a una notoria mejoría en la velocidad. Muy relacionado con esto se encuentra el correcto manejo de las transacciones. Ante alguna corrupción restaurar el backup realizado con GBAK suele ser suficiente.

Problemas típicos con las bases de datos grandes

  • No se sabe donde está el problema
  • No se sabe por qué sucede
  • Realizar un ciclo backup/restore puede ser una gran pérdida de tiempo, porque la restauración puede demorarse un día o más, y no asegura que se haya solucionado el problema

Tareas administrativas diarias en las bases de datos grandes

Si ocurre un problema, puede demorarse mucho la solución así que lo más inteligente es evitar que ocurra. Para ello:

  1. Debe realizarse un backup con GBAK todos los días
  2. Debe verificarse el rendimiento de todas las transacciones
  3. Debe verificarse que todas las instrucciones SQL estén optimizadas
  4. Debe verificarse cada índice y la estadística de cada índice
  5. Debe verificarse que la estructura de la Base de Datos sea la más conveniente
  6. Debe verificarse el archivo FIREBIRD.LOG varias veces por día

Aunque realizar un ciclo backup/restore no nos asegura que solucionaremos todos los problemas, tener una Base de Datos grande sin backups actualizados es un suicidio. En las transacciones lo más importante es que ninguna demore mucho en completarse (“mucho” es relativo, pero en general si tarda más de un minuto entonces está tardando una eternidad). Las instrucciones SQL no optimizadas hacen perder tiempo, algo que no se puede permitir en estas circunstancias. Y no debemos olvidar que una instrucción SQL que hoy está optimizada y funciona perfectamente podría dejar de estarlo dentro de unos meses cuando la Base de Datos haya aumentado mucho de tamaño. Por eso la verificación debe hacerse diariamente.

El archivo FIREBIRD.LOG es el mejor lugar para verificar que todo esté correcto, si hay algún problema casi siempre aparecerá en ese archivo.

¿Cómo realizar el ciclo backup/restore?

Es bastante frecuente, aunque erróneo, hacerlo de esta manera:

Base de Datos —> Backup con el mismo nombre anterior

Por ejemplo, la Base de Datos se llama CONTA.FDB y el archivo de backup siempre se llama CONTA.FBK, ¿cuál es el problema potencial? Que si la Base de Datos está corrupta entonces el nuevo backup no servirá y el anterior no podrá ser utilizado porque fue sobre-escrito.

Lo correcto, por lo tanto, es hacer el backup de esta manera:

Base de Datos —> Backup con un nombre distinto al anterior

Esto evidentemente implica que tendremos varios archivos de backup, pero es preferible que sobren y no que falten.

El archivo delta

Cuando se ejecuta el programa GBAK para realizar un backup, éste hace el backup de todo el contenido que tiene en ese momento la Base de Datos. Es como si le tomara una fotografía. Nada que se realice con posterioridad se guardará en el backup ni en la Base de Datos, sólo lo que existía en el momento de iniciarse GBAK. Pero ¿y qué pasa con los datos que los usuarios continúan insertando, actualizando o borrando? Que no se guardan en la Base de Datos original sino en un archivo temporario llamado delta. Cuando GBAK finaliza, entonces todo el contenido del archivo delta se copia dentro de la Base de Datos.

Cuando hacemos backup de bases de datos pequeñas no vale la pena preocuparse por ese archivo delta pero cuando es una Base de Datos grande sí, porque no podemos permitirnos que esté corrupto. Un motivo podría ser que no haya suficiente espacio en el disco duro para el archivo delta.

La restauración

Aquí, es obligatorio que al finalizar un backup se realice un restore (en otro disco duro y preferiblemente en otra computadora) para asegurarnos de que se encuentre en perfectas condiciones y pueda ser utilizado en caso de necesidad.

Nada hay peor que creer que se tiene un backup actualizado pero eso no es cierto porque el backup se encuentra inservible. No ocurre frecuentemente, pero a veces ocurre, y no se puede tomar ese riesgo.

Los índices

Los índices en Firebird se utilizan en las búsquedas y en los filtros (cláusula WHERE) y cuando deseamos que los resultados aparezcan en un cierto orden (cláusula ORDER BY)

Para saber si un índice es el adecuado, es necesario, y se encuentra en buena salud, debemos verificar sus estadísticas. En Firebird los índices pueden degradarse y no debemos permitir que tal cosa ocurra.

Acciones a tomar si se descubre un problema

Estas son recomendaciones que a veces podrían no aplicarse, dependen de cada caso, pero servirán de guía:

  1. Una transacción está demorando mucho. Detectar cual es la transacción, cual es el programa culpable, y desconectar al usuario
  2. Una consulta está demorando mucho. Verificar cual es la consulta, mirar su PLAN y si es necesario crear un nuevo índice

Programas que se pueden utilizar cuando se trabaja con grandes bases de datos

Aunque detectar los problemas y solucionarlos podría hacerse manualmente, eso requerirá que la persona encargada conozca mucho del tema y que tenga suficiente tiempo y ganas para dedicarle a esa tarea. Para estos casos se justifica adquirir software que ayude en la detección y corrección. Los recomendados son:

  • FBDataGuard. Se ejecuta en la misma computadora donde se encuentra la Base de Datos. Su principal tarea es prevenir que se corrompa. Monitorea el rendimiento, realiza el backup en la forma correcta, obtiene estadísticas, y si descubre algún problema entonces envía un e-mail describiéndolo
  • FBScanner. Verifica cada instrucción SQL que el Cliente le envía al Servidor, puede realizar un análisis detallado de cada consulta, PLAN, transacción y conexión, de esta manera sirve para detectar los “cuellos de botella”, las transacciones que se demoran mucho, los usuarios que se desconectan de mala manera, y monitorea lo que un usuario o una aplicación están realizando.
  • IBTM. Monitorea y analiza transacciones dinámicas. Obtiene los valores de OIT, OAT, OST, NT y visualiza como se van moviendo. Detecta transacciones que se demoran mucho, los momentos en que muchas transacciones se están ejecutando, los momentos en que ocurre el sweep, la basura dejada por los ROLLBACKs.
  • IBAnalyst. Analiza las estadísticas de la Base de Datos e identifica posibles problemas que causan un bajo rendimiento: transacciones que demoran mucho, cantidad de versiones de los registros, registros que han sido borrados pero aún permanecen en la Base de Datos y por lo tanto demoran la lectura, promedio de transacciones por día, conexiones perdidas, índices no usados, índices con muchos valores repetidos, etc.
  • FBMonLogger. Detecta consultas lentas, transacciones que tienen un aislamiento incorrecto, basura que debe ser recolectada, uso de la memoria, etc.
  • Sinática. Monitorea a la Base de Datos en tiempo real, ayudando a detectar los procesos que consumen muchos recursos o que producen “cuellos de botella”, además de las transacciones que demoran mucho en finalizar.

Conclusión:

Aunque realizar las tareas administrativas de backup, verificación de las estadísticas de los índices, revisar el archivo FIREBIRD.LOG, etc. deberían hacerse regularmente con cualquier Base de Datos, cuando éstas son de gran tamaño esas tareas ya son una obligación imprescindible porque no se puede correr el riesgo de que se corrompa o de que funcione muy lentamente, muchas veces tales bases de datos deben funcionar 365/24/7 (o sea, los 365 días del año, durante las 24 horas, de cada uno de los 7 días de la semana) y cualquier demora o detención puede ser muy grave.

En estos casos, suele ser recomendable contratar a una persona cuya función sea la de Administrador de la Base de Datos y proveerle de las herramientas informáticas adecuadas para que pueda realizar efectivamente su labor.

Artículos relacionados:

El índice del blog Firebird

El foro del blog Firebird21

Artículos

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

Usando FBClone para copiar datos

6 comentarios

Hay un programa llamado FBClone que sirve para copiar el contenido de las tablas de dos bases de datos que tengan la misma estructura.

La Base de Datos destino no debe estar abierta.

Puedes descargar a FBClone desde aquí:

https://code.google.com/p/fbclone/downloads/list

En el archivo .ZIP está incluido el código fuente del programa, por si te interesa mirarlo.

FBClone no necesita ser instalado, lo copias en cualquier carpeta y lo ejecutas desde allí, pero para ejecutarlo debes abrir una ventana “Símbolo del sistema”

FBCLONE1

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

Las opciones que empiezan con -s (source) se refieren a la Base de Datos origen o sea la que enviará las filas. Las opciones que empiezan con -t (target) se refieren a la Base de Datos destino o sea la que recibirá las filas.

La Base de Datos destino no necesita estar en la misma computadora que la Base de Datos origen, pueden estar en computadoras distintas.

FBCLONE2

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

Conclusión:

Usar FBClone para realizar backups tiene las ventajas de que no debemos hacer un ciclo backup/restore y que podemos fácilmente copiar de una versión del Firebird a otra.

Pero no te olvides que las estructuras de las tablas de ambas bases de datos deben ser iguales. Y que nadie debe estar conectado a la Base de Datos destino.

Artículos relacionados:

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

Los métodos para hacer Backup

El índice del blog Firebird21

Evitando conflictos cuando las transacciones superan el límite

1 comentario

Todas las transacciones tienen un número que las identifica, a ese número se le llama TID (Transaction Identificator).

TID es un número de tipo INTEGER, y los números de tipo INTEGER van desde el 0 hasta el 2 ^ 31 – 1, es decir desde 0 hasta 2.147.483.647

¿Y qué sucede cuándo se alcanzó el límite?

Si el número de tu última transacción es 2.147.483.647 el número de la siguiente transacción será 1, la cuenta se reinicia.

¿Y eso puede causar problemas?

Sí, porque habrá dos transacciones con el mismo TID, o sea que tendrás dos transacciones cuyo TID es 1. Y eso solamente puede provocar corrupción en tu Base de Datos.

¿Y cuál es la solución?

Hacer un ciclo backup/restore usando el programa GBAK antes de alcanzar el límite. Por ejemplo cuando el TID es 2.100.000.000 haces un ciclo backup/restore con GBAK y con eso conseguirás que en la Base de Datos restaurada (no en la original, sino en la que restauraste) se eliminen los TID de todas las transacciones. Por lo tanto:

  • Antes de que el número de la Next Transaction (siguiente transacción) llegue a 2.147.483.647 haces un backup de tu Base de Datos, usando para hacer el backup el programa GBAK
  • Restauras ese backup (probablemente con el mismo nombre que la Base de Datos original)
  • A partir de este momento todas las conexiones deben realizarse en la Base de Datos restaurada, no en la Base de Datos original
  • Eso te permitirá tener otras 2.147.483.647 transacciones

Ejemplo:

  1. Cuando el número de la Next Transaction llega a 2.100.000.000 se hace un backup, usando para ello el programa GBAK
  2. Se restaura el backup
  3. A partir de este momento todas las conexiones se hacen en el backup restaurado
  4. Se vuelve al punto 1.

De esta manera no habrá límites a la cantidad de transacciones totales de tu Base de Datos.

¿Por qué hay que usar GBAK para hacer el backup?

Porque GBAK además de hacer el backup también recolecta la basura (es la opción por defecto, y por supuesto que debe estar habilitada).

¿Qué significa “recolectar la basura”?

Eliminar permanentemente de la Base de Datos versiones de registros que ya no son útiles pero que permanecían en la Base de Datos, ocupando lugar innecesariamente. Cuando se hace un UPDATE o un DELETE el Firebird guarda la versión anterior del registro para que si la transacción finaliza con un ROLLBACK poder regresar a esa versión anterior. Eso va dejando versiones de registros inservibles a los cuales se les llama “basura”, alguna de la cual puede ser eliminada automáticamente, pero no toda. Para asegurarte de que toda la basura sea eliminada debes hacer un sweep (barrido) manual o usar el programa GBAK.

¿Por qué al recolectarse la basura se eliminan los TID?

Porque como hemos visto en este artículo:

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

una transacción solamente le interesa al Firebird cuando está activa, está revertida o está en limbo. Una transacción que finalizó con un COMMIT (o que finalizó con un ROLLBACK pero la basura que dejó ya fue recolectada) no es de interés para el Firebird ni para alguien más. ¿Por qué no? porque ya nada queda por hacer en esa transacción. Una transacción es algo transitorio, algo temporal, después de finalizar con un COMMIT o después que su basura fue recolectada ya no es interesante, porque ya nada se puede hacer en ella. Por ese motivo los TID pueden reutilizarse, pero para que puedan ser reutilizados se debe hacer un backup con GBAK y luego usar la Base de Datos restaurada, no la original.

¿Y cómo puedo saber si el número de la Next Transaction está cerca del límite de 2.147.483.647?

Usando el programa GSTAT que viene incluido con el Firebird (o muchos otros programas de terceros que también te muestran ese dato)

Transacciones1

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

También podrías escribir:

SELECT
   MON$NEXT_TRANSACTION
FROM
   MON$DATABASE

Entonces, cuando el número de la Next Transaction supera los 2.100.000.000 (algo que puede tardar muchos años, dependiendo de la cantidad de transacciones diarias que tenga tu Base de Datos) urgentemente debes ir pensando en hacer un ciclo backup/restore.

Si por ejemplo tienes 1.000.000 de transacciones por día entonces recién en 2.100 días necesitarás realizar el ciclo backup/restore, y eso equivale a más de 5 años y medio.

Artículos relacionados:

La arquitectura MGA

Entendiendo los identificadores de las transacciones

El índice del blog Firebird21

Entendiendo los identificadores de las transacciones

3 comentarios

Cada transacción tiene un número que la identifica de forma exacta, no pueden existir dos transacciones con el mismo número y en el mismo momento.

Identificador de la transacción

Al número que identifica a la transacción se le conoce como TID (Transaction Identificator)

Estados de las transacciones

Una transacción solamente puede estar en uno de estos estados:

  • Confirmada. Significa que la transacción finalizó con un COMMIT
  • Revertida. Significa que la transacción finalizó con un ROLLBACK
  • Activa. Significa que la transacción aún no finalizó ni con un COMMIT ni con un ROLLBACK ni está en limbo
  • Limbo. Significa que falló el segundo COMMIT. En transacciones que involucran a dos bases de datos hay que hacer dos COMMIT, uno para cada Base de Datos. Si el primer COMMIT finalizó exitosamente y el segundo COMMIT falló entonces la transacción está en limbo.

Transacciones interesantes

Hay algunas transacciones que para el Firebird son de interés, y son las siguientes:

  • Oldest transaction (la transacción más antigua). Es la transacción más antigua que no finalizó con un COMMIT. Eso significa que puede estar revertida, activa o en limbo. Las transacciones confirmadas (o sea, las que finalizaron con un COMMIT) ya no le interesan al Firebird. ¿Por qué no? porque ya han sido guardadas exitosamente y ya nada le queda para hacer con ellas. A la Oldest transaction se la conoce también como la Oldest Interesting Transaction (la más antigua transacción interesante) y se la representa con las letras OIT.
  • Oldest active transaction (la transacción activa más antigua). Es la más antigua transacción que no finalizó ni con un COMMIT ni con un ROLLBACK y no está en limbo. Eso significa que el usuario en este momento tiene a la transacción abierta y está haciendo algo con ella (insertando, modificando, borrando, consultando, ejecutando un stored procedure). Se la representa con las letras OAT.
  • Oldest snapshot transaction  (la transacción instantánea más antigua). Es la transacción más antigua cuya basura no puede ser recolectada. Una transacción deja basura cuando modifica una fila, borra una fila, o finaliza con un ROLLBACK. Lo normal es que esa basura pueda ser recolectada y entonces este número es igual al de la OAT, ese es el caso más común. A la Oldest snapshot transaction se la representa con las letras OST.
  • Next transaction (siguiente transacción). Es el número que tendrá la siguiente transacción.

Barrido automático

El sweep (barrido, de barrer con una escoba) puede estar activado o desactivado. Si está activado entonces empieza cuando la diferencia entre la OST y la OIT es mayor que el sweep interval (intervalo del barrido). Por ejemplo:

OST = 45.201

OIT = 25.200

Sweep interval = 20.000

OST – OIT = 45.201 – 25.200 = 20.001

Como el resultado de OST – OIT (que en este ejemplo es 20.001) es mayor que el intervalo del sweep (que en este ejemplo es 20.000) entonces empieza el sweep.

¿Que hace el sweep?

Elimina permanentemente de la Base de Datos toda la basura que fueron dejando las transacciones. Una transacción deja basura cuando modifica una fila, borra una fila, o finaliza con un ROLLBACK.

¿Es beneficioso el sweep?

Sí, muy beneficioso porque cuando finaliza la Base de Datos queda más limpia y en consecuencia conectarse a ella será más rápido y realizar operaciones en ella (INSERT, UPDATE, DELETE, FETCH, SELECT, EXECUTE PROCEDURE) también será más rápido.

Detectando problemas

Si la diferencia entre la OAT y la Next Transaction aumenta y aumenta eso significa que alguna transacción no está terminando con un COMMIT y por lo tanto está aumentando la cantidad de basura. Cuando la diferencia entre la OAT y la Next Transaction sea grande (“diferencia grande” depende de tu hardware y de tu software) notarás que cada vez toma más tiempo conectarse a la Base de Datos y realizar operaciones en ella. En estos casos lo correcto es utilizar el programa GFIX.EXE para hacer un sweep manual.

Reinicio de los identificadores de las transacciones. Caso 1

Cada vez que haces un ciclo backup/restore los números de los identificadores de las transacciones vuelven a empezar en uno. Por ejemplo:

NT = 65.920

Se hace un ciclo backup/restore y en la Base de Datos restaurada se ve que:

NT= 387

¿Qué pasó, por qué disminuyó la NT? Porque a todas las transacciones confirmadas el Firebird les asignó un número (el mismo número les asignó a todas las transacciones confirmadas) y a la basura la eliminó, o sea que dejó en la Base de Datos solamente las transacciones que previamente habían finalizado con un COMMIT.

¿Qué implica que los números de las transacciones interesantes cambien después de un ciclo backup/restore?

Que jamás deberías usar esos números dentro de tu programa para identificar a las transacciones entre una conexión y otra. O sea que tus programas no deberían depender de los números de las transacciones entre dos conexiones distintas. Dentro de la misma conexión no hay problema, el identificador no cambiará. Por ejemplo, una transacción está haciendo un INSERT en la tabla PRODUCTOS y esa transacción tiene el número 527. Puedes usar ese número 527 para identificarla sin problema. Pero si el usuario se desconectó de la Base de Datos y volvió a conectarse ya no deberías usar el número 527 porque ahora la transacción que hizo el INSERT a la tabla PRODUCTOS podría tener otro número (si se hizo un ciclo backup/restore entre ambas conexiones).

Reinicio de los identificadores de las transacciones. Caso 2

Hay otro caso en el cual el número de la Next Transaction no aumenta.

Los identificadores de las transacciones se guardan internamente como números de tipo INTEGER. Los números de tipo INTEGER pueden, como máximo, llegar hasta 2.147.483.647.

Entonces, ¿qué pasa cuando la Next Transaction alcanza a ese número?

Que ya no se puede seguir usando esa Base de Datos. Imposible. La conexión siempre será denegada.

¿Y cuál es la solución?

Hacer un ciclo backup/restore y usar la Base de Datos restaurada. No la original, porque la original ya está inaccesible, sino la restaurada.

Por lo tanto, si por algún motivo te interesa poder seguir accediendo a la Base de Datos original entonces el ciclo backup/restore que la reemplazará deberías hacerlo bastante antes de llegar al límite de 2.147.483.647 transacciones, por ejemplo al llegar a las 2.147.000.000 de transacciones podrías hacer un ciclo backup/restore y desde ese momento empezar a usar la Base de Datos restaurada, no la original. A la original podrás acceder un máximo de 483.647 veces más, cuando sea estrictamente necesario.

Artículos relacionados:

La Next Transaction después de un ciclo backup/restore

El índice del blog Firebird21

El foro del blog Firebird21

Older Entries