Cognos Auditing Blog - Savjeti i trikovi za okruženja velikih i velikih količina

Blog Johna Boyera i Mikea Norrisa.

Uvod

Važno je da sposobnost Cognos Auditing radi kako biste znali i razumjeli kako Cognos koristi vaša korisnička zajednica i pomogli u odgovorima na pitanja poput:

• • Ko koristi sistem?
  • Koje izvještaje vode?
  • Koje je vrijeme izvođenja izvještaja?
  • Uz pomoć drugih alata, npr MotioCI, koji sadržaj nije iskorišten?

S obzirom na to koliko je važno održavati zdravo okruženje Cognos Analytics, iznenađujuće je malo napisano o njegovoj revizorskoj bazi podataka izvan standardne dokumentacije o proizvodu. Možda se to uzima zdravo za gotovo, ali organizacije koje ga koriste znaju da će s vremenom upiti u tablice Audit Database početi usporavati - pogotovo ako vaša organizacija ima mnogo korisnika koji pokreću mnogo izvještaja i imaju mnogo povijesti. Štaviše, i samo bilježenje aktivnosti revizije može kasniti jer se stavlja u red ako se, na primjer, ne može dodati u bazu podataka dovoljno brzo. Tada počinjete razmišljati o performansama baze podataka kao o svakoj operativnoj bazi podataka koja ima zahtjeve za izvještavanje.

Velike tablice obično usporavaju performanse upita. Što je tabela veća, potrebno je više vremena za umetanje i postavljanje upita. Upamtite da su ove tablice i baza podataka revizije u osnovi operativna baza podataka; pisanja se događaju često i rade protiv nas jer ih ne možemo usredotočiti samo na operacije čitanja kao što biste to učinili s podatkovnim omjerom.

Slično kao i skladište sadržaja, zdravlje Cognos okruženja također mora uzeti u obzir zdravlje baze podataka revizije. Neograničeni rast baze podataka revizije može postati problem s vremenom i na kraju može čak utjecati na ukupne performanse Cognos okruženja. U mnogim organizacijama sa spoljašnjim propisima, nepostojanje potpune revizorske evidencije može ih dovesti u situaciju neusklađenosti sa velikim posljedicama. Dakle, kako se nositi s tim da moramo čuvati toliko podataka za potrebe historijske revizije - u nekim slučajevima i do 10 godina - a opet dobiti izvještaje koji su nam potrebni za održavanje okoliša i održavanje zadovoljstva korisnika učinkom?

Izazov

• • Neograničeni rast baze podataka revizije negativno utiče na zdravlje Cognos okruženja
  • Izvještavanje iz revizijske baze podataka postalo je sporo ili neupotrebljivo
  • Cognos ima kašnjenja u pisanju zapisa u revizorsku bazu podataka
  • Audit Database ponestaje prostora na disku

Sve ovo znači da ne pate samo izvještaji koji se oslanjaju na revizorsku bazu podataka, već često i cijeli sistem. Ako je baza podataka revizije na istom poslužitelju s Cognos spremištem sadržaja, to će utjecati na performanse svih stvari koje Cognos ima u tom okruženju.

Setup

Pretpostavljamo:

1. 1. Cognos Analytics je instaliran i radi
   2. Cognos je konfiguriran za prijavu u revizorsku bazu podataka
   1. • Postavite revizorsku bazu podataka
      • Postavite odgovarajuće nivoe evidentiranja revizije u Cognos administraciji
      • Cognos zapisuje zapise u bazu podataka
   3. Revizorska baza podataka je u upotrebi više od godinu dana
   4. Okruženje je vrlo aktivno s korisnicima i izvršenjima
   5. Paket Audit se koristi za prikaz podataka o upotrebi Cognosa
   6. Želimo poboljšati performanse izvještavanja revizijske baze podataka
   7. Pokretanje ili brisanje starih zapisa nije uvijek opcija

Ako još niste, instalirajte i konfigurirajte Cognos Audit, Lodestar Solutions, a Motio partner, ima odlično pošta o omogućavanju revizije u Cognos BI /CA.

Rjesenje

Postoji nekoliko mogućih rješenja koja se brzo predstavljaju:

1. 1. Smanjite količinu podataka za:
   1. • Premještanje nekih starijih podataka u drugu bazu podataka
      • Premještanje nekih starijih podataka u drugu tablicu u istoj bazi podataka
   2. Samo izbrišite ili napravite lukhive neke podatke i ne brinite zbog toga
   3. Živite s tim. Spustite limenku road i gurnite administratora baze podataka za performanse
      poboljšanja dok im se stavljaju lisice tako što se ne dopuštaju izmjene sheme ili
      indekse

