¡IBAnalyst ahora es parte de HQbird Standard!

IBAnalyst es una herramienta que permite a un administrador de bases de datos analizar estadísticas detalladas de bases de datos Firebird o InterBase y luego identificar posibles problemas con el rendimiento de la base de datos, el mantenimiento y cómo una aplicación interactúa con la base de datos.

Documentación

IBAnalyst muestra gráficamente las estadísticas de la base de datos Firebird (o InterBase) de una manera fácil de usar y resalta los siguientes problemas:

fragmentación de tablas y BLOBs,
versionado de registros,
recolección de basura,
efectividad de índices, etc.

Además, IBAnalyst puede automáticamente hacer sugerencias inteligentes sobre cómo mejorar el rendimiento y el mantenimiento de la base de datos.

IBAnalyst puede obtener estadísticas de bases de datos de producción en vivo a través de Services API (recomendado), o analizar la salida de texto de los comandos gstat -a -r …. Las estadísticas de los períodos de carga máxima pueden dar mucha información sobre problemas reales de rendimiento en bases de datos de producción.

Cómo IBAnalyst puede ayudar a encontrar problemas en tu base de datos Firebird o InterBase

Repasemos las características clave de IBAnalyst. Cuando miras las estadísticas de tu base de datos en IBAnalyst por primera vez, las cosas pueden no estar claras, especialmente si IBAnalyst muestra muchas advertencias con celdas de colores rojo y amarillo en las vistas de Resumen, Tablas e Índices. Consideremos varios ejemplos reales de estadísticas.

Vista de Resumen

La página de Resumen muestra mucha información, pero lo más valioso es el estado de las transacciones ( por favor lee la descripción de los posibles estados de transacciones en la ayuda de IBAnalyst, disponible presionando F1 o en el menú Ayuda).

En esta captura de pantalla puedes ver que alguna transacción está activa durante mucho tiempo, “60% del promedio diario”. IBAnalyst marca el estado de dicha transacción en rojo, porque esta transacción puede impedir que las versiones acumuladas sean consideradas como basura por el servidor y, por lo tanto, sean recolectadas. Esta es una posible causa de lentitud: cuantas más versiones existan para un registro, más tiempo tomará leerlo.

Para encontrar esta transacción de larga duración puedes usar el módulo MON$Logger de FBScanner, o realizar una consulta directa a las tablas MON$. Luego, para averiguar qué tablas fueron afectadas por transacciones de larga duración (tablas con muchas versiones de registros), necesitas ir a la vista “Tablas” de IBAnalyst.

Vista de Tablas

En la vista “Tablas” puedes ver las tablas y sus parámetros importantes: número de registros, número de versiones de registros, longitud de registro, número máximo de versiones, etc.

Puedes ordenar esta vista para encontrar las tablas más grandes. Especialmente nos interesan las tablas con muchas versiones de registros: muchas versiones de registros harán que la recolección de basura para las tablas afectadas sea más larga. Generalmente es necesario cambiar los algoritmos de actualización y eliminación para deshacerse de muchas versiones de registros.

Las Versiones de Fila muestran el número total de versiones para una tabla particular, y Max Vers muestra el máximo de versiones alcanzado por algún registro. Por ejemplo, si miras la tabla NAB, hay 11.9 millones de registros, las versiones totales son 20932, pero un registro tiene 176 versiones. Leer y analizar ese paquete desde el disco toma más tiempo, por lo que leer ese registro es más lento que leer otros.

Esta imagen también muestra muchas tablas donde se eliminaron datos. Pero, debido a la transacción de larga duración, el servidor no puede eliminar estas versiones, y todavía están en el disco, todavía indexadas, y todavía son leídas por el servidor al leer datos.

Vista de Índices

Algunas bases de datos de producción pueden tener índices con un solo valor de clave indexado. Esto puede suceder porque la base de datos fue desarrollada “para ser ampliada en el futuro”, o alguien simplemente experimentó con los índices durante el desarrollo o las pruebas. Puedes ver estos índices como “Inútiles” en IBAnalyst:

SKIN04, SKIN05, SKOUT03, etc., construidos sobre la columna que tiene solo un valor para todas las filas (millones de filas). Estos índices son realmente inútiles, porque

el optimizador puede usar este índice si especificas “where field = …”. Dado que el campo contiene solo un valor, usar el índice causará una lectura inútil de páginas de índice del disco a la memoria, y consumirá memoria (y tiempo) cuando el servidor prepare qué filas mostrar para esa consulta.
crear índices es parte del proceso de restauración. Los índices adicionales añaden tiempo extra.

Por supuesto, eso no es todo lo que puedes encontrar sobre tu base de datos en IBAnalyst. También puedes encontrar

número promedio de transacciones por día
si hubo rollbacks o conexiones perdidas, y cuándo
qué tan grandes (en megabytes) son cada tabla e índice
tablas que tienen registros intercalados con blobs, y por lo tanto leer solo registros es más lento
tablas vacías: simplemente olvidadas, o vacías en el momento en que se tomaron las estadísticas
índices con muchos duplicados de claves (puedes considerar la distribución de valores de la columna)
índices con profundidad 4 o mayor: quizás necesites aumentar el tamaño de página para acelerar

Recomendaciones automáticas

Si te confunden las advertencias de celdas de colores, simplemente abre “Reports\View recommendations”: todo lo suficiente para el rendimiento de la base de datos está reunido aquí. No dudes en hacer cualquier pregunta ( [email protected])