Blog Johna Boyera a Mika Norrisa.
úvod
Je dôležité, aby funkcia Cognos Auditing fungovala, aby ste vedeli a porozumeli tomu, ako Cognos používa vaša užívateľská komunita, a pomohli vám odpovedať na otázky ako:
-
- Kto používa systém?
- Aké prehľady prevádzkujú?
- Aké sú časy spustenia prehľadu?
- S pomocou ďalších nástrojov, ako napr MotioCI, Aký obsah je nepoužitý?
Vzhľadom na to, aké dôležité je udržiavať zdravé prostredie Cognos Analytics, bolo o jeho audítorskej databáze nad rámec štandardnej dokumentácie produktu napísané prekvapivo málo. Možno je to samozrejmé, ale organizácie, ktoré to používajú, vedia, že v priebehu času sa dotazovanie tabuliek databázy auditu začne spomaľovať - najmä ak má vaša organizácia veľa používateľov, ktorí používajú veľa zostáv a majú veľa histórie. Ba čo viac, samotné protokolovanie aktivít auditu sa môže oneskoriť, pretože sa zaraďuje do poradia, keď ho napríklad nemožno pridať dostatočne rýchlo do databázy. To je, keď začnete premýšľať o výkone databázy rovnako ako o akejkoľvek operačnej databáze, ktorá má požiadavky na vykazovanie.
Veľké tabuľky zvyčajne spomaľujú výkon dotazov. Čím väčšia je tabuľka, tým dlhšie trvá vloženie a dotazovanie. Nezabudnite, že tieto tabuľky a databáza auditu sú v zásade operačnou databázou; zápisy sa dejú často a fungujú proti nám, pretože ich nemôžeme zamerať iba na operácie čítania, ako by ste to urobili s údajovým trhom.
Rovnako ako úložisko obsahu, zdravie prostredia Cognos musí brať do úvahy aj stav databázy auditov. Neobmedzený rast databázy auditov sa môže časom stať problémom a môže dokonca mať vplyv na celkový výkon prostredia Cognos. V mnohých organizáciách s externými predpismi, ktoré majú na svedomí, ich neúplný záznam z auditu môže dostať do situácie nedodržiavania predpisov s vážnymi následkami. Ako sa teda vysporiadame s tým, že musíme uchovávať toľko údajov na účely historického auditu - v niektorých prípadoch až 10 rokov - a napriek tomu získať prehľady, ktoré potrebujeme na zachovanie životného prostredia a spokojnosť používateľov s výkonom?
Challenge
-
- Neobmedzený nárast databázy auditov má negatívny vplyv na zdravie prostredia Cognos
- Vykazovanie z databázy auditu sa stalo pomalým alebo nepoužiteľným
- Cognos zaznamenáva oneskorenia pri zápise záznamov do databázy auditu
- V databáze auditu dochádza miesto na disku
To všetko znamená, že nielen databázy, ktoré sa spoliehajú na databázu auditov, trpia, ale často aj celý systém. Ak je databáza auditu na tom istom serveri ako úložisko obsahu Cognos, v tomto prostredí bude mať vplyv na výkonnosť všetkých vecí, ktoré Cognos má.
Setup
Predpokladáme:
-
- Cognos Analytics je nainštalovaný a beží
- Cognos je nakonfigurovaný na prihlásenie do audítorskej databázy
-
- Majte k dispozícii databázu auditov
- Nastavte príslušné úrovne protokolovania auditu v správe Cognos
- Záznamy zapisuje do databázy spoločnosť Cognos
- Auditová databáza sa používa viac ako rok
- Prostredie je veľmi aktívne s používateľmi a exekúciami
- Balík Audit sa používa na zverejnenie údajov o použití Cognos
- Snažíme sa zlepšiť výkonnosť vykazovania databázy auditov
- Začatie odznova alebo vymazanie starých záznamov nie je vždy možnosťou
Ak ešte nemáte, nainštalovaný a nakonfigurovaný Cognos Audit, Lodestar Solutions, a Motio partner, má vynikajúce zverejniť o povolení auditu v Cognos BI /CA.
Riešenie
Existuje niekoľko možných riešení, ktoré sa rýchlo prejavia:
-
- Znížte objem údajov:
-
- Presun niektorých starších údajov do inej databázy
- Presun niektorých starších údajov do inej tabuľky v tej istej databáze
- Stačí vymazať alebo oblúkhive niektoré údaje a nerobte si s nimi starosti
- Žite s tým. Vykopnite plechovku road a tlačte správcu databázy na výkon
vylepšenia a zároveň ich spútať nepovolením úprav schémy alebo
indexy
Nebudeme sa zaoberať možnosťou 3. Možnosť 2, vymazanie údajov, nie je dobrá voľba a odporúčal by som zachovať minimálnu hodnotu aspoň 18 mesiacov. Ak však máte taký záujem, spoločnosť IBM poskytuje nástroj, AuditDBCleanup (Cognos BI) alebo a scenár (Cognos Analytics), ktorý to presne urobí. Nástroj pre Cognos BI odstráni záznamy na základe časovej pečiatky, zatiaľ čo skripty pre Cognos Analytics odstránia iba indexy a tabuľky.
Odporúčania, ktoré sme v tejto súvislosti urobili klientom, boli rozdeliť do dvoch databáz:
-
- Audit - naživo: obsahuje údaje za posledný týždeň
- Audit - historický: obsahuje historické údaje (až N rokov)
Stručne povedané, tento proces prebieha raz za týždeň, aby sa najnovšie záznamy presunuli z Audit Live do Audit Historical. Po spustení tohto procesu sa Audit Live začína znova ako prázdna tabuľka.
-
- Live DB je rýchly a tesný, čo umožňuje, aby vložky prebehli čo najrýchlejšie
- Auditné dotazy sú výlučne smerované do Historickej databázy
Pri použití tohto prístupu nedochádza k žiadnemu implicitnému „spájaniu“ živých a historických údajov. Tvrdil by som, že to asi chcete nechať tak.
V aplikácii Cognos Administration môžete pre zdroj údajov auditu pridať dve rôzne pripojenia. Keď používateľ spustí správu proti balíku Audit, zobrazí sa výzva, ktoré pripojenie chce použiť:
Pokiaľ sa chcete pozrieť na aktuálne údaje z auditu, a nie na historické údaje z auditu, na výzvu vyberte pripojenie „Audit - živé“ (mala by to byť výnimka, nie norma.)
Ak OPRAVDU tiež chcete poskytnúť konsolidovaný prehľad živých aj historických záznamov, môžete tak urobiť, ale malo by to vplyv na výkon.
Môžete napríklad vytvoriť tretiu databázu s názvom „Audit - konsolidované zobrazenie“ a potom pre každú tabuľku v schéme auditu vytvoriť identicky pomenované zobrazenie, ktoré je zjednotením SQL medzi tabuľkou v živej databáze DB a tabuľkou v tabuľke historická DB. Podobne by sa to dalo dosiahnuť aj v modeli Framework Manager, ale opäť by kľúčovým aspektom bol výkon.
Niektorí z našich klientov vytvorili konsolidovaný pohľad. Podľa nášho názoru je to pravdepodobne prehnané. V tomto konsolidovanom pohľade by bol výkon vždy horší a nenarazili sme na mnoho prípadov použitia, ktoré používajú aktuálne súbory údajov aj historické. Živý prenos sa používa na riešenie problémov a historický prehľad trendov.
Od Cognos Analytics 11.1.7 sa databáza auditu rozrástla na 21 tabuliek. Ďalšie informácie nájdete inde v databáze auditov, vzorových správach z auditu a modeli Framework Manager. Predvolená úroveň protokolovania je Minimálna, ale možno budete chcieť použiť ďalšiu úroveň, Základnú, na zachytenie požiadaviek na používanie, správy používateľských kont a používania runtime. Jedným zo spôsobov, ako môžete udržať výkon systému, je udržanie úrovne protokolovania na najnižšej požadovanej úrovni. Je zrejmé, že čím viac protokolovania server vykoná, tým môže byť ovplyvnený celkový výkon servera.
Kľúčové tabuľky, ktoré väčšinu správcov budú zaujímať, sú 6 tabuliek, ktoré zaznamenávajú aktivitu používateľov a aktivitu hlásení v systéme.
- COGIPF_USERLOGON: Ukladá informácie o prihlásení používateľa (vrátane odhlásenia)
- COGIPF_RUNREPORT: Ukladá informácie o spustení správy
- COGIPF_VIEWREPORT: Ukladá informácie o požiadavkách na zobrazenie zostavy
- COGIPF_EDITQUERY: Ukladá informácie o spusteniach dotazov
- COGIPF_RUNJOB: Ukladá informácie o požiadavkách na úlohy
- COGIPF_ACTION: Zaznamenáva akcie používateľov v Cognos (táto tabuľka môže rásť oveľa rýchlejšie ako ostatné)
Vybalená konfigurácia vyzerá takto:
Odporúčaná konfigurácia:
Cognos Audit Database - Live obsahuje 1 týždeň audítorských údajov. Údaje staršie ako 1 týždeň sa presunú do Cognos Audit Database - Historical.
Riadok z databázy Cognos Audit Database - Live to Cognos Audit Database - Historical v diagrame je zodpovedný za:
- Kopírovanie údajov z živého auditu do historického auditu
- Odstráňte všetky riadky v živom audite, ktoré sú staršie ako 1 týždeň
- Odstráňte všetky riadky v Historickom audite, ktoré sú staršie ako x rokov
- Odstráňte všetky riadky v COGIPF_ACTION, ktoré sú staršie ako 6 mesiacov
Indexy
Rôzne typy databáz majú rôzne typy indexovania. Databázový index je dátová štruktúra priradená k tabuľke (alebo zobrazeniu), ktorá sa používa na skrátenie času vykonávania dotazov pri získavaní údajov z tejto tabuľky (alebo zobrazenia). Spolupracujte so svojim DBA na vytvorení optimálnej stratégie. Budú chcieť poznať odpovede na tieto otázky, aby sa mohli najlepšie rozhodnúť, ktoré stĺpce indexovať. Je zrejmé, že správca databázy by mohol nájsť odpovede na niektoré alebo všetky tieto otázky bez vašej pomoci, vyžadovalo by to však nejaký výskum a nejaký čas:
- Koľko záznamov majú tabuľky a do akej veľkosti predpokladáte, že narastú? (Indexovanie tabuľky nebude užitočné, pokiaľ tabuľka nemá veľký počet záznamov.)
- Viete, ktoré stĺpce sú jedinečné? Povolia hodnoty NULL? Ktoré stĺpce majú dátový typ celočíselný alebo veľký? (Stĺpce s číselnými typmi údajov, ktoré sú JEDINEČNÉ a NENÍ NULL, sú silnými kandidátmi na účasť v kľúči indexu.)
- Kde sú dnes vaše hlavné problémy s výkonom? Získavajú údaje? Existujú konkrétne otázky alebo správy, ktoré sú väčším problémom? (To môže správcu databázy priviesť k niektorým konkrétnym stĺpcom, ktoré je možné optimalizovať.)
- Aké polia sa používajú na spájanie tabuliek na vytváranie prehľadov?
- Aké polia sa používajú na filtrovanie, triedenie, zoskupovanie a agregáciu?
Nie je prekvapením, že ide o rovnaké otázky, na ktoré by bolo potrebné odpovedať, aby sa zlepšil výkon akýchkoľvek databázových tabuliek.
Podpora IBM odporúča vytvorenie indexu pre stĺpce „COGIPF_REQUESTID“, „COGIPF_SUBREQUESTID“ a „COGIPF_STEPID“ pre nasledujúce tabuľky na zlepšenie výkonu:
- COGIPF_NATIVEQUERY
- COGIPF_RUNJOB
- COGIPF_RUNJOBSTEP
- COGIPF_RUNREPORT
- COGIPF_EDITQUERY
Plus na ďalších menej používaných stoloch:
- COGIPF_POWERPLAY
- COGIPF_HUMANTASKSERVICE
- COGIPF_HUMANTASKSERVICE_DETAIL
Môžete to použiť ako východiskový bod, ale ja by som prešiel cvičením zodpovedania vyššie uvedených otázok, aby som našiel najlepšiu odpoveď pre vašu organizáciu.
Ostatné úvahy
- Auditujte model FM. Nezabudnite, že model Framework Manager, ktorý poskytuje spoločnosť IBM, je vytvorený podľa predvolených tabuliek a polí. Všetky zmeny, ktoré vykonáte v tabuľkách prehľadov, sa budú musieť prejaviť v modeli. Jednoduchosť alebo zložitosť týchto zmien - alebo vaše organizačné schopnosti tieto zmeny vykonať - môžu mať vplyv na zvolené riešenie.
- Ďalšie polia. Ak sa do toho chystáte, teraz je načase pridať ďalšie polia pre kontextové alebo referenčné údaje, aby ste zlepšili vykazovanie auditu.
- Súhrnné tabuľky. Namiesto kopírovania údajov do vašej historickej tabuľky ich skomprimujte. Dáta by ste mohli agregovať na úroveň dňa, aby boli prehľady efektívnejšie.
- Pohľady namiesto tabuliek. Iní hovoria: „Takže namiesto„ aktuálnej “databázy a„ historickej “databázy by ste mali mať iba jednu databázu a všetky tabuľky v nej by mali mať predponu„ historickú “. Potom by ste mali vytvoriť skupinu zobrazení, jedno pre každú tabuľku, ktorú chcete vidieť ako „aktuálnu“, a nechať každé zobrazenie odfiltrovať historické riadky, ktoré nechcete vidieť, a nechať prejsť iba tie aktuálne. ”
https://softwareengineering.stackexchange.com/questions/276395/two-database-architecture-operational-and-historical/276419#276419
záver
Pointa je, že s informáciami, ktoré sú tu uvedené, by ste mali byť dobre pripravení na produktívny rozhovor s vašim DBA. Je pravdepodobné, že podobné problémy už riešila.
Navrhované zmeny v architektúre databázy Cognos Audit zlepšia výkon v rámci priameho vykazovania, ako aj v aplikáciách tretích strán, ktoré na neho závisia, ako napr. Motio'S ReportCard a zásoby.
Mimochodom, ak ste mali ten rozhovor s vašim DBA, radi by sme sa o tom dozvedeli. Radi by sme sa tiež dozvedeli, či ste vyriešili problém so slabo výkonnou databázou auditu a ako ste to urobili.