Nećemo se baviti opcijom 3. Opcija 2, brisanje podataka, nije dobra opcija i preporučio bih da vrijednost od najmanje 18 mjeseci bude minimalna. Ali, ako ste toliko skloni, IBM nudi uslužni program, AuditDBCleanup (Cognos BI) ili a skripta (Cognos Analytics) koji će učiniti upravo to. Pomoćni program za Cognos BI briše zapise na temelju vremenske oznake, dok skripte za Cognos Analytics samo brišu indekse i tablice.

Preporuke koje smo prethodno dali klijentima o tome bile su da se odvoje u dvije baze podataka:

1. 1. Revizija - uživo: sadrži podatke za posljednju sedmicu
   2. Revizija - Historijska: sadrži historijske podatke (do N godina)

Ukratko, proces se odvija tjedno za premještanje najnovijih zapisa iz Audit Live u Audit Historical. Audit Live počinje ponovo kao prazna ploča nakon što se ovaj proces pokrene.

1. 1. Live DB je brz i čvrst, omogućavajući umetanje što je brže moguće
   2. Revizijski upiti se isključivo upućuju na Istorijsku bazu podataka

Koristeći ovaj pristup, ne postoji implicitno „spajanje“ podataka uživo i povijesnih podataka. Tvrdio bih da vjerovatno želite da tako i ostane.

U administraciji Cognos možete dodati dvije različite veze za izvor podataka revizije. Kada korisnik pokrene izvještaj o paketu Audit, od njega će biti zatraženo koju vezu želi koristiti:

U slučaju da želite pogledati podatke revizije uživo, a ne povijesne podatke, samo odaberete vezu „Revizija - uživo“ kada se to od vas zatraži (to bi trebao biti izuzetak, a ne norma.)

Ako STVARNO želite pružiti i konsolidirani prikaz uživo i historije, mogli biste to učiniti, ali to bi utjecalo na performanse.

Na primjer, mogli biste stvoriti treću bazu podataka pod nazivom „Revizija - konsolidirani prikaz“, a zatim za svaku tablicu u shemi revizije: stvoriti identično nazvan pogled koji predstavlja SQL uniju između tablice u aktivnoj bazi podataka i tablice u istorijski DB. Slično, ovo bi se moglo postići i u modelu Framework Managera, ali opet bi performanse bile ključno pitanje.

Neki od naših klijenata stvorili su konsolidirani prikaz. Naše je mišljenje da je ovo vjerovatno pretjerano. Performanse bi u ovom konsolidiranom prikazu uvijek bile lošije i nismo naišli na mnogo slučajeva upotrebe koji koriste i skupove podataka uživo i povijesnu. Live se koristi za rješavanje problema, a Historical za izvještavanje o trendovima.

Od Cognos Analytics 11.1.7, baza podataka revizije je porasla na 21 tablicu. Više informacija možete pronaći na drugom mjestu u Revizorskoj bazi podataka, uzorcima revizorskih izvještaja i modelu Framework Managera. Zadani nivo bilježenja je Minimalni, ali možda ćete htjeti koristiti sljedeći nivo, Osnovni, za snimanje zahtjeva za upotrebom, upravljanje korisničkim nalogom i korištenje za vrijeme izvođenja. Jedan od načina na koji možete održati performanse sistema je držanjem razine evidentiranja na najnižoj potrebnoj razini. Očigledno, što server više vodi evidentiranje, to može utjecati na ukupne performanse servera.

Ključne tablice koje će zanimati većinu administratora su 6 tablica koje bilježe aktivnosti korisnika i aktivnosti izvještavanja u sistemu.

• COGIPF_USERLOGON: Pohranjuje informacije o prijavi korisnika (uključujući odjavu)
• COGIPF_RUNREPORT: Pohranjuje informacije o izvršenjima izvještaja
• COGIPF_VIEWREPORT: Pohranjuje informacije o zahtjevima za pregled izvještaja
• COGIPF_EDITQUERY: Pohranjuje informacije o pokretanju upita
• COGIPF_RUNJOB: Pohranjuje informacije o zahtjevima za posao
• COGIPF_ACTION: Bilježi korisničke radnje u Cognosu (ova tablica može rasti mnogo brže od ostalih)

Konfiguracija koja se nalazi u kutiji izgleda ovako:

Preporučena konfiguracija:

Cognos revizijska baza podataka - uživo sadrži jednu sedmicu revizijskih podataka. Podaci stariji od jedne sedmice premještaju se u bazu podataka Cognos Audit - Historijski.

Redak iz Cognos Audit Database - Live to Cognos Audit Database - Historijski na dijagramu je odgovoran za:

• Kopiranje podataka iz revizije uživo u reviziju historije
• Uklonite sve redove u reviziji uživo koji su stariji od jedne sedmice
• Uklonite sve redove u Historijskoj reviziji koji su stariji od x godina
• Uklonite sve redove u COGIPF_ACTION koji su stariji od 6 mjeseci

