Cognos Auditing Blog - Nasveti in zvijače za velika in obsežna okolja

Blog Johna Boyerja in Mikea Norrisa.

Predstavitev

Pomembno je, da zmožnost Cognos Auditing deluje, da bi vedeli in razumeli, kako Cognos uporablja vaša uporabniška skupnost, ter pomagali pri odgovarjanju na vprašanja, kot so:

• • Kdo uporablja sistem?
  • Kakšna poročila vodijo?
  • Kakšni so časi izvajanja poročila?
  • S pomočjo drugih orodij, npr MotioCI, katera vsebina je neuporabljena?

Glede na to, kako kritično je vzdrževanje zdravega okolja Cognos Analytics, je bilo presenetljivo malo napisanega o njegovi revizijski bazi podatkov, ki presega standardno dokumentacijo o izdelku. Morda je to samoumevno, vendar organizacije, ki ga uporabljajo, vedo, da se bodo sčasoma poizvedovanja po tabelah zbirke podatkov revizije začele upočasniti - še posebej, če ima vaša organizacija veliko uporabnikov, ki izvajajo velika poročila in imajo veliko zgodovine. Še več, samo beleženje revizijske dejavnosti lahko zamuja, ker je v čakalni vrsti, če je na primer ni mogoče dodati dovolj hitro v zbirko podatkov. Takrat začnete razmišljati o zmogljivosti zbirke podatkov tako kot pri vsaki operativni bazi podatkov, ki ima zahteve za poročanje.

Velike tabele običajno upočasnijo delovanje poizvedb. Večja kot je tabela, dlje traja vstavljanje in poizvedovanje. Ne pozabite, da sta tabeli in zbirka podatkov revizije v bistvu operativna baza podatkov; pisanja se pogosto dogajajo in delujejo proti nam, saj jih ne moremo osredotočiti samo na operacije branja, kot bi to storili s podatkovno zbirko.

Podobno kot trgovina z vsebinami mora tudi zdravje okolja Cognos upoštevati zdravje baze revizijskih podatkov. Neomejena rast revizijske zbirke podatkov lahko sčasoma postane problem in lahko sčasoma celo vpliva na splošno uspešnost okolja Cognos. V mnogih organizacijah, na katere se nanašajo zunanji predpisi, jih pomanjkanje popolnega revizijskega zapisa lahko privede v stanje neskladnosti s hudimi posledicami. Kako se torej spoprijeti s tem, da moramo hraniti toliko podatkov za namene revizije preteklosti - v nekaterih primerih tudi do 10 let -, a vseeno pridobiti poročila, ki jih potrebujemo za vzdrževanje okolja in zadovoljstvo uporabnikov z uspešnostjo?

Izziv

• • Neomejena rast zbirke revizijskih podatkov negativno vpliva na zdravje okolja Cognos
  • Poročanje iz revizijske zbirke podatkov je postalo počasno ali neuporabno
  • Cognos doživlja zamude pri zapisovanju zapisov v revizijsko bazo podatkov
  • V revizijski zbirki podatkov zmanjka prostora na disku

Vse to pomeni, da ne trpijo le poročila, ki temeljijo na revizijski bazi podatkov, ampak pogosto celoten sistem. Če je zbirka podatkov revizije na istem strežniku kot shramba vsebine Cognos, bo to vplivalo na delovanje vseh stvari, ki jih Cognos izvaja v tem okolju.

Nastavitve

Predvidevamo:

1. 1. Cognos Analytics je nameščen in se izvaja
   2. Cognos je konfiguriran za prijavo v revizijsko bazo podatkov
   1. • Vzpostavite revizijsko bazo podatkov
      • V administraciji Cognos nastavite ustrezne ravni beleženja revizije
      • Cognos v bazo zapisuje zapise
   3. Revizijska zbirka podatkov je v uporabi že več kot eno leto
   4. Okolje je zelo aktivno z uporabniki in izvedbami
   5. Paket Audit se uporablja za prikaz podatkov o uporabi Cognosa
   6. Prizadevamo si izboljšati uspešnost poročanja revizijske zbirke podatkov
   7. Zagon ali brisanje starih zapisov ni vedno možnost

Če tega še niste storili, morate namestiti in konfigurirati Cognos Audit, Lodestar Solutions, a Motio partner, ima odlično objava o omogočanju revizije v Cognos BI /CA.

Rešitev

Obstaja nekaj možnih rešitev, ki se hitro pojavijo:

1. 1. Zmanjšajte količino podatkov za:
   1. • Premik nekaterih starejših podatkov v drugo bazo podatkov
      • Premikanje nekaterih starejših podatkov v drugo tabelo v isti bazi podatkov
   2. Samo izbrišite ali ločitehive nekaj podatkov in naj vas to ne skrbi
   3. Živite s tem. Vrzi pločevinko navzdol road in za uspešnost potisnite skrbnika zbirke podatkov
      izboljšave, pri tem pa jim privežite lisice, tako da ne dovolite sprememb sheme oz
      indekse

