Blog di Cognos Auditing – Suggerimenti e trucchi per ambienti di grandi e grandi volumi

Un blog di John Boyer e Mike Norris.

Introduzione

È importante che la funzionalità di Cognos Auditing funzioni per sapere e comprendere come Cognos viene utilizzato dalla comunità di utenti e aiutare a rispondere a domande come:

• • Chi sta usando il sistema?
  • Quali rapporti stanno eseguendo?
  • Quali sono i tempi di esecuzione del rapporto?
  • Con l'aiuto di altri strumenti, come MotioCI, quali contenuti sono inutilizzati?

Considerando quanto sia fondamentale mantenere sani gli ambienti Cognos Analytics, sorprendentemente poco è stato scritto sul suo database di controllo oltre alla documentazione standard del prodotto. Forse è dato per scontato, ma le organizzazioni che lo utilizzano sanno che nel tempo l'interrogazione delle tabelle del database di audit inizierà a rallentare, soprattutto se la propria organizzazione ha molti utenti che eseguono molti report e ha molta cronologia. Inoltre, la registrazione dell'attività di controllo stessa può essere ritardata perché viene messa in coda quando non può essere aggiunta al database abbastanza rapidamente, ad esempio. È allora che inizi a pensare alle prestazioni del database come faresti con qualsiasi database operativo che abbia requisiti di reporting.

Le tabelle di grandi dimensioni in genere rallentano le prestazioni delle query. Più grande è la tabella, più tempo sarà necessario per l'inserimento e l'interrogazione. Si ricorda che queste tabelle e l'Audit Database sono sostanzialmente un database operativo; le scritture si verificano frequentemente e funzionano contro di noi poiché non possiamo focalizzarle solo sulle operazioni di lettura come faresti con un data mart.

Proprio come l'archivio dei contenuti, anche l'integrità dell'ambiente Cognos deve tenere conto dell'integrità del database di controllo. La crescita illimitata dell'Audit Database può diventare un problema nel tempo e potrebbe persino avere un impatto sulle prestazioni complessive di un ambiente Cognos. In molte organizzazioni soggette a normative esterne, la mancanza di un record di audit completo può comportare una situazione di non conformità con pesanti ripercussioni. Quindi, come affrontiamo la necessità di conservare così tanti dati per scopi di auditing cronologico, in alcuni casi fino a 10 anni, ma otteniamo comunque i report di cui abbiamo bisogno per mantenere l'ambiente e mantenere gli utenti soddisfatti delle prestazioni?

La sfida

• • La crescita illimitata dell'Audit Database ha un impatto negativo sulla salute dell'ambiente Cognos
  • La segnalazione al di fuori del database di audit è diventata lenta o inutilizzabile
  • Cognos subisce ritardi nella scrittura dei record nel database di audit
  • Il database di audit sta esaurendo lo spazio su disco

Tutto ciò significa che a soffrirne non sono solo le segnalazioni che si basano sull'Audit Database, ma spesso l'intero sistema. Se Audit Database si trova sullo stesso server del Content Store Cognos, le prestazioni di tutte le cose Cognos saranno influenzate in quell'ambiente.

Il programma di installazione

Assumiamo:

1. 1. Cognos Analytics è installato e funzionante
   2. Cognos è configurato per accedere a un database di audit
   1. • Avere un database di audit in atto
      • Impostare livelli di registrazione di controllo appropriati nell'amministrazione di Cognos
      • Il record viene scritto nel database da Cognos
   3. L'Audit Database è in uso da più di un anno
   4. L'ambiente è molto attivo con utenti ed esecuzioni
   5. Il pacchetto Audit viene utilizzato per far emergere i dati sull'utilizzo di Cognos
   6. Stiamo cercando di migliorare le prestazioni di reporting del database di audit
   7. Ricominciare o eliminare i vecchi record non è sempre un'opzione

Se non hai ancora installato e configurato Cognos Audit, Lodestar Solutions, a Motio partner, ha un eccellente settimana sull'abilitazione di Audit in Cognos BI /CA.

La Soluzione

Ci sono alcune possibili soluzioni che si presentano rapidamente:

1. 1. Riduci il volume dei dati:
   1. • Spostare alcuni dei dati più vecchi in un altro database
      • Spostare alcuni dei dati più vecchi in un'altra tabella nello stesso database
   2. Basta cancellare o archive alcuni dei dati e non preoccuparti
   3. Convivici. Butta giù il barattolo road e spingere l'amministratore del database per le prestazioni
      miglioramenti mentre li ammanettano non consentendo alterazioni dello schema o
      indici

