Blog de auditoría de Cognos: consellos e trucos para ambientes de grande e alto volume

by Pode 17, 2021Auditoríacomentarios 0

Un blogue de John Boyer e Mike Norris.

introdución

É importante que a capacidade de auditoría de Cognos funcione para coñecer e comprender como a comunidade de usuarios utiliza Cognos e axudar a responder a preguntas como:

    • Quen está a usar o sistema?
    • Que informes están publicando?
    • Cales son os tempos de execución do informe?
    • Coa axuda doutras ferramentas, como MotioCI, que contido non se usa?

Tendo en conta o crítico que é manter un ambiente saudable de Cognos Analytics, sorprendentemente pouco se escribiu sobre a súa base de datos de auditoría máis alá da documentación estándar do produto. Quizais se dea por feito, pero as organizacións que o usan saben que co tempo as consultas sobre as táboas da base de datos de auditoría comezarán a ser lentas, especialmente se a súa organización ten moitos usuarios que realizan moitos informes e ten moita historia. O que é máis é que o rexistro da actividade de auditoría pode demorarse porque está en cola cando non se pode engadir á base de datos con suficiente rapidez, por exemplo. É entón cando comeza a pensar sobre o rendemento da base de datos como faría con calquera base de datos operativa que teña requisitos de informes.

As táboas grandes normalmente diminúen o rendemento da consulta. Canto maior sexa a táboa, máis tempo tarda en inserir e consultar. Lembre que estas táboas e a base de datos de auditoría son basicamente unha base de datos operativa; as escrituras están a suceder con frecuencia e traballan contra nós, xa que non podemos enfocalas só para ler operacións como faría cun data mart.

Ao igual que o almacén de contido, a saúde do contorno Cognos tamén debe ter en conta a saúde da base de datos de auditoría. O crecemento ilimitado da base de datos de auditoría pode converterse nun problema co paso do tempo e pode chegar a afectar o rendemento xeral dun ambiente Cognos. En moitas organizacións con regulacións externas encamiñadas a elas, non ter un rexistro de auditoría completo pode levalos a unha situación de incumprimento con fortes repercusións. Entón, como lidamos con ter que manter tantos datos con fins de auditoría histórica (nalgúns casos ata 10 anos), pero aínda así recibimos os informes que necesitamos para manter o ambiente e manter aos usuarios satisfeitos co rendemento?

O Desafío

    • O crecemento ilimitado da base de datos de auditoría está afectando negativamente á saúde do ambiente Cognos
    • Informar da base de datos de auditoría volveuse lento ou inutilizable
    • Cognos experimenta retrasos na gravación de rexistros na base de datos de auditoría
    • A base de datos de auditoría está quedando sen espazo en disco

Todo isto significa que non só os informes dependen da base de datos de auditoría son os que sofren, senón moitas veces todo o sistema. Se a base de datos de auditoría está no mesmo servidor que o almacén de contido de Cognos, o rendemento de todo o que Cognos verá afectado nese contorno.

A Configuración

Supoñemos:

    1. Cognos Analytics está instalado e en execución
    2. Cognos está configurado para rexistrarse nunha base de datos de auditoría
        • Dispoñer dunha base de datos de auditoría
        • Estableza os niveis de rexistro de auditoría axeitados na administración de Cognos
        • Cognos está a escribir os rexistros na base de datos
    3. A base de datos de auditoría leva máis dun ano en uso
    4. O ambiente é moi activo con usuarios e execucións
    5. O paquete de auditoría estase a empregar para aflorar datos de uso de Cognos
    6. Estamos buscando mellorar o rendemento dos informes da base de datos de auditoría
    7. Comezar de novo ou eliminar rexistros antigos non sempre é unha opción

Se aínda non ten instalado e configurado Cognos Audit, Lodestar Solutions, a Motio compañeiro, ten un excelente enviar sobre habilitar a auditoría en Cognos BI / CA.

A solución

Hai algunhas solucións posibles que se presentan rapidamente:

    1. Reduce o volume de datos por:
        • Mover algúns dos datos máis antigos a outra base de datos
        • Mover algúns dos datos máis antigos a outra táboa da mesma base de datos
    2. Só tes que eliminar ou arquearhive algúns dos datos e non te preocupes
    3. Vive con el. Patade a lata polo road e empurra o administrador da base de datos para obter o seu rendemento
      as melloras ao esposalas ao non permitir alteracións do esquema ou
      índices

