'N Blog deur John Boyer en Mike Norris.
Inleiding
Dit is belangrik dat die Cognos -ouditfunksie werk om te weet en te verstaan hoe Cognos deur u gebruikersgemeenskap gebruik word en om vrae te beantwoord soos:
-
- Wie gebruik die stelsel?
- Watter verslae voer hulle uit?
- Wat is die tydsduur van die verslag?
- Met die hulp van ander gereedskap, soos MotioCI, watter inhoud is ongebruik?
Aangesien dit van kritieke belang is om 'n gesonde Cognos Analytics -omgewing te handhaaf, is daar verbasend min oor die ouditdatabasis geskryf, bo die standaard produksiedokumentasie. Miskien word dit as vanselfsprekend aanvaar, maar organisasies wat dit gebruik, weet dat mettertyd die ouditdatabasistabelle kan begin afneem, veral as u organisasie baie gebruikers het wat baie verslae uitvoer en baie geskiedenis het. Wat meer is, is dat die aanmelding van die ouditaktiwiteit self vertraag kan word omdat dit in die ry staan as dit byvoorbeeld nie vinnig genoeg by die databasis gevoeg kan word nie. Dit is wanneer u aan die prestasie van die databasis begin dink, net soos met enige operasionele databasis wat verslagdoeningsvereistes het.
Groot tafels vertraag gewoonlik die prestasie van die navraag. Hoe groter die tabel, hoe langer neem dit om in te voeg en navraag te doen. Onthou dat hierdie tabelle en die ouditdatabasis basies 'n operasionele databasis is; skryfwerk vind gereeld plaas en werk teen ons, aangesien ons dit nie kan fokus nie, net vir leesoperasies soos met 'n data -mart.
Net soos die inhoudswinkel, moet die gesondheid van die Cognos -omgewing ook die gesondheid van die ouditdatabasis in ag neem. Onbeperkte groei van die ouditdatabasis kan mettertyd 'n probleem word en kan uiteindelik selfs die algehele prestasie van 'n Cognos -omgewing beïnvloed. In baie organisasies met eksterne regulasies wat op hulle afgedwing word, kan hulle met 'n volledige ouditrekord in 'n situasie wat nie voldoen nie, met groot gevolge beland. Hoe gaan ons daarmee om soveel data vir historiese ouditdoeleindes te onderhou - in sommige gevalle tot 10 jaar - maar ons kry nog steeds die verslag wat ons nodig het om die omgewing in stand te hou en gebruikers tevrede te hou met die prestasie?
Die Uitdaging
-
- Onbeperkte groei van die ouditdatabasis beïnvloed die gesondheid van die Cognos -omgewing negatief
- Dit is stadig of onbruikbaar om die ouditdatabasis aan te meld
- Cognos ondervind vertragings in rekords wat in die ouditdatabasis geskryf word
- Die ouditdatabasis raak op met skyfspasie
Dit alles beteken dat dit nie net die verslae is wat op die ouditdatabasis staatmaak nie, maar ook die hele stelsel. As die ouditdatabasis op dieselfde bediener as die Cognos -inhoudwinkel is, sal die prestasie van alle dinge in hierdie omgewing beïnvloed word.
Die opstelling
Ons neem aan:
-
- Cognos Analytics is geïnstalleer en werk
- Cognos is opgestel om by 'n ouditdatabasis aan te meld
-
- Hou 'n ouditdatabasis
- Stel toepaslike oudit -aanmeldingsvlakke in Cognos -administrasie
- Die rekord word deur Cognos in die databasis geskryf
- Die ouditdatabasis is al meer as 'n jaar in gebruik
- Die omgewing is baie aktief met gebruikers en teregstellings
- Die ouditpakket word gebruik om die gebruiksdata van Cognos na vore te bring
- Ons wil die verslagdoeningsverrigting van die ouditdatabasis verbeter
- Om te begin of ou rekords te verwyder, is nie altyd 'n opsie nie
As u dit nog nie gedoen het nie, het Cognos Audit geïnstalleer en gekonfigureer, Lodestar Solutions, a Motio vennoot, het 'n uitstekende pos oor die moontlikheid van oudit in Cognos BI /CA.
Die Oplossing
Daar is 'n paar moontlike oplossings wat hulself vinnig voorstel:
-
- Verminder die volume data deur:
-
- Skuif sommige van die ouer data na 'n ander databasis
- Skuif sommige van die ouer data na 'n ander tabel in dieselfde databasis
- Skrap of boog nethive sommige data, en moenie daaroor bekommerd wees nie
- Leef daarmee. Skop die blikkie af in die road en druk die databasisadministrateur vir prestasie
verbeterings terwyl hulle geboei word deur nie toe te laat dat die skema verander of
indekse
Ons gaan nie handel oor opsie 3. Opsie 2, die verwydering van die data, is nie 'n goeie opsie nie, en ek beveel aan dat u die waarde van ten minste 18 maande tot 'n minimum beperk. Maar as u so geneig is, bied IBM 'n program, OuditDBCleanup (Cognos BI) of a script (Cognos Analytics) wat presies dit sal doen. Die nut vir Cognos BI verwyder rekords wat gebaseer is op 'n tydstempel, terwyl die skrifte vir Cognos Analytics net die indekse en tabelle uitvee.
Die aanbevelings wat ons vroeër hieroor aan kliënte gemaak het, was om in twee databasisse te skei:
-
- Oudit - regstreeks: bevat die data van die afgelope week
- Oudit - Histories: bevat historiese data (tot N jaar)
Kortom, die proses loop weekliks om die mees onlangse rekords van Oudit Live na Ouditgeskiedenis te skuif. Oudit Live begin weer as 'n leë plak nadat hierdie proses uitgevoer is.
-
- Die Live DB is vinnig en styf, sodat insetsels so vinnig as moontlik kan gebeur
- Ouditnavrae is uitsluitlik gerig aan die Historiese DB
Deur hierdie benadering te gebruik, is daar geen implisiete "saamvoeging" van die lewendige data en die historiese data nie. Ek sou aanvoer dat u dit waarskynlik so wil hou.
In Cognos -administrasie kan u twee verskillende verbindings vir die ouditdatabron byvoeg. As 'n gebruiker 'n verslag teen die ouditpakket aflê, word hulle gevra vir watter verbinding hy wil gebruik:
As u kans sien om lewendige ouditdata eerder as historiese ouditdata te bekyk, kies u slegs die 'Oudit - lewend' -verbinding as dit gevra word (moet die uitsondering wees, nie die norm nie.)
As u regtig ook 'n gekonsolideerde beeld van beide lewendig en histories wil gee, kan u dit doen, maar dit sal die prestasie beïnvloed.
U kan byvoorbeeld 'n derde databasis met die naam 'Oudit - gekonsolideerde aansig' skep en dan vir elke tabel in die ouditskema 'n identiese naam skep wat 'n SQL -unie is tussen die tabel in die lewendige DB en die tabel in die historiese DB. Net so kan dit ook bereik word in die Framework Manager -model, maar weereens sou prestasie 'n belangrike oorweging wees.
Sommige van ons kliënte het 'n gekonsolideerde siening geskep. Dit is ons mening dat dit waarskynlik te veel is. Die prestasie sou altyd slegter wees in hierdie gekonsolideerde siening, en ons het nie baie gebruiksgevalle teëgekom wat beide die lewendige datastelle en die historiese gebruik nie. Die Live word gebruik vir probleemoplossing en die Historiese vir tendensverslaggewing.
Vanaf Cognos Analytics 11.1.7 het die ouditdatabasis gegroei tot 21 tabelle. U kan elders meer inligting vind oor die ouditdatabasis, voorbeeld -ouditverslae en die raamwerkbestuurder -model. Die standaard aanmeldvlak is minimaal, maar u wil dalk die volgende vlak, Basies, gebruiksversoeke, gebruikersrekeningbestuur en gebruiksduur gebruik. Een manier waarop u die stelselprestasie kan behou, is deur die aanmeldvlak tot die laagste vereiste vlak te hou. Hoe meer dit deur die bediener aangemeld word, hoe meer kan die algehele bedienerprestasie beïnvloed word.
Die sleuteltabelle waarin die meeste administrateurs sal belangstel, is die 6 tabelle wat die gebruikersaktiwiteit en verslagdoeningsaktiwiteit in die stelsel aanteken.
- COGIPF_USERLOGON: Stoor gebruikersaanmelding (insluitend afmelding)
- COGIPF_RUNREPORT: Stoor inligting oor verslaguitvoerings
- COGIPF_VIEWREPORT: Stoor inligting oor versoeke vir verslagaansig
- COGIPF_EDITQUERY: Stoor inligting oor navraaglopies
- COGIPF_RUNJOB: Stoor inligting oor werksversoeke
- COGIPF_ACTION: Teken gebruikersaksies op in Cognos (hierdie tabel kan baie vinniger groei as die ander)
Die out-of-the-box konfigurasie lyk so:
Aanbevole opset:
Die Cognos -ouditdatabasis - Live bevat 1 week ouditdata. Data ouer as 1 week word na die Cognos -ouditdatabasis geskuif - Histories.
Die lyn van die Cognos -ouditdatabasis - Live na Cognos -ouditdatabasis - Geskiedkundige in die diagram is verantwoordelik vir:
- Kopieer data van regstreekse oudit na historiese oudit
- Verwyder alle rye in die Live Audit wat ouer as 1 week is
- Verwyder alle rye in die historiese oudit wat ouer as x jaar is
- Verwyder alle rye in COGIPF_ACTION wat ouer as 6 maande is
Indekse
Verskillende databasistipes het verskillende tipes indeksering. 'N Databasisindeks is 'n datastruktuur wat verband hou met 'n tabel (of aansig), wat gebruik word om die uitvoeringstyd van navrae te verbeter wanneer die data uit die tabel (of aansig) gehaal word. Werk saam met u DBA om die optimale strategie te skep. Hulle sal die antwoorde op vrae soos hierdie wil weet om die beste besluite te neem oor watter kolomme hulle moet indekseer. Uiteraard kan die databasisadministrateur sonder u hulp die antwoorde op sommige of al hierdie vrae vind, maar dit sal 'n bietjie navorsing en tyd neem:
- Hoeveel rekords het die tabelle en tot watter grootte verwag u dat dit sal groei? (Die indeksering van 'n tabel sal nie nuttig wees nie, tensy die tabel 'n groot aantal rekords bevat.)
- Weet u watter kolomme uniek is? Laat hulle NULL waardes toe? Watter kolomme het die datatipe heelgetal of groot heelgetal? (Die kolomme met numeriese datatipes en wat UNIEK en NIE NUL is nie, is sterk kandidate om aan die indeksleutel deel te neem.)
- Waar is u belangrikste prestasieprobleme vandag? Is hulle besig om die data op te spoor? Is daar spesifieke navrae of verslae wat meer 'n probleem is? (Dit kan die databasisadministrateur na spesifieke kolomme lei wat geoptimaliseer kan word.)
- Watter velde word gebruik in die byvoeging van tabelle vir verslagdoening?
- Watter velde word gebruik om te filter, te sorteer, te groepeer en te aggregeer?
Nie verrassend nie, dit is dieselfde vrae wat beantwoord moet word om die prestasie van enige databasistabelle te verbeter.
IBM Ondersteuning beveel aan skep 'n indeks vir kolomme "COGIPF_REQUESTID", "COGIPF_SUBREQUESTID" en "COGIPF_STEPID" vir die volgende tabelle om die prestasie te verbeter:
- COGIPF_NATIVEQUERY
- COGIPF_RUNJOB
- COGIPF_RUNJOBSTEP
- COGIPF_RUNREPORT
- COGIPF_EDITQUERY
Plus op ander minder gebruikte tafels:
- COGIPF_POWERPLAY
- COGIPF_HUMANTASKSERVICE
- COGIPF_HUMANTASKSERVICE_DETAIL
U kan dit as uitgangspunt gebruik, maar ek sal die oefening beantwoord om die vrae hierbo te beantwoord om by die beste antwoord vir u organisasie uit te kom.
ander oorwegings
- Oudit FM -model. Onthou dat die Framework Manager -model wat IBM verskaf, op die standaardtabelle en -velde geskoei is. Enige veranderinge wat u aan die verslagdoeningstabelle aanbring, moet in die model weerspieël word. Die gemak of kompleksiteit van hierdie veranderinge - of u organisatoriese bevoegdheid om hierdie veranderinge aan te bring - kan die oplossing wat u kies beïnvloed.
- Bykomende velde. As u dit gaan doen, is dit nou die tyd om addisionele velde vir konteks- of verwysingsdata by te voeg om die ouditverslaggewing te verbeter.
- Opsommingstabelle. Druk die data saam in plaas daarvan om die data net na u historiese tabel te kopieer. U kan die data op die dagvlak versamel om dit doeltreffender te maak vir verslagdoening.
- Uitsigte in plaas van tabelle. Ander sê: 'In plaas daarvan om 'n' huidige 'databasis en' 'historiese' databasis te hê, moet u slegs een databasis hê, en alle tabelle daarin moet die voorvoegsel met 'historiese' hê. Dan moet u 'n stel aansigte skep, een vir elke tabel wat u as 'aktueel' wil sien, en elke aansig laat filter die historiese rye wat u nie wil sien nie, en laat slegs die huidige deurgaan.
https://softwareengineering.stackexchange.com/questions/276395/two-database-architecture-operational-and-historical/276419#276419
Gevolgtrekking
Die uiteinde is dat u, met die inligting wat u hier verskaf, goed voorbereid moet wees om 'n produktiewe gesprek met u DBA te voer. Die kans is goed dat sy voorheen soortgelyke probleme opgelos het.
Die voorgestelde veranderings in die Cognos-ouditdatabasis-argitektuur sal die prestasie in beide direkte verslagdoening sowel as toepassings van derdepartye wat daarop staatmaak, verbeter. Motio'N ReportCard en Voorraad.
Terloops, as u die gesprek met u DBA gehad het, hoor ons dit graag. Ons sal ook graag wil hoor of u die probleem van 'n swak ouditdatabasis opgelos het en hoe u dit gedoen het.
