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