En blogg av John Boyer og Mike Norris.
Introduksjon
Det er viktig at Cognos Auditing -funksjonen fungerer for å vite og forstå hvordan Cognos brukes av brukermiljøet ditt og hjelpe deg med å svare på spørsmål som:
-
- Hvem bruker systemet?
- Hvilke rapporter kjører de?
- Hva er rapportens kjøringstid?
- Ved hjelp av andre verktøy, som MotioCI, hvilket innhold er ubrukt?
Med tanke på hvor kritisk det er å opprettholde sunne Cognos Analytics -miljøer, er det overraskende lite skrevet om revisjonsdatabasen utover standard produktdokumentasjon. Kanskje det er en selvfølge, men organisasjoner som bruker det, vet at det med tiden vil begynne å avspørre tabellene for revisjonsdatabaser - spesielt hvis organisasjonen din har mange brukere som kjører mange rapporter og har mye historie. Hva mer er at selve loggføringsloggingen kan bli forsinket fordi den står i kø når den ikke kan legges til databasen raskt nok, for eksempel. Det er da du begynner å tenke på databaseytelse som du ville gjort med en hvilken som helst operasjonsdatabase som har rapporteringskrav.
Store bord reduserer vanligvis ytelsen til spørringen. Jo større tabellen er, desto lengre tid tar det å sette inn og spørre. Husk at disse tabellene og revisjonsdatabasen i utgangspunktet er en operativ database; skriver skjer ofte og virker mot oss, ettersom vi ikke kan fokusere dem på bare leseoperasjoner som du ville gjort med en datakart.
I likhet med innholdsbutikken må helsen til Cognos -miljøet også ta hensyn til helsen til revisjonsdatabasen. Ubegrenset vekst av revisjonsdatabasen kan bli et problem over tid og kan til slutt til og med påvirke den generelle ytelsen til et Cognos -miljø. I mange organisasjoner med eksterne forskrifter som pålegges dem, kan det at de ikke har en fullstendig revisjonsjournal, lander dem i en situasjon som ikke er i samsvar med store konsekvenser. Så hvordan håndterer vi å beholde så mye data for historiske revisjonsformål - i noen tilfeller opptil 10 år - men likevel få den rapporteringen vi trenger for å opprettholde miljøet og holde brukerne fornøyde med ytelsen?
Challenge
-
- Ubegrenset vekst av revisjonsdatabasen påvirker helsen til Cognos -miljøet negativt
- Å rapportere fra revisjonsdatabasen har blitt treg eller ubrukelig
- Cognos opplever forsinkelser i registreringer som skrives til revisjonsdatabasen
- Revisjonsdatabasen er tom for diskplass
Alt dette betyr at det ikke bare er rapportene som er avhengige av revisjonsdatabasen, men ofte hele systemet. Hvis revisjonsdatabasen er på samme server som Cognos innholdsbutikk, vil ytelsen til alle ting Cognos påvirkes i det miljøet.
Oppsettet
Vi antar:
-
- Cognos Analytics er installert og kjører
- Cognos er konfigurert til å logge på en revisjonsdatabase
-
- Ha en revisjonsdatabase på plass
- Angi passende nivåer for revisjonslogging i Cognos -administrasjon
- Rekord skrives til databasen av Cognos
- Revisjonsdatabasen har vært i bruk i mer enn et år
- Miljøet er veldig aktivt med brukere og henrettelser
- Audit -pakken brukes til å vise Cognos -bruksdata
- Vi ønsker å forbedre rapporteringsytelsen for revisjonsdatabasen
- Å starte på nytt eller slette gamle poster er ikke alltid et alternativ
Hvis du ikke har Cognos Audit installert og konfigurert, Lodestar Solutions, a Motio partner, har en utmerket poste om aktivering av revisjon i Cognos BI /CA.
The Solution
Det er noen mulige løsninger som raskt presenterer seg:
-
- Reduser datamengden med:
-
- Flytte noen av de eldre dataene til en annen database
- Flytter noen av de eldre dataene til en annen tabell i samme database
- Bare slett eller buhive noen av dataene, og ikke bekymre deg for det
- Lev med det. Spark boksen nedover road og skyv databaseadministratoren for ytelse
forbedringer mens du legger dem i håndjern ved å ikke tillate endringer av skjemaet eller
indekser
Vi kommer ikke til å behandle alternativ 3. Alternativ 2, sletting av data, er ikke et godt alternativ, og jeg vil anbefale å beholde minst 18 måneders verdi. Men hvis du er så tilbøyelig, tilbyr IBM et verktøy, AuditDBCleanup (Cognos BI) eller a script (Cognos Analytics) som vil gjøre akkurat det. Verktøyet for Cognos BI sletter poster basert på et tidsstempel mens skriptene for Cognos Analytics bare sletter indeksene og tabellene.
Anbefalingene vi tidligere har gitt til klienter om dette, var å dele inn i to databaser:
-
- Audit - Live: inneholder siste ukes verdi for data
- Revisjon - Historisk: inneholder historiske data (opptil N år)
Kort sagt, prosessen går ukentlig for å flytte de siste postene fra Audit Live til Audit Historical. Audit Live starter på nytt som en tom skifer etter at denne prosessen har kjørt.
-
- Live DB er rask og stram, slik at innlegg kan skje så raskt som mulig
- Revisjonsspørsmål er utelukkende rettet til Historical DB
Ved å bruke denne tilnærmingen er det ingen implisitt "å sy sammen" av Live -dataene og de historiske dataene. Jeg vil påstå at du sannsynligvis vil beholde det slik.
I Cognos Administration kan du legge til to forskjellige tilkoblinger for revisjonskilden. Når en bruker kjører en rapport mot revisjonspakken, får de spørsmål om hvilken tilkobling de vil bruke:
Hvis du vil se på live -revisjonsdata i stedet for historiske revisjonsdata, velger du bare "Audit - Live" -forbindelsen når du blir bedt om det (bør være unntaket, ikke normen.)
Hvis du VIRKELIG også vil gi et konsolidert syn på både Live og Historical, kan du gjøre det, men det vil påvirke ytelsen.
For eksempel kan du opprette en tredje database som heter “Audit - Consolidated View”, og deretter, for hver tabell i revisjonsskjemaet: Lag en identisk navngitt visning som er en SQL -forening mellom tabellen i live -DB og tabellen i historisk DB. På samme måte kan dette også oppnås i Framework Manager -modellen, men igjen vil ytelse være en sentral vurdering.
Noen av våre kunder har skapt et konsolidert syn. Det er vår oppfatning at dette sannsynligvis er overkill. Ytelsen vil alltid være dårligere i denne konsoliderte visningen, og vi har ikke støtt på mange brukstilfeller som bruker både live datasett og historisk. Live brukes til feilsøking og Historisk for trendrapportering.
Fra og med Cognos Analytics 11.1.7 har revisjonsdatabasen vokst til 21 tabeller. Du finner mer informasjon andre steder i revisjonsdatabasen, eksempler på revisjonsrapporter og Framework Manager -modellen. Standard loggingsnivå er Minimal, men det kan være lurt å bruke neste nivå, Basic, for å registrere bruksforespørsler, brukerkontokontroll og bruk av kjøretid. En måte du kan opprettholde systemytelsen på er ved å holde loggingsnivået til det laveste nivået som kreves. Selvfølgelig, jo mer logging som gjøres av serveren, desto mer kan den generelle serverytelsen påvirkes.
De viktigste tabellene de fleste administratorer vil være interessert i, er de 6 tabellene som logger brukeraktivitet og rapporteringsaktivitet i systemet.
- COGIPF_USERLOGON: Lagrer brukerens påloggingsinformasjon (inkludert avlogging)
- COGIPF_RUNREPORT: Lagrer informasjon om henrettelser i rapporten
- COGIPF_VIEWREPORT: Lagrer informasjon om forespørsler om rapportvisning
- COGIPF_EDITQUERY: Lagrer informasjon om spørrekjøringer
- COGIPF_RUNJOB: Lagrer informasjon om jobbforespørsler
- COGIPF_ACTION: Registrerer brukerhandlinger i Cognos (denne tabellen kan vokse mye raskere enn de andre)
Ut-av-esken-konfigurasjonen ser slik ut:
Anbefalt konfigurasjon:
Cognos Audit Database - Live inneholder 1 uke med revisjonsdata. Data eldre enn 1 uke flyttes til Cognos Audit Database - Historical.
Linjen fra Cognos Audit Database - Live til Cognos Audit Database - Historisk i diagrammet er ansvarlig for:
- Kopiering av data fra Live Audit til Historical Audit
- Fjern alle radene i Live Audit som er eldre enn 1 uke
- Fjern alle radene i historisk revisjon som er eldre enn x år
- Fjern alle radene i COGIPF_ACTION som er eldre enn 6 måneder
Indekser
Ulike databasetyper har forskjellige indekseringstyper. En databaseindeks er en datastruktur, knyttet til en tabell (eller visning), som brukes til å forbedre spørretiden når dataene hentes fra tabellen (eller visningen). Samarbeid med DBA for å lage den optimale strategien. De vil vite svarene på spørsmål som disse for å ta de beste avgjørelsene om hvilke kolonner som skal indekseres. Tydeligvis kan databaseadministratoren finne ut svarene på noen eller alle disse spørsmålene uten din hjelp, men det vil ta litt forskning og litt tid:
- Hvor mange poster har tabellene, og til hvilken størrelse forventer du at de skal vokse? (Indeksering av en tabell vil ikke være nyttig med mindre tabellen har et stort antall poster.)
- Vet du hvilke kolonner som er unike? Tillater de NULL -verdier? Hvilke kolonner har datatype heltall eller stort heltall? (Kolonnene med numeriske datatyper og som er UNIKE og IKKE NULL, er sterke kandidater til å delta i indeksnøkkelen.)
- Hvor er dine viktigste ytelsesproblemer i dag? Er de i å hente dataene? Er det spesifikke spørsmål eller rapporter som er mer et problem? (Dette kan føre databaseadministratoren til noen spesifikke kolonner som kan optimaliseres.)
- Hvilke felt brukes for å kombinere tabeller for rapportering?
- Hvilke felt brukes for filtrering, sortering, gruppering og aggregering?
Ikke overraskende er dette de samme spørsmålene som må besvares for å forbedre ytelsen til databasetabeller.
IBM -støtte anbefaler opprette en indeks på kolonnene "COGIPF_REQUESTID", "COGIPF_SUBREQUESTID" og "COGIPF_STEPID" for følgende tabeller for å forbedre ytelsen:
- COGIPF_NATIVEQUERY
- COGIPF_RUNJOB
- COGIPF_RUNJOBSTEP
- COGIPF_RUNREPORT
- COGIPF_EDITQUERY
Pluss på andre mindre brukte bord:
- COGIPF_POWERPLAY
- COGIPF_HUMANTASKSERVICE
- COGIPF_HUMANTASKSERVICE_DETAIL
Du kan bruke dette som utgangspunkt, men jeg vil gå gjennom øvelsen med å svare på spørsmålene ovenfor for å komme frem til det beste svaret for organisasjonen din.
andre hensyn
- Revisjon FM -modell. Husk at Framework Manager -modellen som IBM tilbyr, er modellert på standardbordene og -feltene. Eventuelle endringer du gjør i rapporteringstabellene, må gjenspeiles i modellen. Enkelheten eller kompleksiteten til disse endringene - eller organisasjonskompetansen din til å gjøre disse endringene - kan påvirke løsningen du velger.
- Flere felt. Hvis du skal gjøre det, er det nå på tide å legge til flere felt for kontekst- eller referansedata for å forbedre revisjonsrapporteringen.
- Oppsummeringstabeller. I stedet for bare å kopiere dataene til den historiske tabellen, komprimerer du dem. Du kan samle dataene til dagnivå for å gjøre det mer effektivt for rapportering.
- Visninger i stedet for bord. Andre sier: "Så, i stedet for å ha en" nåværende "database og en" historisk "database, bør du bare ha en database, og alle tabeller i den skal ha prefikset med" historisk ". Deretter bør du lage et sett med visninger, en for hver tabell du vil se som "nåværende", og la hver visning filtrere ut de historiske radene du ikke vil se, og la bare de nåværende passere gjennom. "
https://softwareengineering.stackexchange.com/questions/276395/two-database-architecture-operational-and-historical/276419#276419
konklusjonen
Poenget er at med informasjonen her bør du være godt forberedt på å ha en produktiv samtale med DBA. Sjansen er god for at hun har løst lignende problemer før.
De foreslåtte endringene i Cognos Audit Database-arkitektur vil forbedre ytelsen i både direkte rapportering og tredjeparts applikasjoner som er avhengige av den, som Motio'S ReportCard og beholdning.
Forresten, hvis du har hatt den samtalen med DBA, vil vi gjerne høre om det. Vi vil også gjerne høre om du har løst problemet med en dårlig utført revisjonsdatabase og hvordan du gjorde det.
