Blog de auditoría de Cognos: consejos y trucos para entornos de gran y gran volumen

by 17 de mayo de 2021Revisión de cuentas0 comentarios

Un blog de John Boyer y Mike Norris.

Introducción

Es importante tener la capacidad de auditoría de Cognos funcionando para saber y comprender cómo la comunidad de usuarios utiliza Cognos y ayudar a responder preguntas como:

    • ¿Quién usa el sistema?
    • ¿Qué informes están ejecutando?
    • ¿Cuáles son los tiempos de ejecución del informe?
    • Con la ayuda de otras herramientas, como MotioCI, ¿qué contenido no se usa?

Teniendo en cuenta lo importante que es mantener entornos de Cognos Analytics saludables, sorprendentemente se ha escrito poco sobre su base de datos de auditoría más allá de la documentación estándar del producto. Quizás, se da por sentado, pero las organizaciones que lo usan saben que con el tiempo la consulta de las tablas de la base de datos de auditoría comenzará a ralentizarse, especialmente si su organización tiene muchos usuarios que ejecutan muchos informes y tiene mucho historial. Además, el registro de la actividad de auditoría en sí puede retrasarse porque se pone en cola cuando no se puede agregar a la base de datos con la suficiente rapidez, por ejemplo. Ahí es cuando comienza a pensar en el rendimiento de la base de datos como lo haría con cualquier base de datos operativa que tenga requisitos de informes.

Las tablas grandes suelen ralentizar el rendimiento de las consultas. Cuanto más grande sea la tabla, más tiempo llevará insertarla y consultarla. Recuerde que estas tablas y la Base de datos de auditoría son básicamente una base de datos operativa; las escrituras ocurren con frecuencia y funcionan en nuestra contra, ya que no podemos enfocarlas solo para operaciones de lectura como lo haría con un data mart.

Al igual que el almacén de contenido, el estado del entorno de Cognos también debe tener en cuenta el estado de la base de datos de auditoría. El crecimiento ilimitado de la base de datos de auditoría puede convertirse en un problema con el tiempo y, eventualmente, incluso puede afectar el rendimiento general de un entorno Cognos. En muchas organizaciones con regulaciones externas impuestas, no tener un registro de auditoría completo puede llevarlos a una situación de incumplimiento con fuertes repercusiones. Entonces, ¿cómo nos ocupamos de tener que mantener tantos datos con fines de auditoría histórica, en algunos casos hasta 10 años, y aún así obtener los informes que necesitamos para mantener el medio ambiente y mantener a los usuarios contentos con el rendimiento?

El Desafío

    • El crecimiento ilimitado de la base de datos de auditoría tiene un impacto negativo en la salud del entorno de Cognos
    • Los informes de la base de datos de auditoría se han vuelto lentos o inutilizables
    • Cognos experimenta retrasos en la escritura de registros en la base de datos de auditoría
    • La base de datos de auditoría se está quedando sin espacio en disco

Todo esto significa que no son solo los informes que se basan en la base de datos de auditoría los que sufren, sino a menudo todo el sistema. Si la base de datos de auditoría está en el mismo servidor que el almacén de contenido de Cognos, el rendimiento de todo lo relacionado con Cognos se verá afectado en ese entorno.

La puesta en marcha

Asumimos:

    1. Cognos Analytics está instalado y en ejecución
    2. Cognos está configurado para iniciar sesión en una base de datos de auditoría
        • Disponga de una base de datos de auditoría
        • Establecer niveles de registro de auditoría adecuados en la administración de Cognos
        • Cognos está escribiendo registros en la base de datos
    3. La base de datos de auditoría se ha utilizado durante más de un año.
    4. El entorno es muy activo con usuarios y ejecuciones.
    5. El paquete de auditoría se está utilizando para mostrar los datos de uso de Cognos.
    6. Buscamos mejorar el rendimiento de los informes de la base de datos de auditoría
    7. Comenzar de nuevo o eliminar registros antiguos no siempre es una opción

Si aún no tiene Cognos Audit instalado y configurado, Lodestar Solutions, un Motio socio, tiene una excelente post sobre la habilitación de Auditoría en Cognos BI / CA.

La Solución

Hay algunas posibles soluciones que se presentan rápidamente:

    1. Reduzca el volumen de datos al:
        • Mover algunos de los datos más antiguos a otra base de datos
        • Mover algunos de los datos más antiguos a otra tabla en la misma base de datos
    2. Solo borra o haz un arcohive algunos de los datos y no te preocupes por eso
    3. Vive con ello. Patea la lata por el road y presionar al administrador de la base de datos para el rendimiento
      mejoras mientras los esposó al no permitir alteraciones del esquema o
      índices