Ne bomo obravnavali možnosti 3. Možnost 2, brisanje podatkov, ni dobra možnost in priporočam, da je vrednost vsaj 18 mesecev. Če pa ste tako nagnjeni, IBM ponuja pripomoček, AuditDBCleanup (Cognos BI) ali a script (Cognos Analytics), ki bo naredil točno to. Pripomoček za Cognos BI izbriše zapise na podlagi časovnega žiga, medtem ko skripti za Cognos Analytics samo izbrišejo indekse in tabele.

Priporočila, ki smo jih prej dali strankam o tem, so bila, da se ločijo v dve bazi podatkov:

1. 1. Revizija - v živo: vsebuje podatke za zadnji teden
   2. Revizija - zgodovinska: vsebuje zgodovinske podatke (do N let)

Skratka, postopek poteka tedensko, da se najnovejši zapisi premaknejo iz Audit Live v Audit Historical. Audit Live se po tem postopku začne znova kot prazna plošča.

1. 1. Live DB je hiter in tesen, kar omogoča čim hitrejše vstavljanje
   2. Revizijske poizvedbe so usmerjene izključno v zgodovinsko bazo podatkov

S tem pristopom ni implicitnega "spajanja" podatkov v živo in zgodovinskih podatkov. Rekel bi, da bi verjetno želeli, da tako ostane.

V administraciji Cognos lahko za vir podatkov revizije dodate dve različni povezavi. Ko uporabnik zažene poročilo v paketu Audit, bo pozvan, katero povezavo želi uporabiti:

Če si želite ogledati revizijske podatke v živo in ne pretekle revizijske podatke, na poziv preprosto izberete povezavo »Revizija - v živo« (to bi morala biti izjema, ne pravilo.)

Če res želite zagotoviti tudi konsolidiran vpogled v živo in zgodovino, bi to lahko storili, vendar bi to vplivalo na uspešnost.

Na primer, lahko ustvarite tretjo bazo podatkov, imenovano »Revizija - konsolidiran pogled«, nato pa za vsako tabelo v shemi revizije: ustvarite identično poimenovan pogled, ki je unija SQL med tabelo v zbirki podatkov v živo in tabelo v zgodovinski DB. Podobno bi bilo to mogoče doseči tudi v modelu Framework Managerja, vendar pa bi bila uspešnost ključnega pomena.

Nekatere naše stranke so ustvarile konsolidiran pogled. Menimo, da je to verjetno preveč. Učinkovitost bi bila v tem konsolidiranem pogledu vedno slabša in nismo naleteli na veliko primerov uporabe, ki uporabljajo tako nabore podatkov v živo kot zgodovino. Live za odpravljanje težav in Historical za poročanje o trendih.

Od Cognos Analytics 11.1.7 se je zbirka revizijskih podatkov povečala na 21 tabel. Več informacij najdete drugje v revizijski bazi podatkov, vzorčnih revizijskih poročilih in modelu Framework Manager. Privzeta raven beleženja je Minimalna, vendar boste morda želeli uporabiti naslednjo raven, Basic, da zajamete zahteve za uporabo, upravljanje uporabniškega računa in uporabo časa izvajanja. Eden od načinov, kako ohraniti delovanje sistema, je, da raven beleženja shranite na najnižjo zahtevano raven. Očitno je, da bolj ko se strežnik prijavi, več vpliva na splošno delovanje strežnika.

Ključne tabele, ki bodo zanimale večino skrbnikov, so 6 tabel, ki beležijo uporabnikovo dejavnost in poročanje o dejavnostih v sistemu.

• COGIPF_USERLOGON: Shrani podatke o prijavi uporabnika (vključno z odjavo)
• COGIPF_RUNREPORT: Shrani podatke o izvajanju poročil
• COGIPF_VIEWREPORT: Shrani podatke o zahtevah za ogled poročil
• COGIPF_EDITQUERY: Shrani podatke o izvajanju poizvedbe
• COGIPF_RUNJOB: Shrani podatke o prošnjah za zaposlitev
• COGIPF_ACTION: Zabeleži dejanja uporabnikov v Cognosu (ta tabela lahko raste veliko hitreje kot druge)

Konfiguracija, ki je na voljo, izgleda tako:

Priporočena konfiguracija:

Cognos Audit Database - Live vsebuje 1 teden revizijskih podatkov. Podatki, starejši od enega tedna, se premaknejo v zbirko podatkov Cognos Audit - zgodovinsko.

Vrstica iz zbirke podatkov Cognos Audit Database - Live to Cognos Audit Database - Zgodovina v diagramu je odgovorna za:

• Kopiranje podatkov iz revizije v živo v zgodovinsko revizijo
• Odstranite vse vrstice v reviziji v živo, ki so starejše od enega tedna
• Odstranite vse vrstice v reviziji zgodovine, starejše od x let
• Odstranite vse vrstice v COGIPF_ACTION, ki so starejše od 6 mesecev

