Cognos Auditing Blog - Tippek és trükkök nagy és nagy volumenű környezetekhez

by May 17, 2021Könyvvizsgálat0 megjegyzések

John Boyer és Mike Norris blogja.

Bevezetés

Fontos, hogy a Cognos Auditálás funkciója ismerje és megértse, hogyan használja a Cognos -ot a felhasználói közössége, és segítsen válaszolni az alábbi kérdésekre:

    • Ki használja a rendszert?
    • Milyen jelentéseket futtatnak?
    • Melyek a jelentések futási ideje?
    • Más eszközök segítségével, mint pl MotioCI, milyen tartalom nem használt?

Figyelembe véve, mennyire fontos az egészséges Cognos Analytics környezet fenntartása, meglepően keveset írtak az auditálási adatbázisáról a szabványos termékdokumentáción túl. Talán magától értetődő, de az azt használó szervezetek tudják, hogy idővel az Audit Database táblák lekérdezése lassulni fog - különösen, ha szervezetének sok felhasználója sok jelentést futtat, és sok előzménye van. Sőt, az ellenőrzési tevékenység naplózása is késhet, mert sorba kerül, ha például nem lehet elég gyorsan hozzáadni az adatbázishoz. Ekkor kezd el gondolkodni az adatbázis teljesítményéről, mint minden működő adatbázis esetében, amely rendelkezik jelentési követelményekkel.

A nagy táblák általában lassítják a lekérdezési teljesítményt. Minél nagyobb a táblázat, annál tovább tart a beszúrás és a lekérdezés. Ne feledje, hogy ezek a táblázatok és az ellenőrzési adatbázis alapvetően működő adatbázis; az írások gyakran történnek, és ellenünk dolgoznak, mivel nem tudjuk őket csak olvasási műveletekre összpontosítani, mint ahogy azt egy adatmártonnal tenné.

A tartalomtárhoz hasonlóan a Cognos környezet állapotának is figyelembe kell vennie az Ellenőrzési adatbázis állapotát. Az ellenőrzési adatbázis korlátlan növekedése idővel problémává válhat, és végül akár hatással lehet a Cognos környezet általános teljesítményére. Sok olyan szervezetben, amelyekre külső szabályozás vonatkozik, a teljes könyvvizsgálati nyilvántartás hiánya súlyos következményekkel járhat a szabályok be nem tartásában. Hogyan kezeljük tehát azt, hogy ennyi adatot kell megőriznünk történelmi ellenőrzési célokra - egyes esetekben akár 10 évig is -, mégis megkapjuk azokat a jelentéseket, amelyekre szükségünk van a környezet fenntartásához és a felhasználók elégedettségének megőrzéséhez?

A kihívás

    • Az ellenőrzési adatbázis korlátlan növekedése negatívan befolyásolja a Cognos környezet állapotát
    • Az ellenőrzési adatbázis jelentése lassúvá vagy használhatatlanná vált
    • A Cognos késlelteti a rekordok írását az ellenőrzési adatbázisba
    • Az Ellenőrzési adatbázis elfogy a lemezterület

Mindez azt jelenti, hogy nemcsak az ellenőrzési adatbázisra támaszkodó jelentések, hanem gyakran a teljes rendszer is szenved. Ha a naplózási adatbázis ugyanazon a szerveren található, mint a Cognos tartalomtároló, akkor minden Cognos teljesítményét befolyásolja az adott környezet.

A Beállítás

Úgy gondoljuk:

    1. A Cognos Analytics telepítve van és fut
    2. A Cognos úgy van konfigurálva, hogy bejelentkezzen egy ellenőrzési adatbázisba
        • Készítsen ellenőrzési adatbázist
        • Állítsa be a megfelelő naplózási szinteket a Cognos adminisztrációjában
        • A rekordokat a Cognos írja az adatbázisba
    3. Az ellenőrzési adatbázis több mint egy éve használatban van
    4. A környezet nagyon aktív a felhasználók és a végrehajtások között
    5. Az audit csomagot a Cognos használati adatok felszínre hozására használják
    6. Javítani szeretnénk az Audit Database jelentési teljesítményét
    7. A régi rekordok újrakezdése vagy törlése nem mindig választható

