IBAnalyst: Cómo obtener estadísticas de la base de datos InterBase/Firebird de la manera correcta

Dmitry Kuzmenko, última actualización 31-03-2014

Resumen

Este documento está dedicado a consejos y trucos para recopilar y analizar estadísticas de bases de datos InterBase/Firebird con o sin IBAnalyst.

Momento adecuado, lugar adecuado

Suena extraño, pero simplemente tomar estadísticas mediante gstat o Services API no es suficiente. Las estadísticas deben tomarse en el momento adecuado para mostrar cómo las aplicaciones afectan los datos y las transacciones en la base de datos. El peor momento para tomar estadísticas es

• Justo después de una restauración
• Después de una copia de seguridad (gbak -b db.gdb) sin el interruptor -g
• Después de un barrido manual (gfix -sweep)

También es correcto que durante el trabajo puede haber momentos en los que la base de datos esté en un estado correcto, por ejemplo, cuando las aplicaciones generan menos carga en la base de datos de lo habitual (usuarios al inicio, hora de comer o según los tiempos específicos del proceso de negocio).

¿Cómo detectar cuándo hay algo mal en la base de datos?

Sí, sus aplicaciones pueden estar diseñadas tan perfectamente que siempre trabajarán con transacciones y datos correctamente, sin crear brechas de barrido, muchas transacciones activas, instantáneas de larga duración, etc. Normalmente esto no sucede. Al menos porque algunos desarrolladores prueban sus aplicaciones con 2-3 usuarios simultáneos, no más. Así, cuando configuran aplicaciones escritas para 15 o más usuarios simultáneos, la base de datos puede comportarse de manera impredecible. Por supuesto, el modo multiusuario puede funcionar bien, porque la mayoría de los conflictos multiusuario se pueden probar con 2-3 aplicaciones ejecutándose simultáneamente. Pero, luego, cuando se ejecuten más aplicaciones concurrentes, pueden surgir problemas de recolección de basura (al menos). Y esto se puede detectar si toma estadísticas en los momentos correctos.

Si no experimenta problemas de rendimiento periódicos

Esto puede suceder cuando sus aplicaciones están diseñadas correctamente, hay baja carga en la base de datos, o su hardware es moderno y muy potente (suficiente para manejar bien el número actual de usuarios y datos).

La información más valiosa es la carga de transacciones y la acumulación de versiones. Esto solo se puede ver si configura un guardado regular de estadísticas.

InterBase no tiene un programador de tareas interno, por lo que es libre de usar cualquier externo, como el Programador de tareas estándar (Windows) o cron (Unix).

La mejor configuración es obtener estadísticas de transacciones cada hora. Esto se puede hacer ejecutando

gstat -h db.gdb >db_stat_.txt

donde

db.gdb es el nombre de su base de datos,

db_stat_.txt es el archivo de texto donde se guardarán las estadísticas,

- fecha y hora actuales cuando se tomaron las estadísticas.

Si experimenta problemas de rendimiento periódicos

Estos problemas generalmente son causados por la ejecución del barrido automático. Primero debe determinar el período de tiempo entre tales caídas de rendimiento. Luego, divida este intervalo mínimamente en 4 (8, 16 y así sucesivamente). Ahora los sistemas de información tienen muchos usuarios concurrentes, y la mayoría de los problemas de rendimiento con servidor y base de datos no configurados ocurren 2 o 3 veces al día. Por ejemplo, si las caídas de rendimiento ocurren cada 3 horas, necesita tomar

gstat -h db.gdb

estadísticas cada 30-45 minutos, y

gstat -a -r db.gdb -user SYSDBA -pass masterkey

cada 1-1.5 horas.

Lo mejor es tomar estadísticas con gstat -a -r justo antes de la próxima caída de rendimiento esperada. Mostrará dónde está la basura real y cuántas versiones de registros obsoletas se han acumulado.

Qué hacer con estas estadísticas

Si su aplicación usa transacciones explícitamente y las usa bien, es decir, sabe qué es read_committed y cuándo usarlo, sus transacciones de instantánea no duran más de lo necesario, y las transacciones están activas el tiempo mínimo, puede ajustar el intervalo de barrido o desactivarlo, y luego solo preocuparse por cuántas actualizaciones hacen las aplicaciones y qué tablas necesitan menos actualizaciones o cuidado con las actualizaciones.

¿Qué significa esto, puede preguntar? Daremos un ejemplo de algún sistema donde los problemas de rendimiento ocurrían cada mañana durante 20-30 minutos. Eso era muy suficiente para las aplicaciones “matutinas”, y no podía durar más.

Se le hicieron preguntas correctas al administrador de la base de datos, y aquí está el panorama:

El trabajo diario estaba dividido en secciones: los analistas trabajan por la mañana, luego los operadores habituales insertan y editan datos, y al final del día se iniciaban procedimientos especiales para recopilar datos que se usarían para análisis al día siguiente (al menos).

El último trabajo en la base de datos al final del día era muchas actualizaciones, y actualizaciones de aquellas tablas que los analistas usaban por la mañana. Así que había muchas versiones de basura, que comenzaban a ser recopiladas por la aplicación que se ejecutaba por la mañana.

Y la respuesta a ese problema fue simple: ejecutar gfix -sweep al final del día.

El barrido lee todas las tablas de la base de datos e intenta recopilar todas las versiones de basura de transacciones confirmadas y revertidas. Después del barrido, la base de datos quedaba limpia casi como después de una restauración.

Y el “problema matutino” desapareció.

Por lo tanto, debe considerar las estadísticas con muchos otros factores:

1. cuántos usuarios concurrentes (promedio) trabajan durante el día

2. cuánto dura el día laboral (8, 12, 16, 24 horas)

3. qué tipo de aplicaciones se ejecutan en diferentes momentos del día y cómo afectan los datos utilizados por otras aplicaciones, que se ejecutan al mismo tiempo o después. Es decir, debe comprender los procesos de negocio que ocurren durante todo el día y toda la semana.

Cuando el DBA no puede hacer nada

Lamentablemente, estas situaciones ocurren. Y de nuevo, un ejemplo:

Algún sistema instalado para ~15 usuarios. Periódicamente el rendimiento es tan malo que el DBA necesita reiniciar el servidor. Después del reinicio del servidor, todo funciona bien por un tiempo, luego el rendimiento vuelve a empeorar. Las estadísticas mostraron que el promedio diario de transacciones es de aproximadamente 75,000, y hay transacciones activas desde el inicio del día hasta el momento en que el rendimiento cae.

Desafortunadamente, las aplicaciones fueron escritas con BDE y sin usar transacciones en absoluto; es decir, todo el manejo de transacciones era automático y usado por el propio BDE. Esto causó que algunas transacciones permanecieran activas durante mucho tiempo, y la basura (versiones de registros) se acumulaba hasta que el DBA reiniciaba el servidor. Después del reinicio, se ejecutaba el barrido automático y la basura se recopilaba (eliminaba).

Todo esto fue causado por las aplicaciones, porque solo se probaron con 2-3 usuarios concurrentes, y cuando llegaron a ~15, las aplicaciones comenzaron a generar una carga muy alta.

Hay que decir que en esa configuración el 70% de los usuarios solo leían datos, y el otro 30% insertaba y actualizaba algunos (!) datos.

En esta situación, lo único que puede mejorar el rendimiento es rediseñar las aplicaciones por completo.

¿Aún tiene preguntas? Pregúntenos en [email protected]