Kazala

Različne vrste zbirk podatkov imajo različne vrste indeksiranja. Indeks zbirke podatkov je struktura podatkov, povezana s tabelo (ali pogledom), ki se uporablja za izboljšanje časa izvajanja poizvedb pri pridobivanju podatkov iz te tabele (ali pogleda). Sodelujte z vašim DBA, da ustvarite optimalno strategijo. Želeli bodo vedeti odgovore na takšna vprašanja, da se najbolje odločijo, katere stolpce bodo indeksirali. Očitno je, da bi lahko skrbnik baze podatkov izvedel odgovore na nekatera ali vsa ta vprašanja brez vaše pomoči, vendar bi trajalo nekaj raziskav in nekaj časa:

• Koliko zapisov imajo mize in v kakšni velikosti pričakujete, da bodo zrasle? (Indeksiranje tabele ne bo uporabno, razen če ima tabela veliko število zapisov.)
• Ali veste, kateri stolpci so edinstveni? Ali dovoljujejo vrednosti NULL? Kateri stolpci imajo podatkovno vrsto celega ali velikega števila? (Stolpci s številskimi vrstami podatkov, ki so UNIQUE in NOT NULL, so močni kandidati za sodelovanje pri indeksnem ključu.)
• Kje so danes vaše glavne težave z uspešnostjo? Ali pridobivajo podatke? Ali obstajajo posebna vprašanja ali poročila, ki predstavljajo večjo težavo? (To lahko vodi skrbnika baze podatkov do nekaterih posebnih stolpcev, ki jih je mogoče optimizirati.)
• Katera polja se uporabljajo pri združevanju tabel za poročanje?
• Katera polja se uporabljajo za filtriranje, razvrščanje, združevanje in združevanje?

Ni presenetljivo, da gre za ista vprašanja, na katera bi morali odgovoriti za izboljšanje delovanja vseh tabel zbirk podatkov.

IBM -ova podpora priporoča ustvarjanje indeksa v stolpcih »COGIPF_REQUESTID«, »COGIPF_SUBREQUESTID« in »COGIPF_STEPID« za naslednje tabele za izboljšanje učinkovitosti:

• COGIPF_NATIVEQUERY
• COGIPF_RUNJOB
• COGIPF_RUNJOBSTEP
• COGIPF_RUNREPORT
• COGIPF_EDITQUERY

Plus na drugih manj uporabljenih mizah:

• COGIPF_POWERPLAY
• COGIPF_HUMANTASKSERVICE
• COGIPF_HUMANTASKSERVICE_DETAIL

To lahko uporabite kot izhodišče, vendar bom skozi vajo odgovoril na zgornja vprašanja, da bi prišel do najboljšega odgovora za vašo organizacijo.

Drugi premisleki

1. Revizijski model FM. Ne pozabite, da model Framework Manager, ki ga ponuja IBM, temelji na privzetih tabelah in poljih. Vse spremembe, ki jih naredite v tabelah za poročanje, se bodo morale odražati v modelu. Enostavnost ali zapletenost teh sprememb - ali vaša organizacijska usposobljenost za te spremembe - lahko vpliva na izbrano rešitev.
2. Dodatna polja. Če boste to storili, je zdaj čas, da dodate dodatna polja za kontekstne ali referenčne podatke za izboljšanje revizijskega poročanja.
3. Povzetek tabel. Namesto da samo kopirate podatke v zgodovinsko tabelo, jih stisnite. Podatke lahko združite na dnevno raven, da bodo učinkovitejši za poročanje.
4. Pogledi namesto tabel. Drugi pravijo: "Torej, namesto da imate" trenutno "bazo podatkov in" zgodovinsko "bazo podatkov, morate imeti samo eno zbirko podatkov, vse tabele v njej pa morajo biti s predpono" zgodovinsko ". Nato morate ustvariti niz pogledov, enega za vsako tabelo, ki jo želite videti kot "trenutno", in naj vsak pogled izloči zgodovinske vrstice, ki jih ne želite videti, in pustite, da preidejo samo trenutne. "
   https://softwareengineering.stackexchange.com/questions/276395/two-database-architecture-operational-and-historical/276419#276419

zaključek

Bistvo je, da bi morali biti s temi informacijami dobro pripravljeni na produktiven pogovor s svojim oddelkom za upravljanje podatkov. Velike možnosti so, da je podobne težave že rešila.

Predlagane spremembe v arhitekturi zbirke podatkov revizije Cognos bodo izboljšale uspešnost tako pri neposrednem poročanju kot pri aplikacijah tretjih oseb, ki se nanj opirajo, npr. MotioJe ReportCard in Inventar.

Mimogrede, če ste imeli ta pogovor z vašim upravnim oddelkom za banko, bi radi to slišali. Prav tako bi radi slišali, če ste rešili težavo s slabo delujočo revizijsko zbirko podatkov in kako ste to storili.