Ha még nem tette meg, telepítse és konfigurálja a Cognos Audit programot, a Lodestar Solutions, a Motio partner, kiváló Hozzászólás az Audit engedélyezéséről a Cognos BI /CA -ban.

A megoldás

Van néhány lehetséges megoldás, amelyek gyorsan bemutatkoznak:

    1. Csökkentse az adatok mennyiségét:
        • A régebbi adatok egy részének áthelyezése egy másik adatbázisba
        • A régebbi adatok egy részének áthelyezése ugyanazon adatbázis másik táblájába
    2. Csak törölje vagy íveljehive néhány adatot, és ne aggódjon emiatt
    3. Élj vele. Dobja le a konzervdobozt road és nyomja meg az adatbázis -adminisztrátort a teljesítmény érdekében
      fejlesztések, miközben megbilincselik őket azzal, hogy nem teszik lehetővé a séma módosítását, ill
      indexek

Nem fogunk foglalkozni a 3. opcióval. A 2. lehetőség, az adatok törlése, nem jó megoldás, és azt javaslom, hogy tartson legalább 18 havi értéket. De ha ennyire hajlik, az IBM biztosít egy segédprogramot, AuditDBCleanup (Cognos BI) vagy a forgatókönyv (Cognos Analytics), amely pontosan ezt fogja tenni. A Cognos BI segédprogramja időbélyeg alapján törli a rekordokat, míg a Cognos Analytics szkriptjei csak az indexeket és táblázatokat törlik.

A korábban az ügyfeleknek tett ajánlásaink szerint két adatbázisra kell bontani:

    1. Audit - Live: tartalmazza a legutóbbi heti adatokat
    2. Audit - Történelmi: történelmi adatokat tartalmaz (legfeljebb N év)

Röviden, a folyamat hetente fut, hogy a legfrissebb rekordokat áthelyezze az Audit Live -ból az Audit Historical -ba. A folyamat lefutása után az Audit Live üres lapként kezdődik.

    1. A Live DB gyors és szoros, így a betétek a lehető leggyorsabban megtörténhetnek
    2. Az ellenőrzési lekérdezések kizárólag a Történelmi DB -re irányulnak

Ezt a megközelítést alkalmazva nincs közvetett „összefűzés” az élő adatokból és a történelmi adatokból. Azt vitatnám, hogy valószínűleg így is akarja tartani.

A Cognos Administration alkalmazásban két különböző kapcsolatot adhat hozzá a naplózási adatforráshoz. Amikor egy felhasználó jelentést futtat az audit csomag ellen, a rendszer megkérdezi, hogy melyik kapcsolatot szeretné használni:

Ellenőrzési adatbázisok

Abban az esetben, ha az élő ellenőrzési adatokat szeretné megtekinteni, nem pedig a korábbi ellenőrzési adatokat, akkor válassza ki az „Audit - Live” kapcsolatot, amikor a rendszer kéri (ez kivétel, nem pedig norma).

Ha TÉNYLEGESen konszolidált képet szeretne adni mind az Élő, mind a Történelmi adatokról, akkor megteheti, de ez hatással lesz a teljesítményre.

Létrehozhat például egy harmadik adatbázist „Ellenőrzés - összevont nézet” néven, majd az ellenőrzési séma minden táblájához hozzon létre egy azonos nevű nézetet, amely SQL -unió az élő DB táblája és a táblázat között. történelmi DB. Hasonlóképpen ezt el lehet érni a Framework Manager modellben is, de ismét a teljesítmény lenne a legfontosabb szempont.