indeksi

Različiti tipovi baza podataka imaju različite tipove indeksiranja. Indeks baze podataka je struktura podataka povezana s tablicom (ili prikazom) koja se koristi za poboljšanje vremena izvršavanja upita prilikom preuzimanja podataka iz te tablice (ili prikaza). Radite sa svojim DBA -om na stvaranju optimalne strategije. Oni će htjeti znati odgovore na ovakva pitanja kako bi donijeli najbolje odluke o tome koje kolone indeksirati. Očigledno je da bi administrator baze podataka mogao saznati odgovore na neka ili sva ova pitanja bez vaše pomoći, ali za to će biti potrebno malo istraživanja i neko vrijeme:

• Koliko zapisa imaju tablice i do koje veličine očekujete da će rasti? (Indeksiranje tablice neće biti korisno osim ako tablica ima veliki broj zapisa.)
• Znate li koje su kolone jedinstvene? Dopuštaju li NULL vrijednosti? Koji stupci imaju tip podataka cijeli ili veliki broj? (Stupci s numeričkim tipovima podataka koji su JEDINSTVENI i NISU NULL jaki su kandidati za učešće u ključu indeksa.)
• Gdje su danas vaši glavni problemi s performansama? Da li oni preuzimaju podatke? Postoje li specifični upiti ili izvještaji koji predstavljaju veći problem? (Ovo može dovesti administratora baze podataka do određenih stupaca koji se mogu optimizirati.)
• Koja se polja koriste za pridruživanje tabela za izvještavanje?
• Koja se polja koriste za filtriranje, sortiranje, grupiranje i agregiranje?

Nije iznenađujuće da su to ista pitanja na koja je potrebno odgovoriti radi poboljšanja performansi bilo koje tablice baze podataka.

IBM podrška preporučuje stvaranje indeksa u stupcima “COGIPF_REQUESTID”, “COGIPF_SUBREQUESTID” i “COGIPF_STEPID” za sljedeće tablice radi poboljšanja performansi:

• COGIPF_NATIVEQUERY
• COGIPF_RUNJOB
• COGIPF_RUNJOBSTEP
• COGIPF_RUNREPORT
• COGIPF_EDITQUERY

Plus na drugim manje korišćenim stolovima:

• COGIPF_POWERPLAY
• COGIPF_HUMANTASKSERVICE
• COGIPF_HUMANTASKSERVICE_DETAIL

Ovo možete koristiti kao polazište, ali ja bih prošao kroz vježbu odgovaranja na gornja pitanja kako bih došao do najboljeg odgovora za vašu organizaciju.

Ostala razmatranja

1. Revizija FM modela. Upamtite da je model Framework Managera koji IBM pruža modeliran na default tablicama i poljima. Sve promjene koje unesete u tablice izvještaja morat će se odraziti u modelu. Lakoća ili složenost ovih promjena - ili vaša organizacijska sposobnost da izvršite te promjene - mogu utjecati na rješenje koje odaberete.
2. Dodatna polja. Ako ćete to učiniti, sada je vrijeme za dodavanje dodatnih polja za kontekst ili referentne podatke radi poboljšanja revizijskog izvještavanja.
3. Sažete tabele. Umjesto da samo kopirate podatke u svoju povijesnu tablicu, komprimirajte ih. Možete agregirati podatke na dnevni nivo kako bi bili učinkovitiji za izvještavanje.
4. Prikazi umjesto tablica. Drugi kažu: „Dakle, umjesto da imate„ trenutnu “bazu podataka i„ povijesnu “bazu podataka, trebali biste imati samo jednu bazu podataka, a sve tablice u njoj trebaju imati prefiks sa„ povijesna “. Zatim biste trebali stvoriti skup prikaza, po jedan za svaku tablicu koju želite vidjeti kao "trenutnu", a svaki prikaz filtrirati povijesne redove koje ne želite vidjeti i pustiti da prođu samo trenutni. "
   https://softwareengineering.stackexchange.com/questions/276395/two-database-architecture-operational-and-historical/276419#276419

zaključak

Zaključak je da bi se s ovdje danim informacijama trebali dobro pripremiti za produktivan razgovor sa svojim administratorom za administraciju. Velike su šanse da je i ranije rješavala slične probleme.

Predložene izmjene u arhitekturi baze podataka Cognos Audit poboljšat će performanse i u direktnom izvještavanju, i u aplikacijama trećih strana koje se na to oslanjaju, poput Motio's ReportCard i Inventar.

Usput, ako ste imali taj razgovor sa svojim administratorom uprave, voljeli bismo čuti o tome. Također bismo voljeli čuti jeste li riješili problem loše revizijske baze podataka i kako ste to učinili.