Blog Johna Boyera i Mikea Norrisa.
Uvod
Važno je da sposobnost Cognos Auditing radi kako bi znali i razumjeli kako Cognos koristi vaša korisnička zajednica i pomogli u odgovorima na pitanja poput:
-
- Tko koristi sustav?
- Koja izvješća vode?
- Koje je vrijeme izvođenja izvješća?
- 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 Analyticsa, iznenađujuće je malo napisano o njegovoj revizijskoj bazi podataka izvan standardne dokumentacije o proizvodu. Možda se to uzima zdravo za gotovo, ali organizacije koje ga koriste znaju da će se s vremenom upiti u tablice Audit Database početi usporavati - osobito ako vaša organizacija ima mnogo korisnika koji pokreću mnoga izvješća i imaju mnogo povijesti. Štoviše, samo bilježenje revizijske aktivnosti 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šćivanjem.
Velike tablice obično usporavaju izvedbu upita. Što je tablica 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; zapisi 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 s vanjskim propisima, nepostojanje potpune revizijske evidencije može ih dovesti u situaciju neusklađenosti s velikim posljedicama. Dakle, kako se nositi s tim da moramo čuvati toliko podataka za potrebe povijesne revizije - u nekim slučajevima i do 10 godina - a opet dobiti izvješća koja su nam potrebna za održavanje okoliša i održavanje zadovoljstva korisnika učinkom?
Izazov
-
- Neograničeni rast baze podataka revizije negativno utječe na zdravlje okoliša Cognos
- Izvještavanje iz revizijske baze podataka postalo je sporo ili neupotrebljivo
- Cognos ima kašnjenja u pisanju zapisa u revizijsku bazu podataka
- Audit Database ponestaje prostora na disku
Sve to znači da ne pate samo izvješća koja se oslanjaju na revizijsku bazu podataka, već često i cijeli sustav. Ako je Audit Database na istom poslužitelju s Cognos spremištem sadržaja, to će utjecati na izvedbu svih stvari koje Cognos ima u tom okruženju.
Postava
Pretpostavljamo:
-
- Cognos Analytics je instaliran i radi
- Cognos je konfiguriran za prijavu u revizijsku bazu podataka
-
- Postavite revizorsku bazu podataka
- Postavite odgovarajuće razine evidentiranja revizije u administraciji Cognosa
- Cognos zapisuje zapise u bazu podataka
- Revizorska baza podataka koristi se više od godinu dana
- Okruženje je vrlo aktivno s korisnicima i izvršenjima
- Paket Audit koristi se za prikaz podataka o upotrebi Cognosa
- Želimo poboljšati performanse izvješćivanja o reviziji baze podataka
- Pokretanje ili brisanje starih zapisa nije uvijek opcija
Ako još niste, instalirajte i konfigurirajte Cognos Audit, Lodestar Solutions, a Motio partner, ima izvrsnu pošta o omogućavanju revizije u Cognos BI /CA.
Rješenje
Postoji nekoliko mogućih rješenja koja se brzo predstavljaju:
-
- Smanjite količinu podataka za:
-
- Premještanje nekih starijih podataka u drugu bazu podataka
- Premještanje nekih starijih podataka u drugu tablicu u istoj bazi podataka
- Samo izbrišite ili lukhive neke podatke i ne brinite zbog toga
- Živite s tim. Spustite limenku road i gurnite administratora baze podataka za performanse
poboljšanja dok im se stavljaju lisice ne dopuštajući izmjene sheme ili
indeksi
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. No, ako ste toliko skloni, IBM nudi uslužni program, AuditDBCleanup (Cognos BI) ili a rukopis (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:
-
- Revizija - uživo: sadrži podatke najnovijeg tjedna
- Revizija - povijesna: sadrži povijesne podatke (do N godina)
Ukratko, proces se odvija tjedno za premještanje najnovijih zapisa iz Audit Live u Audit Historical. Audit Live počinje nakon početka ovog procesa kao prazna ploča.
-
- Live DB je brz i čvrst, što omogućuje umetanje što je brže moguće
- Revizijski upiti isključivo su usmjereni na Povijesni DB
Koristeći ovaj pristup, ne postoji implicitno „spajanje“ podataka uživo i povijesnih podataka. Tvrdio bih da vjerojatno želite tako i ostati.
U administraciji Cognos možete dodati dvije različite veze za izvor podataka revizije. Kada korisnik pokrene izvješće 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 revizije, samo odaberete vezu "Revizija - uživo" kada se to od vas zatraži (trebala bi biti iznimka, a ne norma.)
Ako STVARNO želite pružiti i konsolidirani prikaz uživo i povijesti, 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 povijesni DB. Slično, to 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 to vjerojatno pretjerano. U ovom konsolidiranom prikazu performanse bi uvijek bile lošije i nismo naišli na mnogo slučajeva korištenja koji koriste i skupove podataka uživo i povijesne. Live se koristi za rješavanje problema, a Historical za izvješćivanje o trendovima.
Od Cognos Analyticsa 11.1.7, baza podataka revizije narasla je na 21 tablicu. Više informacija možete pronaći na drugom mjestu u Revizorskoj bazi podataka, uzorcima revizorskih izvješća i modelu Framework Managera. Zadana razina bilježenja je Minimalna, ali možda ćete htjeti upotrijebiti sljedeću razinu, Osnovnu, za snimanje zahtjeva za upotrebom, upravljanje korisničkim računom i korištenje tijekom izvođenja. Jedan od načina na koji možete održati performanse sustava je držanje razine bilježenja na najnižoj potrebnoj razini. Očigledno, što poslužitelj više zapisuje, to može utjecati na ukupnu izvedbu poslužitelja.
Ključne tablice koje će zanimati većinu administratora su 6 tablica koje bilježe aktivnosti korisnika i aktivnosti izvješćivanja u sustavu.
- COGIPF_USERLOGON: Pohranjuje podatke o prijavi korisnika (uključujući odjavu)
- COGIPF_RUNREPORT: Pohranjuje podatke o izvršenjima izvješća
- COGIPF_VIEWREPORT: Pohranjuje informacije o zahtjevima za pregled izvješća
- COGIPF_EDITQUERY: Pohranjuje informacije o pokretanju upita
- COGIPF_RUNJOB: Pohranjuje podatke o zahtjevima za posao
- COGIPF_ACTION: Bilježi radnje korisnika u Cognosu (ova tablica može rasti mnogo brže od ostalih)
Isporučena konfiguracija izgleda ovako:
Preporučena konfiguracija:
Cognos revizijska baza podataka - uživo sadrži tjedne revizijske podatke. Podaci stariji od tjedan dana premještaju se u bazu podataka Cognos Audit - Povijesno.
Redak iz Cognos Audit Database - Live to Cognos Audit Database - Povijesno na dijagramu odgovoran je za:
- Kopiranje podataka iz revizije uživo u povijesnu reviziju
- Uklonite sve retke u reviziji uživo koji su stariji od tjedan dana
- Uklonite sve retke u Povijesnoj reviziji koji su stariji od x godina
- Uklonite sve retke u COGIPF_ACTION koji su stariji od 6 mjeseci
Indeksi
Različite vrste baza podataka imaju različite vrste indeksiranja. Indeks baze podataka je struktura podataka povezana s tablicom (ili prikazom) koja se koristi za poboljšanje vremena izvršavanja upita pri dohvaćanju podataka iz te tablice (ili pogleda). Surađujte sa svojim DBA -om kako biste stvorili optimalnu strategiju. Oni će htjeti znati odgovore na ovakva pitanja kako bi donijeli najbolje odluke o tome koje stupce 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 je 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 koji su stupci jedinstveni? Dopuštaju li NULL vrijednosti? Koji stupci imaju vrstu podataka cijeli ili veliki cijeli broj? (Stupci s numeričkim vrstama podataka koji su JEDINSTVENI i NISU NULL jaki su kandidati za sudjelovanje u indeksnom ključu.)
- Gdje su vam danas glavni problemi s performansama? Jesu li u dohvaćanju podataka? Postoje li specifični upiti ili izvješća koja predstavljaju veći problem? (To može dovesti administratora baze podataka do određenih stupaca koji se mogu optimizirati.)
- Koja se polja koriste za pridruživanje tablica za izvješćivanje?
- Koja se polja koriste za filtriranje, razvrstavanje, grupiranje i združivanje?
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 izvedbe:
- COGIPF_NATIVEQUERY
- COGIPF_RUNJOB
- COGIPF_RUNJOBSTEP
- COGIPF_RUNREPORT
- COGIPF_EDITQUERY
Plus na drugim manje korištenim stolovima:
- COGIPF_POWERPLAY
- COGIPF_HUMANTASKSERVICE
- COGIPF_HUMANTASKSERVICE_DETAIL
Možete koristiti ovo 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
- Revizija FM modela. Upamtite da je model Framework Managera koji IBM pruža modeliran na zadanim tablicama i poljima. Sve promjene koje napravite u tablicama izvješćivanja morat će se odraziti u modelu. Lakoća ili složenost ovih promjena - ili vaša organizacijska sposobnost da napravite te promjene - mogu utjecati na rješenje koje odaberete.
- Dodatna polja. Ako ćete to učiniti, sada je vrijeme za dodavanje dodatnih polja za kontekst ili referentne podatke radi poboljšanja revizijskog izvješćivanja.
- Sažete tablice. Umjesto da samo kopirate podatke u povijesnu tablicu, komprimirajte ih. Možete agregirati podatke na dnevnu razinu kako bi bili učinkovitiji za izvješćivanje.
- 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 s„ povijesna “. Zatim biste trebali stvoriti skup prikaza, po jedan za svaku tablicu koju želite vidjeti kao "trenutačnu", a svaki prikaz filtrirati povijesne retke 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 podacima 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 Cognos Audit Database poboljšat će performanse i u izravnom izvješćivanju i u aplikacijama trećih strana koje se na to oslanjaju, poput Motio'S ReportCard i Inventar.
Usput, ako ste vodili 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.