Néhány ügyfelünk összevont nézetet hozott létre. Véleményünk szerint ez valószínűleg túlzás. Ebben a konszolidált nézetben a teljesítmény mindig rosszabb lenne, és nem sok felhasználási esettel találkoztunk, amelyek mind az élő adatkészleteket, mind az előzményeket használják. Az Élő a hibaelhárításra, a Történelmi pedig a trendjelentésre szolgál.

A Cognos Analytics 11.1.7 verziójától kezdve az ellenőrzési adatbázis 21 táblára nőtt. További információt talál az Audit Database más részein, az ellenőrzési jelentések mintáin és a Framework Manager modellben. Az alapértelmezett naplózási szint Minimális, de érdemes használni a következő szintet, az Alapot a használati kérelmek, a felhasználói fiókok kezelése és a futásidejű használat rögzítéséhez. A rendszer teljesítményének fenntartásának egyik módja az, hogy a naplózási szintet a szükséges legalacsonyabb szinten tartja. Nyilvánvaló, hogy minél több naplózást végez a szerver, annál nagyobb hatással lehet a szerver általános teljesítményére.

A legfontosabb táblázatok, amelyek a legtöbb adminisztrátort érdeklik, a 6 táblázat, amelyek naplózzák a felhasználói tevékenységeket és a jelentési tevékenységeket a rendszerben.

  • COGIPF_USERLOGON: Tárolja a felhasználói bejelentkezési információkat (beleértve a kijelentkezést)
  • COGIPF_RUNREPORT: A jelentések végrehajtásával kapcsolatos információkat tárolja
  • COGIPF_VIEWREPORT: A jelentésmegtekintési kérésekkel kapcsolatos információkat tárolja
  • COGIPF_EDITQUERY: A lekérdezésfuttatásokra vonatkozó információkat tárolja
  • COGIPF_RUNJOB: Az álláskérésekkel kapcsolatos információkat tárolja
  • COGIPF_ACTION: Rögzíti a felhasználói műveleteket a Cognos alkalmazásban (ez a táblázat sokkal gyorsabban nőhet, mint a többi)

A kész konfiguráció így néz ki:

Alapértelmezett ellenőrzési konfiguráció

Ajánlott konfiguráció:

Ajánlott ellenőrzési konfiguráció

A Cognos Audit Database - Live 1 hetes ellenőrzési adatokat tartalmaz. Az 1 hétnél régebbi adatok átkerülnek a Cognos Audit Database - Historical -ba.

A diagramon található Cognos Audit Database - Live to Cognos Audit Database - Historical sor a következő feladatokért felelős:

  • Adatok másolása az élő auditból a történelmi auditba
  • Távolítsa el az élő audit minden sorát, amely 1 hétnél régebbi
  • Távolítsa el az összes sort, amely régebbi, mint x év
  • Távolítsa el a COGIPF_ACTION összes 6 hónapnál régebbi sorát

Indexek

A különböző adatbázis -típusoknak különböző indexelési típusai vannak. Az adatbázis -index egy táblázathoz (vagy nézethez) társított adatstruktúra, amelyet a lekérdezések végrehajtási idejének javítására használnak, amikor lekérik az adatokat a táblázatból (vagy nézetből). Dolgozzon együtt a DBA -val az optimális stratégia létrehozásához. Tudni akarják az ilyen kérdésekre adott válaszokat, hogy a legjobb döntést hozzák az indexelni kívánt oszlopokról. Nyilvánvaló, hogy az adatbázis -adminisztrátor az Ön segítsége nélkül megtalálhatja a válaszokat néhány vagy mindegyik kérdésre, de ehhez némi kutatás és némi idő kell:

  • Hány rekordja van a tábláknak, és mekkora méretűre számítanak? (A táblázat indexelése nem lesz hasznos, kivéve, ha a táblázat nagy számú rekordot tartalmaz.)
  • Tudod, hogy melyik oszlop egyedi? Engedélyezik a NULL értékeket? Mely oszlopok adattípusa egész vagy nagy egész? (A numerikus adattípusokat tartalmazó, egyedi és NOT NULL oszlopok erős jelöltek az indexkulcsban való részvételre.)
  • Hol vannak ma a fő teljesítményproblémák? Ők keresik az adatokat? Vannak olyan speciális lekérdezések vagy jelentések, amelyek nagyobb problémát jelentenek? (Ez az adatbázis rendszergazdáját bizonyos optimalizálható oszlopokhoz vezetheti.)
  • Milyen mezőket használnak a táblázatok összekapcsolásához a jelentésekhez?
  • Milyen mezőket használnak a szűréshez, rendezéshez, csoportosításhoz és összesítéshez?

