Cognos revisionsblogg - Tips och tricks för stora och höga volymer

En blogg av John Boyer och Mike Norris.

Beskrivning

Det är viktigt att Cognos Auditing -funktionen fungerar för att veta och förstå hur Cognos används av din användargrupp och hjälpa till att svara på frågor som:

• • Vem använder systemet?
  • Vilka rapporter kör de?
  • Vilka är rapportens körtider?
  • Med hjälp av andra verktyg, t.ex. MotioCI, vilket innehåll är oanvänt?

Med tanke på hur viktigt det är att upprätthålla hälsosamma Cognos Analytics -miljöer har överraskande lite skrivits om sin revisionsdatabas utöver standardproduktdokumentationen. Kanske är det givet för givet, men organisationer som använder det vet att efterfrågan på granskningsdatabastabellerna kommer att börja sakta ner - särskilt om din organisation har många användare som kör massor av rapporter och har mycket historik. Vad mer är att själva loggningsloggen kan bli försenad eftersom den står i kö när den inte kan läggas till databasen tillräckligt snabbt, till exempel. Det är då du börjar tänka på databasprestanda som du skulle göra med alla operativa databaser som har rapporteringskrav.

Stora tabeller saktar vanligtvis efterfrågeprestanda. Ju större tabell, desto längre tid tar det att infoga och fråga. Kom ihåg att dessa tabeller och granskningsdatabasen i grunden är en operativ databas; skrivningar händer ofta och arbetar mot oss eftersom vi inte kan fokusera dem för enbart läsoperationer som du skulle göra med en data -mart.

Precis som innehållsbutiken måste Cognos -miljöens hälsa också ta hänsyn till hälsan hos granskningsdatabasen. Obegränsad tillväxt av granskningsdatabasen kan bli ett problem med tiden och kan så småningom även påverka den totala prestandan i en Cognos -miljö. I många organisationer med externa föreskrifter som tvingas till dem, kan de inte hamna i en fullständig revisionsprotokoll i en bristande efterlevnadssituation med stora konsekvenser. Så hur ska vi hantera att behöva behålla så mycket data för historiska granskningsändamål - i vissa fall upp till 10 år - men ändå få den rapportering vi behöver för att behålla miljön och hålla användarna nöjda med prestanda?

Utmaningen

• • Obegränsad tillväxt av granskningsdatabasen påverkar hälsan i Cognos -miljön negativt
  • Rapportering av granskningsdatabasen har blivit långsam eller oanvändbar
  • Cognos upplever förseningar i registreringar som skrivs till granskningsdatabasen
  • Revisionsdatabasen tar slut på diskutrymme

Allt detta betyder att det inte bara är rapporterna som är beroende av granskningsdatabasen, utan ofta hela systemet. Om granskningsdatabasen finns på samma server som Cognos innehållslager påverkas prestandan för alla saker Cognos i den miljön.

Setup

Vi antar:

1. 1. Cognos Analytics är installerat och körs
   2. Cognos är konfigurerad för att logga till en granskningsdatabas
   1. • Ha en granskningsdatabas på plats
      • Ställ in lämpliga nivåer för granskningsloggning i Cognos -administration
      • Posten skrivs till databasen av Cognos
   3. Revisionsdatabasen har använts i mer än ett år
   4. Miljön är mycket aktiv med användare och avrättningar
   5. Granskningspaketet används för att visa användningsdata för Cognos
   6. Vi försöker förbättra rapporteringsprestanda för granskningsdatabaser
   7. Att börja om eller ta bort gamla poster är inte alltid ett alternativ

Om du ännu inte har installerat och konfigurerat Cognos Audit, Lodestar Solutions, a Motio partner, har en utmärkt inlägg om aktivering av granskning i Cognos BI /CA.

Lösningen

Det finns några möjliga lösningar som snabbt presenterar sig:

1. 1. Minska datamängden med:
   1. • Flytta några av de äldre data till en annan databas
      • Flytta några av de äldre data till en annan tabell i samma databas
   2. Bara ta bort eller bågehive några av uppgifterna och oroa dig inte för det
   3. Lev med det. Sparka ner burken road och pressa databasadministratören för prestanda
      förbättringar samtidigt som de handfängs genom att inte tillåta ändringar av schemat eller
      index