Non imos tratar a opción 3. A opción 2, eliminar os datos, non é unha boa opción e recomendaríalle manter un valor mínimo de 18 meses como mínimo. Pero, se estás tan inclinado, IBM ofrece unha utilidade, AuditDBCleanup (Cognos BI) ou a escrita (Cognos Analytics) que fará exactamente iso. A utilidade para Cognos BI elimina rexistros baseados nunha marca de tempo mentres que os scripts para Cognos Analytics só eliminan os índices e as táboas.

As recomendacións que fixemos anteriormente aos clientes sobre isto consistían en separarnos en dúas bases de datos:

    1. Auditoría: en directo: contén os datos da semana máis recente
    2. Auditoría: histórica: contén datos históricos (ata N anos)

En resumo, o proceso execútase semanalmente para mover os rexistros máis recentes de Audit Live a Audit Historical. Audit Live comeza de novo como unha pizarra en branco despois de executarse este proceso.

    1. O Live DB é rápido e axustado, o que permite que as insercións se produzan o máis rápido posible
    2. As consultas de auditoría diríxense exclusivamente ao DB histórico

Usando este enfoque, non hai "unión" implícita dos datos en directo e dos datos históricos. Eu diría que probablemente queira seguir así.

En Cognos Administration, pode engadir dúas conexións diferentes para a fonte de datos de auditoría. Cando un usuario executa un informe contra o paquete de auditoría, solicítaselle a conexión que quere usar:

Bases de datos de auditoría

Se queres ver os datos de auditoría en vivo en vez de datos de auditoría históricos, só tes que escoller a conexión "Auditoría - En directo" cando se che solicite (debería ser a excepción e non a norma).

Se REALMENTE tamén desexa ofrecer unha visión consolidada de Live e Historical, podería facelo, pero repercutiría no rendemento.

Por exemplo, podería crear unha terceira base de datos chamada "Auditoría - Vista consolidada" e, a continuación, para cada táboa do esquema de auditoría: cree unha vista con nome idéntico que sexa unha unión SQL entre a táboa da base de datos en directo e a táboa na DB histórico. Do mesmo xeito, isto tamén se podería lograr no modelo de Framework Manager, pero, de novo, o rendemento sería unha consideración clave.

Algúns dos nosos clientes crearon unha visión consolidada. A nosa opinión é que probablemente sexa demasiado. O rendemento sempre sería peor nesta visión consolidada e non atopamos moitos casos de uso que empreguen os conxuntos de datos en directo e o histórico. O Live está a empregarse para a resolución de problemas e o Historial para o informe de tendencias.

A partir de Cognos Analytics 11.1.7, a base de datos de auditoría creceu ata 21 táboas. Podes atopar máis información noutros lugares sobre a base de datos de auditoría, exemplos de informes de auditoría e o modelo de Framework Manager. O nivel de rexistro predeterminado é Mínimo, pero pode querer usar o seguinte nivel, Básico, para capturar solicitudes de uso, xestión de contas de usuario e uso en tempo de execución. Un xeito de manter o rendemento do sistema é manter o nivel de rexistro ao nivel máis baixo requirido. Obviamente, canto máis rexistro se faga polo servidor, máis rendemento global do servidor pode verse afectado.

As táboas clave que máis interesarán aos administradores son as 6 táboas que rexistran a actividade do usuario e a actividade de informes no sistema.

  • COGIPF_USERLOGON: almacena a información de inicio de sesión do usuario (incluído o inicio de sesión)
  • COGIPF_RUNREPORT: almacena información sobre execucións de informes
  • COGIPF_VIEWREPORT: almacena información sobre solicitudes de visualización de informes
  • COGIPF_EDITQUERY: almacena información sobre as execucións de consultas
  • COGIPF_RUNJOB: almacena información sobre solicitudes de emprego
  • COGIPF_ACTION: rexistra as accións do usuario en Cognos (esta táboa pode crecer moito máis rápido que as outras)

A configuración que está fóra de caixa ten o seguinte aspecto:

Configuración de auditoría predeterminada

Configuración recomendada:

Configuración de auditoría recomendada

A base de datos de auditoría de Cognos - En directo contén 1 semana de datos de auditoría. Os datos anteriores a 1 semana móvense á base de datos de auditoría de Cognos: histórica.

