Entendiendo a GSTAT (4)

Deja un comentario

Entender como funciona el programa GSTAT es bastante largo. Ya hemos visto algo sobre él en estos artículos:

Entendiendo a GSTAT (1)

Entendiendo a GSTAT (2)

Entendiendo a GSTAT (3)

ahora, continuamos.

Opción -index

Esta es la opción que debemos elegir cuando solamente nos interesan los índices de nuestras tablas.

gstat01

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

Como es lo usual, la contraseña la extraemos de un archivo de texto y la salida del programa GSTAT la enviamos a otro archivo de texto. Esto último es para facilitarnos la tarea.

gstat02

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

En la Captura 2. vemos una parte del contenido del archivo de texto que nos muestra información sobre nuestros índices. Los nombres de los índices siempre aparecen ordenados alfabéticamente.

¿Cuál es el significado de lo que estamos viendo?

ASIENTOSCAB es el nombre de la tabla

131 es el identificador que la tabla ASIENTOSCAB tiene dentro de la tabla del sistema RDB$RELATIONS. Es en RDB$RELATIONS donde se  guardan los nombres de todas las tablas de la Base de Datos.

ASC01, ASC02, ASC03, y PK_ASIENTOSCAB son los nombres de los índices

0, 1, 2, 3, los números entre paréntesis que vemos después de los nombres de los índices son los identificadores de los índices menos 1 y nos indican el orden en el cual fueron creados, siendo 0 el primer índice que creamos, 1 el segundo índice que creamos, 2 el tercer índice que creamos y así sucesivamente. Si se creó un índice y luego se lo eliminó, el número que tenía no aparecerá en la lista.

Listado 1.

SELECT
   RDB$INDEX_ID,
   RDB$RELATION_NAME,
   RDB$INDEX_NAME
FROM
   RDB$INDICES
WHERE
   RDB$RELATION_NAME = 'ASIENTOSCAB'
ORDER BY
   RDB$INDEX_ID

gstat03

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

¿Por qué en la Captura 2. no muestra los verdaderos identificadores sino los identificadores menos 1? Es un verdadero misterio, quizás haya alguna razón valedera para ello pero es dudoso que exista. Probablemente sólo sea por costumbre.

Depth es la cantidad de indirecciones o desviaciones que hay en el árbol B-tree del índice. Lo ideal es que ese número sea como máximo 3. Si es mayor que 3 entonces el índice no será tan eficiente como podría ser ¿cómo lo solucionamos? aumentando el tamaño de la página de nuestra Base de Datos. Si por ejemplo el tamaño de la página es 4096 lo aumentamos a 8192 y volvemos a ejecutar a GSTAT con la opción -index para comprobar si Depth ahora es 1, 2, ó 3 (esos son los mejores valores que puede tener Depth). Si sigue siendo mayor que 3 entonces volvemos a aumentar el tamaño de la página de nuestra Base de Datos y ahora lo ponemos en 16384.

Leaf buckets es la cantidad de páginas que están en el nivel más bajo del árbol B-tree. Es en estas páginas donde se guardan los punteros a las filas de la tabla. En las demás páginas de índice se guardan los enlaces a otras páginas de índice.

Nodes es la cantidad total de filas en la tabla que han sido indexadas. Sin embargo, este número puede ser erróneo porque podrían aparecer filas que han sido borradas con DELETE y aún su basura no ha sido recolectada o también porque las columnas del índice cambiaron de valor. Por eso, es conveniente ejecutar a GSTAT con la opción -index solamente después de un sweep o de un ciclo backup/restore.

Average data length es el tamaño en bytes promedio de los datos de la columna (o columnas) que se indexaron. Como Firebird comprime esos datos antes de grabarlos en una página de índices, el average data length será siempre menor a la suma del tamaño de las columnas de la tabla.

Total dup es la cantidad total de duplicados que tiene un índice. Los índices que se utilizan en las restricciones Primary Key y Unique Key no admiten duplicados, pero los otros índices sí los admiten. Cuantos más duplicados haya, peor es el índice.

 Listado 2.

SELECT
   ASC_ANOEJE,
   ASC_CODSUC,
   ASC_NUMERO,
   COUNT(*)
FROM
   ASIENTOSCAB
GROUP BY
   ASC_ANOEJE,
   ASC_CODSUC,
   ASC_NUMERO

gstat05

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

gstat04

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

En la Captura 4. vemos que al ejecutar el Listado 2. se usó el índice ASC01, y en la Captura 5. vemos la cantidad de veces que los valores de ese índice aparecieron. En este caso no hay duplicados, ya que COUNT siempre nos muestra el número 1 pero en otros índices sí podría haber duplicados. El Listado 2. nos ayudará a conocer cuantos duplicados tiene nuestro índice. Recuerda que Total dup puede mostrarte una cantidad incorrecta de duplicados si no has hecho previamente un ciclo backup/restore.