Vi kommer inte att behandla alternativ 3. Alternativ 2, radering av data, är inte ett bra alternativ och jag skulle rekommendera att hålla minst 18 månaders värde minst. Men om du är så benägen erbjuder IBM ett verktyg, AuditDBcleanup (Cognos BI) eller a skript (Cognos Analytics) som kommer att göra exakt det. Verktyget för Cognos BI raderar poster baserat på en tidsstämpel medan skripten för Cognos Analytics bara tar bort index och tabeller.

Rekommendationerna vi tidigare har gjort till klienter om detta var att dela upp i två databaser:

1. 1. Audit - Live: innehåller senaste veckans data
   2. Revision - Historisk: innehåller historisk data (upp till N år)

Kort sagt, processen körs varje vecka för att flytta de senaste posterna från Audit Live till Audit Historical. Audit Live börjar om som en tom skiffer efter att denna process har körts.

1. 1. Live DB är snabb och tät, så att skär kan ske så snabbt som möjligt
   2. Granskningsfrågor riktas uteslutande till den historiska databasen

Med detta tillvägagångssätt finns det ingen implicit "sammanfogning" av levande data och historiska data. Jag skulle hävda att du förmodligen vill behålla det så.

I Cognos Administration kan du lägga till två olika anslutningar för granskningsdatakällan. När en användare kör en rapport mot granskningspaketet får de en fråga om vilken anslutning de vill använda:

Om du vill titta på levande revisionsdata snarare än historiska granskningsdata väljer du bara anslutningen "Audit - Live" när du uppmanas (bör vara undantaget, inte normen.)

Om du verkligen också vill ge en konsoliderad bild av både Live och Historical kan du göra det, men det skulle påverka prestanda.

Du kan till exempel skapa en tredje databas med namnet “Audit - Consolidated View” och sedan för varje tabell i revisionsschemat: skapa en identiskt namngiven vy som är en SQL -union mellan tabellen i live -DB och tabellen i historiska DB. På samma sätt kan detta också uppnås i Framework Manager -modellen, men återigen skulle prestanda vara en viktig faktor.

Några av våra kunder har skapat en konsoliderad vy. Det är vår uppfattning att detta troligen är överkill. Prestanda skulle alltid vara sämre i denna konsoliderade uppfattning och vi har inte stött på många användningsfall som använder både levande datamängder och historiska. Live används för felsökning och det historiska för trendrapportering.

Från och med Cognos Analytics 11.1.7 har granskningsdatabasen vuxit till 21 tabeller. Du kan hitta mer information någon annanstans i granskningsdatabasen, exempelrevisionsrapporter och Framework Manager -modellen. Standardloggningsnivån är Minimal, men du kanske vill använda nästa nivå, Basic, för att fånga användningsförfrågningar, användarkontohantering och körningstid. Ett sätt att behålla systemets prestanda är genom att hålla loggningsnivån till den lägsta nivå som krävs. Uppenbarligen, ju mer loggning som görs av servern, desto mer övergripande serverprestanda kan påverkas.

De viktigaste tabellerna som de flesta administratörer kommer att vara intresserade av är de 6 tabeller som loggar användaraktivitet och rapporteringsaktivitet i systemet.

• COGIPF_USERLOGON: Lagrar användarinloggningsinformation (inklusive avloggning)
• COGIPF_RUNREPORT: Lagrar information om rapportkörningar
• COGIPF_VIEWREPORT: Lagrar information om rapportvyförfrågningar
• COGIPF_EDITQUERY: Lagrar information om frågekörningar
• COGIPF_RUNJOB: Lagrar information om jobbförfrågningar
• COGIPF_ACTION: Registrerar användaråtgärder i Cognos (den här tabellen kan växa mycket snabbare än de andra)

Out-of-the-box-konfigurationen ser ut så här:

Rekommenderad konfiguration:

Cognos Audit Database - Live innehåller 1 veckas granskningsdata. Data äldre än 1 vecka flyttas till Cognos Audit Database - Historical.

Linjen från Cognos Audit Database - Live till Cognos Audit Database - Historisk i diagrammet är ansvarig för:

• Kopiera data från Live Audit till Historical Audit
• Ta bort alla rader i Live Audit som är äldre än 1 vecka
• Ta bort alla rader i Historical Audit som är äldre än x år
• Ta bort alla rader i COGIPF_ACTION som är äldre än 6 månader