A liña da base de datos de auditoría de Cognos - Base de datos de auditoría en directo a Cognos - A historia do diagrama é responsable de:

  • Copiar datos da auditoría en directo á auditoría histórica
  • Elimina todas as filas da auditoría en directo que teñan máis de 1 semana
  • Elimina todas as filas da auditoría histórica que teñan máis de x anos
  • Elimina todas as filas de COGIPF_ACTION que teñan máis de 6 meses

Índices

Diferentes tipos de bases de datos teñen diferentes tipos de indexación. Un índice de base de datos é unha estrutura de datos, asociada a unha táboa (ou vista), usada para mellorar o tempo de execución das consultas ao recuperar os datos desa táboa (ou vista). Traballa co teu DBA para crear a estratexia óptima. Quererán coñecer as respostas a preguntas como estas para tomar as mellores decisións sobre que columnas indexar. Obviamente, o administrador da base de datos podería descubrir as respostas a algunhas ou a todas estas preguntas sen a súa axuda, pero levaría algo de investigación e algún tempo:

  • Cantos rexistros teñen as táboas e con que tamaño esperas que medren? (A indexación dunha táboa non será útil a menos que a táboa conteña un gran número de rexistros.)
  • ¿Sabes que columnas son únicas? Permiten valores NULL? Que columnas teñen un tipo de datos enteiro ou enteiro grande? (As columnas con tipos de datos numéricos que son ÚNICOS e NON NULOS son candidatos fortes para participar na clave de índice.)
  • Onde están os teus principais problemas de rendemento na actualidade? Están recuperando os datos? Hai consultas ou informes específicos que sexan un problema máis? (Isto pode levar ao administrador da base de datos a algunhas columnas específicas que se poden optimizar.)
  • Que campos se usan para unir táboas para informar?
  • Que campos se usan para filtrar, ordenar, agrupar e agregar?

Non en balde, estas son as mesmas preguntas ás que habería que responder para mellorar o rendemento de calquera táboa de bases de datos.

Soporte técnico de IBM recomenda creando un índice nas columnas "COGIPF_REQUESTID", "COGIPF_SUBREQUESTID" e "COGIPF_STEPID" para as seguintes táboas para mellorar o rendemento:

  • COGIPF_NATIVEQUERY
  • COGIPF_RUNJOB
  • COGIPF_RUNJOBSTEP
  • COGIPF_RUNREPORT
  • COGIPF_EDITQUERY

Ademais noutras táboas menos usadas:

  • COGIPF_POWERPLAY
  • COGIPF_HUMANTTASKSERVICE
  • COGIPF_HUMANTASKSERVICE_DETAIL

Podes usar isto como punto de partida, pero eu faría o exercicio de responder ás preguntas anteriores para chegar á mellor resposta para a túa organización.

outras consideracións

  1. Modelo de auditoría FM. Lembre que o modelo de Framework Manager que ofrece IBM está modelado nas táboas e campos predeterminados. Calquera cambio que faga nas táboas de informes deberá reflectirse no modelo. A facilidade ou complexidade destes cambios ou a súa competencia organizativa para facer estes cambios poden afectar á solución que escolla.
  2. Campos adicionais. Se o vas a facer, agora é o momento de engadir campos adicionais para datos de contexto ou de referencia para mellorar os informes de auditoría.
  3. Táboas de resumo. En vez de simplemente copiar os datos na táboa histórica, comprímea. Podería agregar os datos ao nivel do día para facelo máis eficiente na elaboración de informes.
  4. Vistas en lugar de táboas. Outros din: "Entón, en vez de ter unha base de datos" actual "e unha base de datos" histórica ", só debería ter unha base de datos e todas as táboas nel deberían ir prefixadas con" histórica ". Despois, debes crear un conxunto de vistas, unha para cada táboa que queiras ver como "actual", e que cada vista filtre as filas históricas que non queres ver e deixe pasar só as actuais. "
    https://softwareengineering.stackexchange.com/questions/276395/two-database-architecture-operational-and-historical/276419#276419

Conclusión

A conclusión é que coa información proporcionada aquí debería estar ben preparado para manter unha conversa produtiva co seu DBA. É probable que xa resolvese problemas similares.

Os cambios propostos na arquitectura de Cognos Audit Database mellorarán o rendemento tanto nos informes directos como nas aplicacións de terceiros que dependen dela, como Motio'S ReportCard e Inventario.

Por certo, se mantiveches esa conversa co teu DBA, encantaríanos escoitalo. Tamén nos encantaría saber se resolveu o problema dunha base de datos de auditoría con pouco rendemento e como o fixo.