Non ci occuperemo dell'opzione 3. L'opzione 2, l'eliminazione dei dati, non è una buona opzione e consiglierei di mantenere un valore minimo di almeno 18 mesi. Ma, se sei così incline, IBM fornisce un'utilità, AuditDBCleanup (Cognos BI) o a copione (Cognos Analytics) che farà esattamente questo. L'utilità per Cognos BI elimina i record in base a un timestamp, mentre gli script per Cognos Analytics eliminano semplicemente gli indici e le tabelle.

Le raccomandazioni che abbiamo fatto ai clienti in precedenza su questo erano di separare in due database:

1. 1. Audit – Live: contiene i dati della settimana più recente
   2. Audit – Storico: contiene dati storici (fino a N anni)

In breve, il processo viene eseguito settimanalmente per spostare i record più recenti da Audit Live a Audit Historical. Audit Live ricomincia come una lavagna vuota dopo l'esecuzione di questo processo.

1. 1. Il Live DB è veloce e stretto, consentendo agli inserti di avvenire il più velocemente possibile
   2. Le interrogazioni di audit sono dirette esclusivamente al DB Storico

Utilizzando questo approccio, non c'è una "cucitura insieme" implicita dei dati Live e dei dati Storici. Direi che probabilmente vorrai mantenerlo così.

In Cognos Administration è possibile aggiungere due diverse connessioni per Audit Data Source. Quando un utente esegue un report sul pacchetto Audit, gli viene chiesto quale connessione vuole usare:

Nel caso in cui desideri esaminare i dati di audit in tempo reale anziché i dati di audit storici, scegli semplicemente la connessione "Audit - Live" quando richiesto (dovrebbe essere l'eccezione, non la norma).

Se vuoi DAVVERO anche fornire una visione consolidata sia di Live che di Storico, puoi farlo, ma influirebbe sulle prestazioni.

Ad esempio, potresti creare un 3° Database chiamato “Audit – Consolidated View” e quindi, per ogni tabella nello schema Audit: creare una vista con lo stesso nome che sia un'unione SQL tra la tabella nel DB live e la tabella nello storico DB. Allo stesso modo, questo potrebbe essere ottenuto anche nel modello Framework Manager, ma, ancora una volta, le prestazioni sarebbero una considerazione chiave.

Alcuni dei nostri clienti hanno creato una visione consolidata. È nostra opinione che questo sia probabilmente eccessivo. Le prestazioni sarebbero sempre peggiori in questa visualizzazione consolidata e non abbiamo riscontrato molti casi d'uso che utilizzano sia i set di dati live che lo storico. Il Live viene utilizzato per la risoluzione dei problemi e lo Storico per i rapporti sui trend.

A partire da Cognos Analytics 11.1.7, l'Audit Database è cresciuto fino a 21 tabelle. È possibile trovare ulteriori informazioni altrove su Audit Database, report di audit di esempio e modello Framework Manager. Il livello di registrazione predefinito è Minimo, ma potresti voler utilizzare il livello successivo, Base, per acquisire le richieste di utilizzo, la gestione dell'account utente e l'utilizzo del runtime. Un modo per mantenere le prestazioni del sistema è mantenere il livello di registrazione al livello minimo richiesto. Ovviamente, più registrazione viene eseguita dal server, più le prestazioni complessive del server possono essere influenzate.

Le tabelle chiave che interessano alla maggior parte degli amministratori sono le 6 tabelle che registrano l'attività dell'utente e l'attività di reporting nel sistema.

• COGIPF_USERLOGON: memorizza le informazioni di accesso dell'utente (inclusa la disconnessione)
• COGIPF_RUNREPORT: memorizza le informazioni sull'esecuzione dei report
• COGIPF_VIEWREPORT: Memorizza le informazioni sulle richieste di visualizzazione dei rapporti
• COGIPF_EDITQUERY: memorizza le informazioni sulle esecuzioni delle query
• COGIPF_RUNJOB: Memorizza le informazioni sulle richieste di lavoro
• COGIPF_ACTION: registra le azioni dell'utente in Cognos (questa tabella può crescere molto più rapidamente delle altre)

La configurazione predefinita è simile a questa:

Configurazione consigliata:

Il database Cognos Audit – Live contiene 1 settimana di dati di audit. I dati più vecchi di 1 settimana vengono spostati nel database Cognos Audit – Storico.

La riga da Cognos Audit Database – Live a Cognos Audit Database – Historical nel diagramma è responsabile di:

• Copia dei dati da Live Audit a Historical Audit
• Rimuovi tutte le righe nel Live Audit che sono più vecchie di 1 settimana
• Rimuovi tutte le righe in Audit storico che sono più vecchie di x anni
• Rimuovi tutte le righe in COGIPF_ACTION più vecchie di 6 mesi

Indici

Diversi tipi di database hanno diversi tipi di indicizzazione. Un indice di database è una struttura di dati, associata a una tabella (o vista), utilizzata per migliorare il tempo di esecuzione delle query durante il recupero dei dati da quella tabella (o vista). Collabora con il tuo DBA per creare la strategia ottimale. Vorranno conoscere le risposte a domande come queste per prendere le decisioni migliori su quali colonne indicizzare. Ovviamente, l'amministratore del database potrebbe trovare le risposte ad alcune o tutte queste domande senza il tuo aiuto, ma ci vorrebbe un po' di ricerca e un po' di tempo:

• Quanti record hanno le tabelle e fino a che dimensione prevedi che crescano? (L'indicizzazione di una tabella non sarà utile a meno che la tabella non abbia un numero elevato di record.)
• Sai quali colonne sono uniche? Consentono valori NULL? Quali colonne hanno il tipo di dati intero o grande intero? (Le colonne con tipi di dati numerici e che sono UNIQUE e NOT NULL sono candidati validi per partecipare alla chiave dell'indice.)
• Dove sono i tuoi principali problemi di prestazioni oggi? Stanno recuperando i dati? Esistono query o rapporti specifici che rappresentano più un problema? (Ciò può portare l'amministratore del database ad alcune colonne specifiche che possono essere ottimizzate.)
• Quali campi vengono utilizzati nell'unione delle tabelle per i rapporti?
• Quali campi vengono utilizzati per filtrare, ordinare, raggruppare e aggregare?

Non sorprende che queste siano le stesse domande a cui è necessario rispondere per migliorare le prestazioni di qualsiasi tabella di database.

Supporto IBM raccomanda creando un indice sulle colonne "COGIPF_REQUESTID", "COGIPF_SUBREQUESTID" e "COGIPF_STEPID" per le seguenti tabelle per migliorare le prestazioni:

• COGIPF_NATIVEQUERY
• COGIPF_RUNJOB
• COGIPF_RUNJOBSTEP
• COGIPF_RUNREPORT
• COGIPF_EDITQUERY

In più su altre tabelle meno utilizzate:

• COGIPF_POWERPLAY
• SERVIZIO COGIPF_HUMANTASK
• COGIPF_HUMANTASKSERVICE_DETAIL

Puoi usare questo come punto di partenza, ma vorrei passare attraverso l'esercizio di rispondere alle domande sopra per arrivare alla risposta migliore per la tua organizzazione.

altre considerazioni

1. Verifica il modello FM. Ricorda che il modello Framework Manager fornito da IBM è modellato sulle tabelle e sui campi predefiniti. Eventuali modifiche apportate alle tabelle dei rapporti dovranno essere riflesse nel modello. La facilità o la complessità di queste modifiche, o la tua competenza organizzativa per apportare queste modifiche, può influire sulla soluzione scelta.
2. Campi aggiuntivi. Se hai intenzione di farlo, ora è il momento di aggiungere ulteriori campi per dati di contesto o di riferimento per migliorare i rapporti di controllo.
3. Tabelle riassuntive. Invece di copiare semplicemente i dati nella tabella storica, comprimili. Puoi aggregare i dati a livello di giorno per renderlo più efficiente per i rapporti.
4. Viste invece di tabelle. Altri dicono: “Quindi, invece di avere un database 'corrente' e un database 'storico', dovresti avere solo un database e tutte le tabelle in esso dovrebbero avere il prefisso 'storico'. Quindi, dovresti creare una serie di viste, una per ogni tabella che vuoi vedere come 'corrente', e fare in modo che ogni vista filtri le righe storiche che non vuoi vedere e lasci passare solo quelle attuali.
   https://softwareengineering.stackexchange.com/questions/276395/two-database-architecture-operational-and-historical/276419#276419

Conclusione

La linea di fondo è che con le informazioni fornite qui dovresti essere ben preparato per avere una conversazione produttiva con il tuo DBA. È probabile che abbia già risolto problemi simili in passato.

Le modifiche proposte nell'architettura del database di Cognos Audit miglioreranno le prestazioni sia nel reporting diretto che nelle applicazioni di terze parti che si basano su di esso, come Motio'S ReportCard e Inventario.

A proposito, se hai avuto quella conversazione con il tuo DBA, ci piacerebbe sentirne parlare. Ci piacerebbe anche sapere se hai risolto il problema di un database di audit con prestazioni scadenti e come lo hai fatto.