Index

Olika databastyper har olika indexeringstyper. Ett databasindex är en datastruktur som är associerad med en tabell (eller vy), som används för att förbättra frågekörningstiden när data hämtas från den tabellen (eller vyn). Arbeta med din DBA för att skapa den optimala strategin. De kommer att vilja veta svaren på frågor som dessa för att fatta de bästa besluten om vilka kolumner som ska indexeras. Uppenbarligen kan databasadministratören ta reda på svaren på några eller alla dessa frågor utan din hjälp, men det skulle ta lite forskning och lite tid:

• Hur många poster har tabellerna och till vilken storlek tror du att de ska växa? (Att indexera en tabell är inte användbart om inte tabellen har ett stort antal poster.)
• Vet du vilka kolumner som är unika? Tillåter de NULL -värden? Vilka kolumner har datatyp av heltal eller stort heltal? (Kolumnerna med numeriska datatyper och som är UNIKA och INTE NULL är starka kandidater för att delta i indexnyckeln.)
• Var är dina huvudsakliga prestandaproblem idag? Är de på att hämta data? Finns det specifika frågor eller rapporter som är mer ett problem? (Detta kan leda databasadministratören till vissa specifika kolumner som kan optimeras.)
• Vilka fält används för att sammanfoga tabeller för rapportering?
• Vilka fält används för filtrering, sortering, gruppering och aggregering?

Inte överraskande är det samma frågor som måste besvaras för att förbättra prestanda för alla databastabeller.

IBM Support rekommenderar skapa ett index på kolumnerna "COGIPF_REQUESTID", "COGIPF_SUBREQUESTID" och "COGIPF_STEPID" för följande tabeller för att förbättra prestanda:

• COGIPF_NATIVEQUERY
• COGIPF_RUNJOB
• COGIPF_RUNJOBSTEP
• COGIPF_RUNREPORT
• COGIPF_EDITQUERY

Plus på andra mindre använda bord:

• COGIPF_POWERPLAY
• COGIPF_HUMANTASKSERVICE
• COGIPF_HUMANTASKSERVICE_DETAIL

Du kan använda detta som utgångspunkt, men jag skulle gå igenom övningen att svara på frågorna ovan för att komma fram till det bästa svaret för din organisation.

andra överväganden

1. Granska FM -modell. Kom ihåg att den Framework Manager -modell som IBM tillhandahåller är modellerad på standardtabellerna och -fälten. Alla ändringar du gör i rapporteringstabellerna måste återspeglas i modellen. Lätt eller komplex med dessa förändringar - eller din organisatoriska kompetens att göra dessa förändringar - kan påverka den lösning du väljer.
2. Ytterligare fält. Om du ska göra det är det dags att lägga till ytterligare fält för sammanhang eller referensdata för att förbättra revisionsrapporteringen.
3. Sammanfattningstabeller. Istället för att bara kopiera data till din historiska tabell, komprimera den. Du kan samla in data till dagsnivå för att göra den mer effektiv för rapportering.
4. Vyer istället för tabeller. Andra säger: ”Så, istället för att ha en” aktuell ”databas och en” historisk ”databas, bör du bara ha en databas och alla tabeller i den bör ha prefix med” historisk ”. Därefter bör du skapa en uppsättning vyer, en för varje tabell som du vill se som "aktuell", och få varje vy att filtrera bort de historiska raderna som du inte vill se och låta bara de aktuella passera igenom. "
   https://softwareengineering.stackexchange.com/questions/276395/two-database-architecture-operational-and-historical/276419#276419

Slutsats

Slutsatsen är att med informationen här bör du vara väl förberedd för att ha en produktiv konversation med din DBA. Chansen är stor att hon har löst liknande problem tidigare.

De föreslagna ändringarna i Cognos Audit Database-arkitektur kommer att förbättra prestanda i både direktrapportering och tredjepartsapplikationer som är beroende av den, t.ex. MotioÄr ReportCard och inventering.

Förresten, om du har haft det samtalet med din DBA, skulle vi gärna höra om det. Vi vill också gärna höra om du har löst problemet med en dåligt fungerande granskningsdatabas och hur du gjorde det.