No vamos a ocuparnos de la opción 3. La opción 2, eliminar los datos, no es una buena opción y recomiendo mantener al menos el valor de 18 meses como mínimo. Pero, si lo desea, IBM proporciona una utilidad, Limpieza de DB de auditoría (Cognos BI) o un guión (Cognos Analytics) que hará exactamente eso. La utilidad de Cognos BI elimina registros según una marca de tiempo, mientras que los scripts de Cognos Analytics simplemente eliminan los índices y las tablas.

Las recomendaciones que les hicimos a los clientes anteriormente sobre esto fueron separarlas en dos bases de datos:

    1. Auditoría - En vivo: contiene los datos de la semana más reciente
    2. Auditoría - Histórico: contiene datos históricos (hasta N años)

En resumen, el proceso se ejecuta semanalmente para mover los registros más recientes de Audit Live a Audit Historical. Audit Live comienza de nuevo como una pizarra en blanco después de que se ejecuta este proceso.

    1. El Live DB es rápido y ajustado, lo que permite que las inserciones se realicen lo más rápido posible
    2. Las consultas de auditoría se dirigen exclusivamente a la base de datos histórica

Con este enfoque, no hay una "unión" implícita de los datos en vivo y los datos históricos. Yo diría que probablemente quieras mantenerlo así.

En Cognos Administration, puede agregar dos conexiones diferentes para el origen de datos de auditoría. Cuando un usuario ejecuta un informe sobre el paquete de auditoría, se le pregunta qué conexión desea utilizar:

Bases de datos de auditoría

En caso de que desee ver datos de auditoría en vivo en lugar de datos de auditoría históricos, simplemente elija la conexión "Auditoría - En vivo" cuando se le solicite (debería ser la excepción, no la norma).

Si REALMENTE también desea proporcionar una vista consolidada de Live e Histórico, puede hacerlo, pero afectaría el rendimiento.

Por ejemplo, podría crear una tercera base de datos llamada "Auditoría - Vista consolidada" y luego, para cada tabla en el esquema de auditoría: crear una vista con el mismo nombre que sea una unión SQL entre la tabla en la base de datos en vivo y la tabla en el DB histórico. De manera similar, esto también podría lograrse en el modelo Framework Manager, pero, nuevamente, el rendimiento sería una consideración clave.

Algunos de nuestros clientes han creado una visión consolidada. En nuestra opinión, es probable que esto sea excesivo. El rendimiento siempre sería peor en esta vista consolidada y no nos hemos encontrado con muchos casos de uso que utilicen tanto los conjuntos de datos en vivo como el histórico. El Live se utiliza para la resolución de problemas y el Histórico para la generación de informes de tendencias.

A partir de Cognos Analytics 11.1.7, la base de datos de auditoría ha aumentado a 21 tablas. Puede encontrar más información en otra parte sobre la base de datos de auditoría, ejemplos de informes de auditoría y el modelo de Framework Manager. El nivel de registro predeterminado es Mínimo, pero es posible que desee utilizar el siguiente nivel, Básico, para capturar solicitudes de uso, administración de cuentas de usuario y uso del tiempo de ejecución. Una forma de mantener el rendimiento del sistema es manteniendo el nivel de registro en el nivel más bajo requerido. Obviamente, cuanto más registro realiza el servidor, más se puede ver afectado el rendimiento general del servidor.

Las tablas clave que interesarán a la mayoría de los administradores son las 6 tablas que registran la actividad del usuario y la actividad de informes en el sistema.

  • COGIPF_USERLOGON: almacena la información de inicio de sesión del usuario (incluido el cierre de sesión)
  • COGIPF_RUNREPORT: almacena información sobre ejecuciones de informes
  • COGIPF_VIEWREPORT: almacena información sobre solicitudes de visualización de informes
  • COGIPF_EDITQUERY: almacena información sobre ejecuciones de consultas
  • COGIPF_RUNJOB: almacena información sobre solicitudes de trabajo
  • COGIPF_ACTION: registra las acciones del usuario en Cognos (esta tabla puede crecer mucho más rápidamente que las otras)

La configuración lista para usar se ve así:

Configuración de auditoría predeterminada

Configuración recomendada:

Configuración de auditoría recomendada

La base de datos de auditoría de Cognos - Live contiene 1 semana de datos de auditoría. Los datos anteriores a 1 semana se mueven a la base de datos de auditoría de Cognos: histórico.