Nem meglepő, hogy ugyanazokat a kérdéseket kell megválaszolni az adatbázis -táblák teljesítményének javítása érdekében.

IBM támogatás ajánlja index létrehozása a „COGIPF_REQUESTID”, „COGIPF_SUBREQUESTID” és „COGIPF_STEPID” oszlopokban a következő táblázatokhoz a teljesítmény javítása érdekében:

  • COGIPF_NATIVEQUERY
  • COGIPF_RUNJOB
  • COGIPF_RUNJOBSTEP
  • COGIPF_RUNREPORT
  • COGIPF_EDITQUERY

Plusz más kevésbé használt táblázatokon:

  • COGIPF_POWERPLAY
  • COGIPF_HUMANTASKSERVICE
  • COGIPF_HUMANTASKSERVICE_DETAIL

Ezt kiindulópontként használhatja, de én végigvinném a fenti kérdések megválaszolásának gyakorlatát, hogy a szervezete számára a legjobb választ kapjuk.

egyéb szempontok

  1. Audit FM modell. Ne feledje, hogy az IBM által biztosított Framework Manager modell az alapértelmezett táblázatok és mezők alapján készült. A jelentéstáblázatokban végrehajtott változtatásokat tükrözni kell a modellben. A változtatások egyszerűsége vagy összetettsége - vagy az Ön szervezeti kompetenciája a változtatások végrehajtásához - befolyásolhatja a választott megoldást.
  2. További mezők. Ha ezt megteszi, akkor itt az ideje, hogy további mezőket adjon hozzá a környezeti vagy referenciaadatokhoz az auditjelentések javítása érdekében.
  3. Összefoglaló táblázatok. Ahelyett, hogy csak lemásolná az adatokat a történelmi táblázatba, tömörítse azokat. Összevonhatja az adatokat a napi szintre, hogy hatékonyabbá tegye a jelentéstételt.
  4. Nézetek táblázatok helyett. Mások azt mondják: „Tehát ahelyett, hogy„ aktuális ”és„ történelmi ”adatbázisa lenne, csak egy adatbázisa legyen, és az összes táblázatot„ történelmi ”előtaggal kell ellátni. Ezután létre kell hoznia egy nézethalmazt, egyet minden egyes táblázathoz, amelyet „aktuálisnak” szeretne látni, és minden nézetnek ki kell szűrnie azokat a történelmi sorokat, amelyeket nem szeretne látni, és csak az aktuálisakat engedi át. ”
    https://softwareengineering.stackexchange.com/questions/276395/two-database-architecture-operational-and-historical/276419#276419

Következtetés

A lényeg az, hogy az itt megadott információkkal jól fel kell készülnie arra, hogy produktív beszélgetést folytasson a DBA -val. Jó eséllyel már korábban is megoldott hasonló problémákat.

A Cognos Audit Database architektúrájában javasolt változtatások javítani fogják a teljesítményt mind a közvetlen jelentések, mind az arra támaszkodó harmadik féltől származó alkalmazások esetében, mint pl. Motio'S ReportCard és Leltár.

Egyébként, ha ezt a beszélgetést folytatta a DBA -val, szívesen hallunk róla. Szeretnénk hallani azt is, hogy megoldotta -e a rosszul teljesítő ellenőrzési adatbázis problémáját, és hogyan tette ezt.