En blog af John Boyer og Mike Norris.
Introduktion
Det er vigtigt at have Cognos Auditing -funktionen til at kende og forstå, hvordan Cognos bruges af dit brugerfællesskab og hjælpe med at besvare spørgsmål som:
-
- Hvem bruger systemet?
- Hvilke rapporter kører de?
- Hvad er rapportens kørselstider?
- Ved hjælp af andre værktøjer, f.eks MotioCI, hvilket indhold er ubrugt?
I betragtning af hvor kritisk det er at opretholde sunde Cognos Analytics -miljøer, er der overraskende lidt blevet skrevet om dets revisionsdatabase ud over standard produktdokumentation. Måske er det taget for givet, men organisationer, der bruger det, ved, at over tid vil forespørgsler i Audit Database -tabellerne begynde at bremse - især hvis din organisation har mange brugere, der kører masser af rapporter og har masser af historie. Hvad mere er, at selve loggningsaktivitetsloggen kan blive forsinket, fordi den står i kø, når den f.eks. Ikke hurtigt kan tilføjes til databasen. Det er, når du begynder at tænke på databaseydelse, som du ville med enhver operativ database, der har rapporteringskrav.
Store borde sænker typisk forespørgselsydelsen. Jo større bord, jo længere tid tager det at indsætte og forespørge. Husk, at disse tabeller og revisionsdatabasen grundlæggende er en driftsdatabase; skrivninger sker ofte og virker imod os, da vi ikke kan fokusere dem på kun at læse operationer, som du ville med en datamart.
Ligesom indholdsbutikken skal Cognos -miljøets sundhed også tage højde for sundhedsgraden i revisionsdatabasen. Ubegrænset vækst i revisionsdatabasen kan blive et problem over tid og kan i sidste ende endda påvirke den samlede ydelse af et Cognos -miljø. I mange organisationer med eksterne regler pålagt dem, kan ikke en fuldstændig revisionsprotokol bringe dem i en situation med manglende overholdelse med store konsekvenser. Så hvordan håndterer vi det med at skulle vedligeholde så mange data til historiske revisionsformål - i nogle tilfælde op til 10 år - men alligevel få den rapportering, vi har brug for for at opretholde miljøet og holde brugerne tilfredse med ydelsen?
Udfordringen
-
- Ubegrænset vækst i revisionsdatabasen påvirker sundheden i Cognos -miljøet negativt
- Rapportering fra revisionsdatabasen er blevet langsom eller ubrugelig
- Cognos oplever forsinkelser i registreringer, der skrives til revisionsdatabasen
- Revisionsdatabasen er ved at løbe tør for diskplads
Alt dette betyder, at det ikke kun er de rapporter, der er afhængige af revisionsdatabasen, der lider, men ofte hele systemet. Hvis revisionsdatabasen er på den samme server som Cognos indholdsbutik, påvirkes ydelsen af alle ting Cognos i dette miljø.
Opsætningen
Vi antager:
-
- Cognos Analytics er installeret og kører
- Cognos er konfigureret til at logge på en revisionsdatabase
-
- Hav en revisionsdatabase på plads
- Angiv passende Audit -logningsniveauer i Cognos -administration
- Rekord skrives til databasen af Cognos
- Revisionsdatabasen har været i brug i mere end et år
- Miljøet er meget aktivt med brugere og henrettelser
- Revisionspakken bruges til at vise Cognos -brugsdata
- Vi søger at forbedre rapporteringsresultaterne for revisionsdatabasen
- At starte forfra eller slette gamle poster er ikke altid en mulighed
Hvis du endnu ikke har Cognos Audit installeret og konfigureret, Lodestar Solutions, a Motio partner, har en fremragende indlæg om aktivering af revision i Cognos BI /CA.
Løsningen
Der er nogle mulige løsninger, der hurtigt viser sig:
-
- Reducer datamængden ved at:
-
- Flytning af nogle af de ældre data til en anden database
- Flytning af nogle af de ældre data til en anden tabel i den samme database
- Bare slet eller buehive nogle af dataene og bekymre dig ikke om det
- Lev med det. Spark dåsen ned ad road og skub databaseadministratoren til ydeevne
forbedringer, mens man lægger dem i håndjern ved ikke at tillade ændringer af skemaet eller
indekser
Vi kommer ikke til at beskæftige os med mulighed 3. Mulighed 2, sletning af data, er ikke en god mulighed, og jeg vil anbefale at holde mindst 18 måneders værdi på et minimum. Men hvis du er så tilbøjelig, tilbyder IBM et værktøj, AuditDBCleanup (Cognos BI) eller a script (Cognos Analytics), som vil gøre præcis det. Værktøjet til Cognos BI sletter poster baseret på et tidsstempel, mens scripts til Cognos Analytics bare sletter indekser og tabeller.
De anbefalinger, vi tidligere har givet til klienter om dette, var at opdele i to databaser:
-
- Audit - Live: indeholder den seneste uges data
- Revision - Historisk: indeholder historiske data (op til N år)
Kort sagt, processen kører ugentligt for at flytte de seneste poster fra Audit Live til Audit Historical. Audit Live starter forfra som en tom skifer, efter at denne proces er kørt.
-
- Live DB er hurtig og stram, så indlæg kan ske så hurtigt som muligt
- Revisionsforespørgsler rettes udelukkende til den historiske DB
Ved hjælp af denne fremgangsmåde er der ingen implicit "syning sammen" af Live -dataene og de historiske data. Jeg vil hævde, at du sandsynligvis vil beholde det på den måde.
I Cognos Administration kan du tilføje to forskellige forbindelser til Audit Data Source. Når en bruger kører en rapport mod Audit -pakken, får de besked på, hvilken forbindelse de vil bruge:
Hvis du vil se på live -revisionsdata frem for historiske revisionsdata, vælger du bare forbindelsen "Audit - Live", når du bliver bedt om det (bør være undtagelsen, ikke normen.)
Hvis du VIRKELIG også vil give et konsolideret overblik over både Live og Historical, kan du gøre det, men det vil påvirke ydeevnen.
For eksempel kan du oprette en 3. database kaldet "Audit - konsolideret visning" og derefter for hver tabel i revisionsskemaet: oprette en identisk navngivet visning, der er en SQL -forening mellem tabellen i live -DB og tabellen i historisk DB. På samme måde kunne dette også opnås i Framework Manager -modellen, men igen ville ydelse være en vigtig overvejelse.
Nogle af vores kunder har skabt en konsolideret visning. Det er vores opfattelse, at dette sandsynligvis er overkill. Ydeevnen ville altid være dårligere i denne konsoliderede visning, og vi er ikke stødt på mange brugssager, der bruger både Live datasæt og Historisk. Live bruges til fejlfinding og det historiske til trendrapportering.
Fra og med Cognos Analytics 11.1.7 er revisionsdatabasen vokset til 21 tabeller. Du kan finde flere oplysninger andetsteds på revisionsdatabasen, eksempler på revisionsrapporter og Framework Manager -modellen. Standard logningsniveauet er minimalt, men du vil måske bruge det næste niveau, Basic, til at registrere brugsanmodninger, brugerkontokontrol og brug af runtime. En måde, hvorpå du kan opretholde systemets ydeevne, er ved at holde logningsniveauet til det laveste nødvendige niveau. Jo mere logning der foretages af serveren, jo mere generel serverydelse kan påvirkes.
De vigtigste tabeller, de fleste administratorer vil være interesseret i, er de 6 tabeller, der logger brugeraktivitet og rapporteringsaktivitet i systemet.
- COGIPF_USERLOGON: Gemmer brugerlogon (inklusive log off) oplysninger
- COGIPF_RUNREPORT: Gemmer oplysninger om rapportudførelser
- COGIPF_VIEWREPORT: Gemmer oplysninger om anmodninger om rapportvisning
- COGIPF_EDITQUERY: Gemmer oplysninger om forespørgselskørsler
- COGIPF_RUNJOB: Gemmer oplysninger om jobanmodninger
- COGIPF_ACTION: Registrerer brugerhandlinger i Cognos (denne tabel kan vokse meget hurtigere end de andre)
Out-of-the-box konfigurationen ser sådan ud:
Anbefalet konfiguration:
Cognos Audit Database - Live indeholder 1 uges revisionsdata. Data ældre end 1 uge flyttes til Cognos Audit Database - Historical.
Linjen fra Cognos Audit Database - Live til Cognos Audit Database - Historisk i diagrammet er ansvarlig for:
- Kopiering af data fra Live Audit til Historical Audit
- Fjern alle rækker i Live Audit, der er ældre end 1 uge
- Fjern alle rækker i historisk revision, der er ældre end x år
- Fjern alle rækker i COGIPF_ACTION, der er ældre end 6 måneder
Indexes
Forskellige databasetyper har forskellige indekseringstyper. Et databaseindeks er en datastruktur, der er knyttet til en tabel (eller visning), der bruges til at forbedre forespørgselsudførelsestiden, når dataene hentes fra den pågældende tabel (eller visning). Arbejd med din DBA for at skabe den optimale strategi. De vil gerne vide svarene på spørgsmål som disse for at træffe de bedste beslutninger om, hvilke kolonner der skal indekseres. Det er klart, at databaseadministratoren kunne finde svarene på nogle eller alle disse spørgsmål uden din hjælp, men det ville tage lidt research og lidt tid:
- Hvor mange poster har tabellerne, og til hvilken størrelse forventer du, at de vokser? (Indeksering af en tabel vil ikke være nyttig, medmindre tabellen har et stort antal poster.)
- Ved du, hvilke kolonner der er unikke? Tillader de NULL -værdier? Hvilke kolonner har datatype heltal eller stort heltal? (Kolonnerne med numeriske datatyper, og som er UNIKE og IKKE NULL, er stærke kandidater til at deltage i indeksnøglen.)
- Hvor er dine vigtigste ydelsesproblemer i dag? Er de ved at hente dataene? Er der specifikke forespørgsler eller rapporter, der mere er et problem? (Dette kan føre databaseadministratoren til nogle bestemte kolonner, der kan optimeres.)
- Hvilke felter bruges til sammenføjning af tabeller til rapportering?
- Hvilke felter bruges til filtrering, sortering, gruppering og aggregering?
Ikke overraskende er det de samme spørgsmål, der skal besvares for at forbedre ydelsen af databasetabeller.
IBM Support anbefaler oprettelse af et indeks på kolonnerne "COGIPF_REQUESTID", "COGIPF_SUBREQUESTID" og "COGIPF_STEPID" for følgende tabeller for at forbedre ydeevnen:
- COGIPF_NATIVEQUERY
- COGIPF_RUNJOB
- COGIPF_RUNJOBSTEP
- COGIPF_RUNREPORT
- COGIPF_EDITQUERY
Plus på andre mindre brugte borde:
- COGIPF_POWERPLAY
- COGIPF_HUMANTASKSERVICE
- COGIPF_HUMANTASKSERVICE_DETAIL
Du kan bruge dette som udgangspunkt, men jeg ville gennemgå øvelsen med at besvare ovenstående spørgsmål for at nå frem til det bedste svar for din organisation.
andre overvejelser
- Revider FM -model. Husk, at den Framework Manager -model, som IBM leverer, er modelleret på standardtabellerne og -felterne. Eventuelle ændringer, du foretager i rapporteringstabellerne, skal afspejles i modellen. Lettelsen eller kompleksiteten af disse ændringer - eller din organisatoriske kompetence til at foretage disse ændringer - kan påvirke den løsning, du vælger.
- Yderligere felter. Hvis du vil gøre det, er det nu tid til at tilføje flere felter til kontekst- eller referencedata for at forbedre revisionsrapporteringen.
- Oversigtstabeller. Komprimer dem i stedet for bare at kopiere dataene til din historiske tabel. Du kan samle dataene til dagsniveau for at gøre det mere effektivt til rapportering.
- Visninger i stedet for tabeller. Andre siger: “Så i stedet for at have en 'aktuel' database og en 'historisk' database skal du kun have én database, og alle tabeller i den skal have et præfiks med 'historisk'. Derefter skal du oprette et sæt visninger, en for hver tabel, som du vil se som 'aktuel', og få hver visning til at filtrere de historiske rækker, som du ikke vil se, og kun lade de nuværende passere igennem. ”
https://softwareengineering.stackexchange.com/questions/276395/two-database-architecture-operational-and-historical/276419#276419
Konklusion
Konklusionen er, at med oplysningerne her skal du være godt forberedt på at have en produktiv samtale med din DBA. Chancerne er gode for, at hun har løst lignende problemer før.
De foreslåede ændringer i Cognos Audit Database-arkitektur vil forbedre ydeevnen i både direkte rapportering og tredjepartsapplikationer, der er afhængige af det, som f.eks. Motio's ReportCard og beholdning.
Forresten, hvis du har haft den samtale med din DBA, vil vi meget gerne høre om det. Vi vil også meget gerne høre, om du har løst problemet med en dårligt fungerende revisionsdatabase, og hvordan du gjorde det.