La línea de Cognos Audit Database - Live a Cognos Audit Database - Historical en el diagrama es responsable de:

  • Copia de datos de Live Audit a Historical Audit
  • Elimine todas las filas de la auditoría en vivo que tengan más de 1 semana
  • Elimine todas las filas de la auditoría histórica que tengan más de x años
  • Elimine todas las filas de COGIPF_ACTION que tengan más de 6 meses

Índices

Los diferentes tipos de bases de datos tienen diferentes tipos de indexación. Un índice de base de datos es una estructura de datos, asociada con una tabla (o vista), que se utiliza para mejorar el tiempo de ejecución de las consultas al recuperar los datos de esa tabla (o vista). Trabaje con su DBA para crear la estrategia óptima. Querrán saber las respuestas a preguntas como estas para tomar las mejores decisiones sobre qué columnas indexar. Obviamente, el administrador de la base de datos podría encontrar las respuestas a algunas o todas estas preguntas sin su ayuda, pero tomaría algo de investigación y algo de tiempo:

  • ¿Cuántos registros tienen las tablas y hasta qué tamaño espera que crezcan? (Indexar una tabla no será útil a menos que la tabla tenga una gran cantidad de registros).
  • ¿Sabes qué columnas son únicas? ¿Permiten valores NULL? ¿Qué columnas tienen el tipo de datos de entero o entero grande? (Las columnas con tipos de datos numéricos y que son ÚNICAS y NO NULAS son buenas candidatas para participar en la clave de índice).
  • ¿Dónde están sus principales problemas de rendimiento hoy? ¿Están recuperando los datos? ¿Hay consultas o informes específicos que sean más problemáticos? (Esto puede llevar al administrador de la base de datos a algunas columnas específicas que se pueden optimizar).
  • ¿Qué campos se utilizan para unir tablas para informes?
  • ¿Qué campos se utilizan para filtrar, ordenar, agrupar y agregar?

No es sorprendente que estas sean las mismas preguntas que deberían responderse para mejorar el rendimiento de cualquier tabla de base de datos.

Soporte de IBM de CFP. creando un índice en las columnas "COGIPF_REQUESTID", "COGIPF_SUBREQUESTID" y "COGIPF_STEPID" para las siguientes tablas para mejorar el rendimiento:

  • COGIPF_NATIVEQUERY
  • COGIPF_RUNJOB
  • COGIPF_RUNJOBSTEP
  • COGIPF_RUNREPORT
  • COGIPF_EDITQUERY

Más en otras tablas menos utilizadas:

  • COGIPF_POWERPLAY
  • COGIPF_SERVICIOHUMANTASK
  • COGIPF_SERVICIOHUMANTASK_DETALLE

Puede usar esto como un punto de partida, pero yo pasaría por el ejercicio de responder las preguntas anteriores para llegar a la mejor respuesta para su organización.

Otras Consideraciones

  1. Modelo de auditoría FM. Recuerde que el modelo de Framework Manager que proporciona IBM se basa en las tablas y campos predeterminados. Cualquier cambio que realice en las tablas de informes deberá reflejarse en el modelo. La facilidad o complejidad de estos cambios, o su competencia organizacional para realizar estos cambios, pueden afectar la solución que elija.
  2. Campos Adicionales. Si va a hacerlo, ahora es el momento de agregar campos adicionales para el contexto o los datos de referencia para mejorar los informes de auditoría.
  3. Tablas resumen. En lugar de simplemente copiar los datos a su tabla histórica, comprímalos. Puede agregar los datos al nivel del día para que sea más eficiente para los informes.
  4. Vistas en lugar de tablas. Otros dicen: “Entonces, en lugar de tener una base de datos 'actual' y una base de datos 'histórica', solo debe tener una base de datos, y todas las tablas deben tener el prefijo 'histórico'. Luego, debe crear un conjunto de vistas, una para cada tabla que desee ver como 'actual', y hacer que cada vista filtre las filas históricas que no desea ver y deje pasar solo las actuales ".
    https://softwareengineering.stackexchange.com/questions/276395/two-database-architecture-operational-and-historical/276419#276419

Conclusión

La conclusión es que con la información proporcionada aquí, debe estar bien preparado para tener una conversación productiva con su DBA. Es muy probable que haya resuelto problemas similares antes.

Los cambios propuestos en la arquitectura de la base de datos de auditoría de Cognos mejorarán el rendimiento tanto en los informes directos como en las aplicaciones de terceros que dependen de él, como Motio, ReportCard e inventario.

Por cierto, si ha tenido esa conversación con su DBA, nos encantaría saberlo. También nos encantaría saber si ha resuelto el problema de una base de datos de auditoría de bajo rendimiento y cómo lo hizo.