Un blog de John Boyer et Mike Norris.
Introduction
Il est important que la fonction d'audit de Cognos fonctionne pour savoir et comprendre comment Cognos est utilisé par votre communauté d'utilisateurs et pour répondre à des questions telles que :
-
- Qui utilise le système ?
- Quels rapports exécutent-ils ?
- Quels sont les délais d'exécution du rapport ?
- Avec l'aide d'autres outils, comme MotioCI, quel contenu est inutilisé ?
Considérant à quel point il est essentiel de maintenir des environnements Cognos Analytics sains, étonnamment, peu de choses ont été écrites sur sa base de données d'audit au-delà de la documentation standard du produit. C'est peut-être tenu pour acquis, mais les organisations qui l'utilisent savent qu'avec le temps, l'interrogation des tables de la base de données d'audit commencera à ralentir, en particulier si votre organisation compte de nombreux utilisateurs exécutant de nombreux rapports et a beaucoup d'historique. De plus, la journalisation de l'activité d'audit elle-même peut être retardée car elle est mise en file d'attente lorsqu'elle ne peut pas être ajoutée à la base de données assez rapidement, par exemple. C'est à ce moment-là que vous commencez à penser aux performances de la base de données comme vous le feriez avec n'importe quelle base de données opérationnelle ayant des exigences de reporting.
Les grandes tables ralentissent généralement les performances des requêtes. Plus la table est grande, plus l'insertion et la requête sont longues. N'oubliez pas que ces tables et la base de données d'audit sont fondamentalement une base de données opérationnelle ; les écritures se produisent fréquemment et jouent contre nous car nous ne pouvons pas les concentrer uniquement sur les opérations de lecture comme vous le feriez avec un data mart.
Tout comme le magasin de contenu, l'intégrité de l'environnement Cognos doit également prendre en compte l'intégrité de la base de données d'audit. La croissance illimitée de la base de données d'audit peut devenir un problème au fil du temps et peut même éventuellement avoir un impact sur les performances globales d'un environnement Cognos. Dans de nombreuses organisations soumises à des réglementations externes, le fait de ne pas disposer d'un dossier d'audit complet peut les placer dans une situation de non-conformité avec de lourdes répercussions. Alors, comment gérer le fait d'avoir à conserver autant de données à des fins d'audit historique (dans certains cas jusqu'à 10 ans) tout en obtenant les rapports dont nous avons besoin pour maintenir l'environnement et garder les utilisateurs satisfaits des performances ?
Le projet
-
- La croissance illimitée de la base de données d'audit a un impact négatif sur la santé de l'environnement Cognos
- Les rapports à partir de la base de données d'audit sont devenus lents ou inutilisables
- Cognos connaît des retards dans l'écriture des enregistrements dans la base de données d'audit
- La base de données d'audit manque d'espace disque
Tout cela signifie que ce ne sont pas seulement les rapports qui reposent sur la base de données d'audit qui souffrent, mais souvent l'ensemble du système. Si la base de données d'audit se trouve sur le même serveur que le magasin de contenu Cognos, les performances de tout ce qui concerne Cognos seront affectées dans cet environnement.
Le programme d'installation
Nous supposons:
-
- Cognos Analytics est installé et en cours d'exécution
- Cognos est configuré pour se connecter à une base de données d'audit
-
- Avoir une base de données d'audit en place
- Définir les niveaux de journalisation d'audit appropriés dans l'administration de Cognos
- Les enregistrements sont en cours d'écriture dans la base de données par Cognos
- La base de données d'audit est utilisée depuis plus d'un an
- L'environnement est très actif avec les utilisateurs et les exécutions
- Le package d'audit est utilisé pour afficher les données d'utilisation de Cognos
- Nous cherchons à améliorer les performances de reporting de la base de données d'audit
- Recommencer ou supprimer d'anciens enregistrements n'est pas toujours une option
Si vous n'avez pas encore installé et configuré Cognos Audit, Lodestar Solutions, un Motio partenaire, a une excellente poster sur l'activation de l'audit dans Cognos BI /CA.
La solution
Il y a quelques solutions possibles qui se présentent rapidement :
-
- Réduisez le volume de données en :
-
- Déplacer certaines des anciennes données vers une autre base de données
- Déplacer certaines des anciennes données vers une autre table de la même base de données
- Il suffit de supprimer ou d'archive certaines données et ne vous en souciez pas
- Vivre avec. Donnez un coup de pied à la canette road et poussez l'administrateur de base de données pour des performances
améliorations tout en les menottant en ne permettant pas les modifications du schéma ou
index
Nous n'allons pas traiter de l'option 3. L'option 2, la suppression des données, n'est pas une bonne option et je recommanderais de garder au moins 18 mois au minimum. Mais, si vous le souhaitez, IBM fournit un utilitaire, AuditDBCleanup (Cognos BI) ou un scénario (Cognos Analytics) qui fera exactement cela. L'utilitaire pour Cognos BI supprime les enregistrements en fonction d'un horodatage tandis que les scripts pour Cognos Analytics suppriment simplement les index et les tables.
Les recommandations que nous avons faites aux clients à ce sujet étaient de séparer en deux bases de données :
-
- Audit – Live : contient la valeur des données de la semaine la plus récente
- Audit – Historique : contient des données historiques (jusqu'à N ans)
En bref, le processus s'exécute chaque semaine pour déplacer les enregistrements les plus récents d'Audit Live vers Audit Historical. Audit Live recommence comme une ardoise vierge après l'exécution de ce processus.
-
- La base de données Live est rapide et précise, permettant des insertions aussi rapides que possible
- Les requêtes d'audit sont exclusivement dirigées vers la base de données historique
En utilisant cette approche, il n'y a pas d'« assemblage » implicite des données en direct et des données historiques. Je dirais que vous voulez probablement que cela reste ainsi.
Dans Cognos Administration, vous pouvez ajouter deux connexions différentes pour la source de données d'audit. Lorsqu'un utilisateur exécute un rapport sur le package d'audit, il est invité à indiquer la connexion qu'il souhaite utiliser :
Si vous souhaitez consulter des données d'audit en direct plutôt que des données d'audit historiques, il vous suffit de sélectionner la connexion « Audit - En direct » lorsque vous y êtes invité (ce devrait être l'exception, pas la norme.)
Si vous souhaitez VRAIMENT également fournir une vue consolidée à la fois en direct et historique, vous pouvez le faire, mais cela aurait un impact sur les performances.
Par exemple, vous pouvez créer une 3e base de données appelée « Audit – Vue consolidée », puis, pour chaque table du schéma d'audit : créer une vue du même nom qui est une union SQL entre la table dans la base de données en direct et la table dans le BD historique. De même, cela pourrait également être réalisé dans le modèle Framework Manager, mais, encore une fois, les performances seraient un facteur clé.
Certains de nos clients ont créé une vue consolidée. À notre avis, c'est probablement exagéré. Les performances seraient toujours pires dans cette vue consolidée et nous n'avons pas rencontré de nombreux cas d'utilisation qui utilisent à la fois les ensembles de données en direct et l'historique. Le Live étant utilisé pour le dépannage et l'Historique pour les rapports de tendance.
Depuis Cognos Analytics 11.1.7, la base de données d'audit est passée à 21 tables. Vous pouvez trouver plus d'informations ailleurs sur la base de données d'audit, des exemples de rapports d'audit et le modèle Framework Manager. Le niveau de journalisation par défaut est Minimal, mais vous souhaiterez peut-être utiliser le niveau suivant, Basic, pour capturer les demandes d'utilisation, la gestion des comptes d'utilisateurs et l'utilisation de l'environnement d'exécution. Une façon de maintenir les performances du système consiste à maintenir le niveau de journalisation au niveau le plus bas requis. De toute évidence, plus la journalisation effectuée par le serveur est importante, plus les performances globales du serveur peuvent être affectées.
Les tables clés qui intéresseront la plupart des administrateurs sont les 6 tables qui enregistrent l'activité de l'utilisateur et l'activité de rapport dans le système.
- COGIPF_USERLOGON : stocke les informations de connexion (y compris la déconnexion) de l'utilisateur
- COGIPF_RUNREPORT : Stocke des informations sur les exécutions de rapports
- COGIPF_VIEWREPORT : Stocke des informations sur les demandes de vue de rapport
- COGIPF_EDITQUERY : Stocke des informations sur les exécutions de requêtes
- COGIPF_RUNJOB : Stocke des informations sur les demandes de travail
- COGIPF_ACTION : Enregistre les actions des utilisateurs dans Cognos (ce tableau peut croître beaucoup plus rapidement que les autres)
La configuration prête à l'emploi ressemble à ceci :
Configuration recommandée :
La base de données d'audit Cognos – Live contient 1 semaine de données d'audit. Les données de plus d'une semaine sont déplacées vers la base de données d'audit Cognos – Historique.
La ligne de la base de données d'audit Cognos – En direct à la base de données d'audit Cognos – Historique dans le diagramme est responsable de :
- Copie des données de Live Audit vers Historical Audit
- Supprimer toutes les lignes du Live Audit datant de plus d'une semaine
- Supprimer toutes les lignes de l'audit historique datant de plus de x ans
- Supprimer toutes les lignes de COGIPF_ACTION qui datent de plus de 6 mois
Index
Différents types de bases de données ont différents types d'indexation. Un index de base de données est une structure de données, associée à une table (ou vue), utilisée pour améliorer le temps d'exécution des requêtes lors de la récupération des données de cette table (ou vue). Travaillez avec votre DBA pour créer la stratégie optimale. Ils voudront connaître les réponses à des questions comme celles-ci pour prendre les meilleures décisions sur les colonnes à indexer. Évidemment, l'administrateur de la base de données pourrait trouver les réponses à certaines ou à toutes ces questions sans votre aide, mais cela demanderait quelques recherches et un certain temps :
- Combien d'enregistrements contiennent les tables et jusqu'à quelle taille pensez-vous qu'elles grandissent ? (L'indexation d'une table ne sera utile que si la table contient un grand nombre d'enregistrements.)
- Savez-vous quelles colonnes sont uniques ? Autorisent-ils les valeurs NULL ? Quelles colonnes ont le type de données entier ou grand entier ? (Les colonnes avec des types de données numériques et qui sont UNIQUE et NON NULL sont de bonnes candidates pour participer à la clé d'index.)
- Où sont vos principaux problèmes de performances aujourd'hui ? Sont-ils en train de récupérer les données ? Existe-t-il des requêtes ou des rapports spécifiques qui posent davantage problème ? (Cela peut conduire l'administrateur de la base de données à certaines colonnes spécifiques qui peuvent être optimisées.)
- Quels champs sont utilisés dans la jointure des tables pour la création de rapports ?
- Quels champs sont utilisés pour filtrer, trier, regrouper et agréger ?
Sans surprise, ce sont les mêmes questions auxquelles il faudrait répondre pour améliorer les performances de toutes les tables de base de données.
Assistance IBM recommande créer un index sur les colonnes « COGIPF_REQUESTID », « COGIPF_SUBREQUESTID » et « COGIPF_STEPID » pour les tables suivantes afin d'améliorer les performances :
- COGIPF_NATIVEQUERY
- COGIPF_RUNJOB
- COGIPF_RUNJOBSTEP
- COGIPF_RUNREPORT
- COGIPF_EDITQUERY
Plus sur d'autres tables moins utilisées :
- COGIPF_POWERPLAY
- COGIPF_HUMANTASKSERVICE
- COGIPF_HUMANTASKSERVICE_DETAIL
Vous pouvez l'utiliser comme point de départ, mais je ferais l'exercice de répondre aux questions ci-dessus pour arriver à la meilleure réponse pour votre organisation.
Autres considérations
- Auditer le modèle FM. N'oubliez pas que le modèle Framework Manager fourni par IBM est modelé sur les tables et les champs par défaut. Toute modification apportée aux tableaux de rapport devra être reflétée dans le modèle. La facilité ou la complexité de ces changements – ou votre compétence organisationnelle pour effectuer ces changements – peut affecter la solution que vous choisissez.
- Champs supplémentaires. Si vous comptez le faire, il est maintenant temps d'ajouter des champs supplémentaires pour le contexte ou les données de référence afin d'améliorer les rapports d'audit.
- Tableaux récapitulatifs. Au lieu de simplement copier les données dans votre tableau historique, compressez-les. Vous pouvez agréger les données au niveau du jour pour les rendre plus efficaces pour la création de rapports.
- Des vues au lieu de tables. D'autres disent : « Ainsi, au lieu d'avoir une base de données 'actuelle' et une base de données 'historique', vous ne devriez avoir qu'une seule base de données, et toutes les tables qu'elle contient devraient être préfixées par 'historique'. Ensuite, vous devez créer un ensemble de vues, une pour chaque table que vous souhaitez voir comme « actuelle », et faire en sorte que chaque vue filtre les lignes historiques que vous ne voulez pas voir et ne laisse passer que les lignes actuelles. »
https://softwareengineering.stackexchange.com/questions/276395/two-database-architecture-operational-and-historical/276419#276419
Conclusion
L'essentiel est qu'avec les informations fournies ici, vous devriez être bien préparé pour avoir une conversation productive avec votre DBA. Il y a de fortes chances qu'elle ait déjà résolu des problèmes similaires.
Les changements proposés dans l'architecture de la base de données d'audit de Cognos amélioreront les performances à la fois des rapports directs et des applications tierces qui en dépendent, comme Motio's ReportCard et Inventaire.
Soit dit en passant, si vous avez eu cette conversation avec votre DBA, nous aimerions en entendre parler. Nous aimerions également savoir si vous avez résolu le problème d'une base de données d'audit peu performante et comment vous l'avez fait.
