Een blog van John Boyer en Mike Norris.
Introductie
Het is belangrijk dat de Cognos Auditing-functie werkt om te weten en te begrijpen hoe Cognos wordt gebruikt door uw gebruikersgemeenschap en om vragen te helpen beantwoorden zoals:
-
- Wie gebruikt het systeem?
- Welke rapporten draaien ze?
- Wat zijn de doorlooptijden van het rapport?
- Met behulp van andere tools, zoals MotioCI, welke inhoud is ongebruikt?
Gezien hoe belangrijk het is om gezonde Cognos Analytics-omgevingen te onderhouden, is er verrassend weinig geschreven over de controledatabase buiten de standaard productdocumentatie. Misschien is het vanzelfsprekend, maar organisaties die het gebruiken, weten dat na verloop van tijd het doorzoeken van de Audit Database-tabellen zal vertragen, vooral als uw organisatie veel gebruikers heeft die veel rapporten uitvoeren en veel geschiedenis heeft. Wat meer is, is dat het loggen van auditactiviteiten zelf kan worden vertraagd omdat het in de wachtrij wordt geplaatst wanneer het bijvoorbeeld niet snel genoeg aan de database kan worden toegevoegd. Op dat moment begint u na te denken over databaseprestaties zoals u zou doen met elke operationele database die rapportagevereisten heeft.
Grote tabellen vertragen doorgaans de prestaties van query's. Hoe groter de tabel, hoe langer het duurt om in te voegen en op te vragen. Onthoud dat deze tabellen en de Audit Database in feite een operationele database zijn; schrijfbewerkingen komen vaak voor en werken tegen ons omdat we ze niet kunnen concentreren op alleen leesbewerkingen zoals u zou doen met een datamart.
Net als de content store, moet de gezondheid van de Cognos-omgeving ook rekening houden met de gezondheid van de Audit Database. Onbeperkte groei van de Audit Database kan in de loop van de tijd een probleem worden en kan uiteindelijk zelfs de algehele prestaties van een Cognos-omgeving beïnvloeden. In veel organisaties met externe regelgeving die hen wordt opgedrongen, kan het ontbreken van een volledig auditverslag hen in een situatie van niet-naleving doen belanden met zware gevolgen. Dus hoe gaan we om met het feit dat we zoveel gegevens moeten bijhouden voor historische auditdoeleinden - in sommige gevallen tot 10 jaar - en toch de rapportage moeten krijgen die we nodig hebben om de omgeving te onderhouden en gebruikers tevreden te houden met de prestaties?
De Uitdaging
-
- Onbeperkte groei van de Audit Database heeft een negatieve invloed op de gezondheid van de Cognos-omgeving
- Rapportage vanuit de Audit Database is traag of onbruikbaar geworden
- Cognos ondervindt vertragingen bij het schrijven van records naar de auditdatabase
- De auditdatabase heeft bijna geen schijfruimte meer
Dit alles betekent dat het niet alleen de rapporten zijn die afhankelijk zijn van de Audit Database, maar vaak het hele systeem. Als de auditdatabase zich op dezelfde server bevindt als de Cognos-contentstore, worden de prestaties van alle dingen die Cognos in die omgeving gebruikt, beïnvloed.
De Setup
Wij nemen aan:
-
- Cognos Analytics is geïnstalleerd en actief
- Cognos is geconfigureerd om in te loggen op een auditdatabase
-
- Zorg voor een auditdatabase
- Stel de juiste niveaus voor controlelogboekregistratie in Cognos-beheer in
- Record wordt door Cognos naar de database geschreven
- De Audit Database is al meer dan een jaar in gebruik
- De omgeving is erg actief met gebruikers en uitvoeringen
- Het Audit-pakket wordt gebruikt om Cognos-gebruiksgegevens aan het licht te brengen
- We willen de rapportageprestaties van Audit Database verbeteren
- Opnieuw beginnen of oude records verwijderen is niet altijd een optie
Als u Cognos Audit nog niet hebt geïnstalleerd en geconfigureerd, kan Lodestar Solutions, een Motio partner, heeft een uitstekende post over het inschakelen van Audit in Cognos BI /CA.
De oplossing
Er zijn enkele mogelijke oplossingen die zich snel aandienen:
-
- Verminder de hoeveelheid gegevens door:
-
- Een deel van de oudere gegevens naar een andere database verplaatsen
- Een deel van de oudere gegevens naar een andere tabel in dezelfde database verplaatsen
- Gewoon verwijderen of archive een deel van de gegevens en maak je er geen zorgen over
- Leef ermee. Schop het blikje naar beneden road en druk op de databasebeheerder voor prestaties
verbeteringen terwijl u ze handboeien omdoet door geen wijzigingen in het schema toe te staan of
indexen
We gaan niet in op optie 3. Optie 2, het verwijderen van de gegevens, is geen goede optie en ik raad aan om minimaal 18 maanden aan te houden. Maar als u zo geneigd bent, biedt IBM een hulpprogramma, AuditDBCleanup (Cognos BI) of a script (Cognos Analytics) die precies dat zal doen. Het hulpprogramma voor Cognos BI verwijdert records op basis van een tijdstempel, terwijl de scripts voor Cognos Analytics alleen de indexen en tabellen verwijderen.
De aanbevelingen die we eerder aan klanten hierover hebben gedaan, waren om op te splitsen in twee databases:
-
- Audit – Live: bevat de gegevens van de meest recente week
- Audit – Historisch: bevat historische gegevens (tot N jaar)
Kortom, het proces wordt wekelijks uitgevoerd om de meest recente records van Audit Live naar Audit Historical te verplaatsen. Audit Live begint opnieuw als een schone lei nadat dit proces is uitgevoerd.
-
- De Live DB is snel en strak, waardoor invoegingen zo snel mogelijk kunnen gebeuren
- Auditquery's zijn uitsluitend gericht op de Historische DB
Met deze benadering is er geen impliciete "aan elkaar geplakte" van de Live data en de Historische data. Ik zou zeggen dat je het waarschijnlijk zo wilt houden.
In Cognos Administration kunt u twee verschillende verbindingen toevoegen voor de controlegegevensbron. Wanneer een gebruiker een rapport uitvoert op basis van het Audit-pakket, wordt hem gevraagd welke verbinding hij wil gebruiken:
Als u toevallig naar live auditgegevens wilt kijken in plaats van historische auditgegevens, kiest u gewoon de "Audit - Live" -verbinding wanneer daarom wordt gevraagd (zou de uitzondering moeten zijn, niet de norm.)
Als u ECHT ook een geconsolideerde weergave van zowel Live als Historisch wilt bieden, zou u dat kunnen doen, maar dit zou de prestaties beïnvloeden.
U kunt bijvoorbeeld een 3e database maken met de naam "Audit – Consolidated View" en vervolgens voor elke tabel in het auditschema: maak een weergave met dezelfde naam die een SQL-unie is tussen de tabel in de live DB en de tabel in de historische DB. Op dezelfde manier zou dit ook kunnen worden bereikt in het Framework Manager-model, maar nogmaals, prestaties zouden een belangrijke overweging zijn.
Sommige van onze klanten hebben een geconsolideerd overzicht gecreëerd. Wij zijn van mening dat dit waarschijnlijk overkill is. De prestaties zouden altijd slechter zijn in deze geconsolideerde weergave en we zijn niet veel use-cases tegengekomen die zowel de Live-gegevenssets als Historisch gebruiken. De Live wordt gebruikt voor het oplossen van problemen en de Historisch voor trendrapportage.
Met ingang van Cognos Analytics 11.1.7 is de auditdatabase uitgegroeid tot 21 tabellen. Elders in de Audit Database, voorbeelden van auditrapporten en het Framework Manager-model vindt u meer informatie. Het standaard logboekniveau is Minimaal, maar u kunt het volgende niveau, Basis, gebruiken om gebruiksverzoeken, gebruikersaccountbeheer en runtimegebruik vast te leggen. Een manier waarop u de systeemprestaties kunt handhaven, is door het logboekregistratieniveau op het laagste vereiste niveau te houden. Het is duidelijk dat hoe meer logboekregistratie door de server wordt gedaan, hoe meer de algehele serverprestaties kunnen worden beïnvloed.
De belangrijkste tabellen waarin de meeste beheerders geïnteresseerd zullen zijn, zijn de 6 tabellen die de gebruikersactiviteit en rapportageactiviteiten in het systeem registreren.
- COGIPF_USERLOGON: Slaat gebruikersaanmeldingsgegevens (inclusief uitloggen) op
- COGIPF_RUNREPORT: Slaat informatie op over rapportuitvoeringen
- COGIPF_VIEWREPORT : Slaat informatie op over rapportweergaveverzoeken
- COGIPF_EDITQUERY: Slaat informatie op over het uitvoeren van query's
- COGIPF_RUNJOB : Slaat informatie op over taakaanvragen
- COGIPF_ACTION: registreert gebruikersacties in Cognos (deze tabel kan veel sneller groeien dan de andere)
De kant-en-klare configuratie ziet er als volgt uit:
Aanbevolen configuratie:
De Cognos Audit Database – Live bevat 1 week aan auditgegevens. Gegevens ouder dan 1 week worden verplaatst naar de Cognos Audit Database – Historisch.
De regel van de Cognos Audit Database – Live naar Cognos Audit Database – Historisch in het diagram is verantwoordelijk voor:
- Gegevens kopiëren van Live Audit naar Historische Audit
- Verwijder alle rijen in de Live Audit die ouder zijn dan 1 week
- Verwijder alle rijen in Historische controle die ouder zijn dan x jaar
- Verwijder alle rijen in COGIPF_ACTION die ouder zijn dan 6 maanden
Indexen
Verschillende databasetypen hebben verschillende indexeringstypen. Een database-index is een gegevensstructuur, gekoppeld aan een tabel (of weergave), die wordt gebruikt om de uitvoeringstijd van query's te verbeteren bij het ophalen van de gegevens uit die tabel (of weergave). Werk samen met uw DBA om de optimale strategie te creëren. Ze zullen de antwoorden op dit soort vragen willen weten om de beste beslissingen te nemen over welke kolommen ze moeten indexeren. Het is duidelijk dat de databasebeheerder de antwoorden op sommige of al deze vragen zonder uw hulp kan vinden, maar het zou wat onderzoek en enige tijd vergen:
- Hoeveel records hebben de tabellen en tot hoe groot verwacht u dat ze zullen groeien? (Het indexeren van een tabel is niet nuttig tenzij de tabel een groot aantal records heeft.)
- Weet jij welke kolommen uniek zijn? Staan ze NULL-waarden toe? Welke kolommen hebben het gegevenstype geheel getal of groot geheel getal? (De kolommen met numerieke gegevenstypen en die UNIEK en NIET NULL zijn, zijn sterke kandidaten om deel te nemen aan de indexsleutel.)
- Waar zijn uw belangrijkste prestatieproblemen vandaag? Zijn ze bezig met het ophalen van de gegevens? Zijn er specifieke vragen of meldingen die meer een probleem vormen? (Dit kan de databasebeheerder naar enkele specifieke kolommen leiden die kunnen worden geoptimaliseerd.)
- Welke velden worden gebruikt in het samenvoegen van tabellen voor rapportage?
- Welke velden worden gebruikt voor filteren, sorteren, groeperen en aggregeren?
Het is niet verrassend dat dit dezelfde vragen zijn die moeten worden beantwoord om de prestaties van databasetabellen te verbeteren.
IBM-ondersteuning beveelt een index maken op de kolommen "COGIPF_REQUESTID", "COGIPF_SUBREQUESTID" en "COGIPF_STEPID" voor de volgende tabellen om de prestaties te verbeteren:
- COGIPF_NATIVEQUERY
- COGIPF_RUNJOB
- COGIPF_RUNJOBSTEP
- COGIPF_RUNREPORT
- COGIPF_EDITQUERY
Plus op andere minder gebruikte tabellen:
- COGIPF_POWERPLAY
- COGIPF_HUMANTASKSERVICE
- COGIPF_HUMANTASKSERVICE_DETAIL
U kunt dit als uitgangspunt gebruiken, maar ik zou de oefening van het beantwoorden van de bovenstaande vragen doornemen om tot het beste antwoord voor uw organisatie te komen.
Andere Overwegingen
- Audit FM-model. Onthoud dat het Framework Manager-model dat IBM levert, is gemodelleerd op de standaardtabellen en -velden. Alle wijzigingen die u aanbrengt in de rapportagetabellen, moeten in het model worden weergegeven. Het gemak of de complexiteit van deze wijzigingen – of uw organisatorische bekwaamheid om deze wijzigingen aan te brengen – kan van invloed zijn op de oplossing die u kiest.
- Extra velden. Als je het gaat doen, is dit het moment om extra velden toe te voegen voor context- of referentiegegevens om de auditrapportage te verbeteren.
- Samenvattende tabellen. In plaats van alleen de gegevens naar uw historische tabel te kopiëren, comprimeert u deze. U kunt de gegevens op dagniveau aggregeren om het efficiënter te maken voor rapportage.
- Weergaven in plaats van tabellen. Anderen zeggen: “Dus in plaats van een 'huidige' database en een 'historische' database, zou je maar één database moeten hebben, en alle tabellen daarin zouden moeten worden voorafgegaan door 'historisch'. Vervolgens moet je een set weergaven maken, één voor elke tabel die je als 'huidig' wilt zien, en elke weergave de historische rijen laten filteren die je niet wilt zien en alleen de huidige doorlaten."
https://softwareengineering.stackexchange.com/questions/276395/two-database-architecture-operational-and-historical/276419#276419
Conclusie
Het komt erop neer dat u met de hier verstrekte informatie goed voorbereid moet zijn op een productief gesprek met uw DBA. De kans is groot dat ze al eerder soortgelijke problemen heeft opgelost.
De voorgestelde wijzigingen in de Cognos Audit Database-architectuur zullen de prestaties verbeteren in zowel directe rapportage als toepassingen van derden die erop vertrouwen, zoals Motio's ReportCard en inventaris.
Trouwens, als je dat gesprek met je DBA hebt gehad, horen we het graag. We horen ook graag of je het probleem van een slecht presterende Audit Database hebt opgelost en hoe je dat hebt gedaan.