Max dup es la cantidad máxima de valores duplicados que tiene un índice.

Fill distribution es una tabla de frecuencias y seguramente te recordarás de ellas si alguna vez estudiaste Estadísticas. Hay 5 filas, yendo de 20% en 20%, cada fila indicando la cantidad de páginas de índices que están completadas hasta ese porcentaje.

gstat02

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

En la Captura 6. vemos que hay 8 páginas de índices que están llenas entre un 20% y un 39%. Y hay 3 páginas de índices que están llenas entre un 40% y un 59%. La suma de 8 + 3 es 11, y siempre debe coincidir con leaf buckets.

Esta distribución es mala, estamos usando más páginas que las necesarias. ¿Cómo sabemos eso? porque no hay páginas rellenas entre un 80% y un 99%. En una buena distribución el número mayor debería estar siempre en la última fila, (es decir, en 80% a 99%). ¿Cómo conseguimos eso? Con un ciclo backup/restore y luego usando el backup restaurado.

Artículos relacionados:

Entendiendo a GSTAT (1)

Entendiendo a GSTAT (2)

Entendiendo a GSTAT (3)

El índice del blog Firebird21

El foro del blog Firebird21

Optimizando un SELECT que compara columnas de la misma tabla

3 comentarios

En general, debemos tener a todas las columnas de todas nuestras tablas normalizadas. Eso es lo correcto y es lo recomendable. Sin embargo, hay ocasiones en que desnormalizar las columnas es conveniente.

Una de esas ocasiones es cuando debemos escribir un SELECT que en la cláusula WHERE compara el contenido de dos columnas. Veamos un ejemplo.

Tenemos la tabla PRODUCTOS con la siguiente estructura:

optimizando1

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

Y queremos saber si hay productos cuyo precio de venta es menor que su precio de costo, así que escribimos el siguiente SELECT.

Listado 1.

SELECT
   *
FROM
   PRODUCTOS
WHERE
   PRD_PREVTA < PRD_PRECTO

La consulta nos mostrará el resultado correcto, pero si analizamos su rendimiento, encontraremos que no ha usado un índice.

optimizando2

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

El problema es que no podemos tener un índice que pueda ser usado en casos como este. O sea, que no podemos tener índices para:

  • Comparar dos columnas de la misma tabla por =
  • Comparar dos columnas de la misma tabla por <
  • Comparar dos columnas de la misma tabla por >
  • Comparar dos columnas de la misma tabla por <=
  • Comparar dos columnas de la misma tabla por >=
  • Comparar dos columnas de la misma tabla por <>

Si la tabla tiene pocas filas, eso no es un problema, Firebird es muy rápido para devolver el resultado de los SELECT. Pero si la tabla tiene muchas filas, allí ya es otro tema.

¿Y cómo podemos hacer para mejorar la velocidad de nuestro SELECT?

La solución es crear una columna que contenga la diferencia entre las dos columnas que nos interesan. La estructura de la tabla PRODUCTOS quedaría entonces así:

optimizando3

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

Para mantener actualizada a la columna PRD_DIFERE podríamos escribir un trigger como el siguiente:

Listado 2.

CREATE TRIGGER PRODUCTOS_BIU FOR PRODUCTOS
   ACTIVE BEFORE
   INSERT OR
   UPDATE
   POSITION 1
AS
BEGIN

   NEW.PRD_DIFERE = NEW.PRD_PREVTA - NEW.PRD_PRECTO;

END;

Y para usar un índice entonces deberemos crearlo.

Listado 3.

CREATE INDEX IDX_PRODUCTOS ON PRODUCTOS(PRD_DIFERE);

Y si ahora escribimos el SELECT del Listado 1. modificado para que utilice a la columna PRD_DIFERE, tendríamos:

Listado 4.

SELECT
   *
FROM
   PRODUCTOS
WHERE
  PRD_DIFERE < 0

Queremos verificar si ahora se está usando un índice, así que miramos el rendimiento y encontramos:

optimizando4

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

Y comprobamos que sí, efectivamente ahora se usa un índice, y por lo tanto nuestro SELECT será mucho más rápido que antes.

Conclusión:

En general debemos tener a todas las columnas de todas nuestras tablas normalizadas, pero hay excepciones, como el caso mostrado en este artículo. Eso se debe a que el Firebird no utiliza índices cuando comparamos el contenido de una columna con el contenido de otra columna. La solución es crear una columna adicional que contendrá la diferencia entre los valores de las columnas que necesitamos comparar.

Desde luego que comparar precio de costo con precio de venta es sólo un ejemplo. También podemos comparar importe vendido contra importe cobrado, importe comprado contra importe pagado, etc.

Artículos relacionados:

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