Un blog de John Boyer și Mike Norris.
Introducere
Este important să aveți capacitatea de audit Cognos care să funcționeze pentru a cunoaște și a înțelege modul în care Cognos este utilizat de comunitatea dvs. de utilizatori și pentru a ajuta la răspunsuri la întrebări precum:
-
- Cine folosește sistemul?
- Ce rapoarte rulează?
- Care sunt timpii de rulare a raportului?
- Cu ajutorul altor instrumente, cum ar fi MotioCI, ce conținut este neutilizat?
Având în vedere cât este de important să menținem medii sănătoase Cognos Analytics, în mod surprinzător s-au scris puține despre baza sa de audit, dincolo de documentația standard a produsului. Poate că este considerat de la sine înțeles, dar organizațiile care îl folosesc știu că, în timp, interogarea tabelelor bazei de date de audit va începe să încetinească - mai ales dacă organizația dvs. are mulți utilizatori care rulează o mulțime de rapoarte și are mult istoric. Mai mult decât atât, jurnalizarea activității de audit în sine poate fi întârziată, deoarece este în așteptare atunci când nu poate fi adăugată la baza de date suficient de repede, de exemplu. Atunci începeți să vă gândiți la performanța bazei de date așa cum ați face cu orice bază de date operațională care are cerințe de raportare.
Tabelele mari de obicei încetinesc performanța interogării. Cu cât tabelul este mai mare, cu atât este nevoie de mai mult timp pentru a introduce și interoga. Amintiți-vă că aceste tabele și baza de date de audit sunt practic o bază de date operațională; scrisurile se întâmplă frecvent și lucrează împotriva noastră, deoarece nu le putem concentra doar pentru operații de citire așa cum ați face cu un martie de date.
La fel ca magazinul de conținut, sănătatea mediului Cognos trebuie să ia în considerare și sănătatea bazei de date de audit. Creșterea nelimitată a bazei de date de audit poate deveni o problemă în timp și poate avea un impact chiar asupra performanței generale a unui mediu Cognos. În multe organizații cu reglementări externe impuse asupra lor, lipsa unei înregistrări complete a auditului le poate pune într-o situație de neconformitate cu repercusiuni grele. Așadar, cum ne descurcăm cu faptul că trebuie să menținem atât de multe date în scopuri de audit istoric - în unele cazuri până la 10 ani - totuși primim totuși rapoartele de care avem nevoie pentru a menține mediul înconjurător și pentru a menține utilizatorii mulțumiți de performanță?
Provocarea
-
- Creșterea nelimitată a bazei de date de audit are un impact negativ asupra sănătății mediului Cognos
- Raportarea din baza de date de audit a devenit lentă sau inutilizabilă
- Cognos experimentează întârzieri în înregistrările scrise în baza de date de audit
- Baza de date de audit rămâne fără spațiu pe disc
Toate acestea înseamnă că suferă nu doar rapoartele care se bazează pe baza de date de audit, ci adesea întregul sistem. Dacă baza de date de audit se află pe același server cu magazinul de conținut Cognos, performanța tuturor lucrurilor Cognos va fi afectată în acel mediu.
Setup
Presupunem:
-
- Cognos Analytics este instalat și rulează
- Cognos este configurat pentru a se conecta la o bază de date de audit
-
- Aveți la dispoziție o bază de date de audit
- Setați niveluri adecvate de înregistrare a auditului în administrarea Cognos
- Înregistrările sunt scrise în baza de date de Cognos
- Baza de date de audit este în uz de mai bine de un an
- Mediul este foarte activ cu utilizatorii și execuțiile
- Pachetul de audit este utilizat pentru a afișa datele de utilizare Cognos
- Căutăm să îmbunătățim performanța raportării bazei de date de audit
- Repetarea sau ștergerea înregistrărilor vechi nu este întotdeauna o opțiune
Dacă nu aveți, încă, aveți instalat și configurat Cognos Audit, Lodestar Solutions, a Motio partener, are un excelent post privind activarea auditului în Cognos BI / CA.
Soluția
Există câteva soluții posibile care se prezintă rapid:
-
- Reduceți volumul de date prin:
-
- Mutarea unora dintre datele mai vechi într-o altă bază de date
- Mutarea unora dintre datele mai vechi într-un alt tabel din aceeași bază de date
- Ștergeți sau arcațihive unele dintre date și nu vă faceți griji
- Traieste cu asta. Loviți cutia în jos road și împingeți administratorul bazei de date pentru performanță
îmbunătățiri în timp ce le încătușează nepermițând modificări ale schemei sau
indexurile
Nu vom aborda opțiunea 3. Opțiunea 2, ștergerea datelor, nu este o opțiune bună și aș recomanda să mențineți o valoare minimă de cel puțin 18 luni. Dar, dacă sunteți atât de înclinați, IBM oferă un utilitar, AuditDBCleanup (Cognos BI) sau a scenariu (Cognos Analytics) care va face exact asta. Utilitarul pentru Cognos BI șterge înregistrările bazate pe un timestamp, în timp ce scripturile pentru Cognos Analytics șterg doar indexurile și tabelele.
Recomandările pe care le-am făcut clienților cu privire la acest lucru anterior au fost să se separe în două baze de date:
-
- Audit - Live: conține datele celei mai recente săptămâni
- Audit - Istoric: conține date istorice (până la N ani)
Pe scurt, procesul se desfășoară săptămânal pentru a muta cele mai recente înregistrări din Audit Live în Audit Historical. Audit Live reîncepe ca o listă goală după ce se execută acest proces.
-
- Live DB este rapid și strâns, permițând inserțiilor să se întâmple cât mai repede posibil
- Interogările de audit sunt direcționate exclusiv către DB istoric
Folosind această abordare, nu există o „îmbinare” implicită a datelor Live și a datelor Istorice. Aș argumenta că probabil doriți să o păstrați așa.
În Administrarea Cognos, puteți adăuga două conexiuni diferite pentru sursa de date de audit. Când un utilizator rulează un raport împotriva pachetului Audit, i se solicită ce conexiune dorește să utilizeze:
În cazul în care doriți să consultați datele de audit live mai degrabă decât datele istorice de audit, alegeți doar conexiunea „Audit - Live” când vi se solicită (ar trebui să fie excepția, nu norma).
Dacă DORIȚI, de asemenea, doriți să oferiți o imagine consolidată atât a Live cât și a istoricului, ați putea face acest lucru, dar ar avea impact asupra performanței.
De exemplu, ați putea crea o a treia bază de date numită „Audit - Vizualizare consolidată” și apoi, pentru fiecare tabel din schema Audit: creați o vizualizare denumită identic, care este o uniune SQL între tabela din DB live și tabela din DB istoric. În mod similar, acest lucru ar putea fi realizat și în modelul Framework Manager, dar, din nou, performanța ar fi un aspect cheie.
Unii dintre clienții noștri au creat o imagine consolidată. Opinia noastră este că acest lucru este probabil exagerat. Performanța ar fi întotdeauna mai slabă în această vizualizare consolidată și nu am întâlnit multe cazuri de utilizare care folosesc atât seturile de date live, cât și istoricul. Live este utilizat pentru depanare și Istoric pentru raportarea tendințelor.
Începând cu Cognos Analytics 11.1.7, baza de date de audit a crescut la 21 de tabele. Puteți găsi mai multe informații în altă parte în baza de date de audit, rapoarte de audit eșantion și modelul Framework Manager. Nivelul implicit de înregistrare este minim, dar poate doriți să utilizați nivelul următor, de bază, pentru a captura cererile de utilizare, gestionarea contului de utilizator și utilizarea în timpul rulării. O modalitate prin care puteți menține performanța sistemului este menținerea nivelului de înregistrare la cel mai scăzut nivel necesar. Evident, cu cât este mai mare înregistrarea de către server, cu atât performanța generală a serverului poate fi afectată.
Tabelele cheie de care vor fi interesați cei mai mulți administratori sunt cele 6 tabele care înregistrează activitatea utilizatorului și activitatea de raportare în sistem.
- COGIPF_USERLOGON: Stochează informațiile de conectare a utilizatorului (inclusiv deconectarea)
- COGIPF_RUNREPORT: Stochează informații despre execuțiile raportului
- COGIPF_VIEWREPORT: stochează informații despre solicitările de vizualizare a raportului
- COGIPF_EDITQUERY: Stochează informații despre rulările de interogare
- COGIPF_RUNJOB: Stochează informații despre cererile de locuri de muncă
- COGIPF_ACTION: Înregistrează acțiunile utilizatorilor în Cognos (acest tabel poate crește mult mai rapid decât celelalte)
Configurarea prealabilă arată astfel:
Configurare recomandată:
Baza de date Cognos Audit - Live conține 1 săptămână de date de audit. Datele mai vechi de o săptămână sunt mutate în baza de date de audit Cognos - Istoric.
Linia din baza de date Cognos Audit - Live către Cognos Audit Database - Istoricul din diagramă este responsabil pentru:
- Copierea datelor din Audit live în Audit istoric
- Eliminați toate rândurile din Auditul live care au mai mult de o săptămână
- Eliminați toate rândurile din Auditul istoric mai vechi de x ani
- Eliminați toate rândurile din COGIPF_ACTION care sunt mai vechi de 6 luni
Indexuri
Diferite tipuri de baze de date au diferite tipuri de indexare. Un index de bază de date este o structură de date, asociată cu un tabel (sau vizualizare), utilizată pentru a îmbunătăți timpul de execuție a interogărilor la preluarea datelor din acel tabel (sau vizualizare). Colaborați cu DBA pentru a crea strategia optimă. Ei vor dori să știe răspunsurile la întrebări de acest gen pentru a lua cele mai bune decizii cu privire la ce coloane să indexeze. Evident, administratorul bazei de date ar putea afla răspunsurile la unele sau la toate aceste întrebări fără ajutorul dvs., dar ar dura câteva cercetări și ceva timp:
- Câte înregistrări au tabelele și la ce dimensiune vă așteptați să crească? (Indexarea unui tabel nu va fi utilă decât dacă tabelul are un număr mare de înregistrări.)
- Știți ce coloane sunt unice? Permit valori NULL? Ce coloane au un tip de date întreg sau mare? (Coloanele cu tipuri de date numerice și care sunt UNIQUE și NOT NULL sunt candidați puternici pentru a participa la cheia index.)
- Unde sunt principalele dvs. probleme de performanță astăzi? Sunt în recuperarea datelor? Există întrebări sau rapoarte specifice care sunt mai mult o problemă? (Acest lucru poate duce administratorul bazei de date la unele coloane specifice care pot fi optimizate.)
- Ce câmpuri sunt utilizate în tabelele de alăturare pentru raportare?
- Ce câmpuri sunt utilizate pentru filtrare, sortare, grupare și agregare?
Nu este surprinzător că acestea sunt aceleași întrebări la care ar trebui să se răspundă pentru îmbunătățirea performanței oricăror tabele de baze de date.
Asistență IBM recomandă crearea unui index pe coloanele „COGIPF_REQUESTID”, „COGIPF_SUBREQUESTID” și „COGIPF_STEPID” pentru următoarele tabele pentru a îmbunătăți performanța:
- COGIPF_NATIVEQUERY
- COGIPF_RUNJOB
- COGIPF_RUNJOBSTEP
- COGIPF_RUNREPORT
- COGIPF_EDITQUERY
Plus pe alte mese mai puțin utilizate:
- COGIPF_POWERPLAY
- COGIPF_HUMANTTASKSERVICE
- COGIPF_HUMANTASKSERVICE_DETAIL
Puteți folosi acest lucru ca punct de plecare, dar aș trece prin exercițiul de a răspunde la întrebările de mai sus pentru a ajunge la cel mai bun răspuns pentru organizația dvs.
alte considerații
- Audit model FM. Amintiți-vă că modelul Framework Manager furnizat de IBM este modelat pe tabelele și câmpurile implicite. Orice modificare pe care o aduceți tabelelor de raportare va trebui să fie reflectată în model. Ușurința sau complexitatea acestor schimbări - sau competența organizațională pentru a face aceste modificări - pot afecta soluția pe care o alegeți.
- Câmpuri suplimentare. Dacă veți face acest lucru, este momentul să adăugați câmpuri suplimentare pentru context sau date de referință pentru a îmbunătăți raportarea auditului.
- Tabelele rezumative. În loc să copiați doar datele în tabelul istoric, comprimați-le. Puteți agrega datele la nivelul zilei pentru a le face mai eficiente pentru raportare.
- Vizualizări în loc de tabele. Alții spun: „Deci, în loc să aveți o bază de date„ curentă ”și o bază de date„ istorică ”, ar trebui să aveți o singură bază de date și toate tabelele din ea ar trebui să fie prefixate cu„ istorice ”. Apoi, ar trebui să creați un set de vizualizări, unul pentru fiecare tabel pe care doriți să îl vedeți ca „curent” și să fiți fiecare vizualizare să filtreze rândurile istorice pe care nu doriți să le vedeți și să lăsați să treacă doar cele actuale. ”
https://softwareengineering.stackexchange.com/questions/276395/two-database-architecture-operational-and-historical/276419#276419
Concluzie
Concluzia este că, cu informațiile furnizate aici, ar trebui să fiți bine pregătiți să purtați o conversație productivă cu DBA. Sunt mari șanse ca ea să fi rezolvat probleme similare înainte.
Modificările propuse în arhitectura Cognos Audit Database vor îmbunătăți performanța atât în raportarea directă, cât și în aplicațiile de la terțe părți care se bazează pe ea, cum ar fi Motio'S ReportCard și Inventar.
Apropo, dacă ați avut acea conversație cu DBA, ne-ar plăcea să aflăm despre asta. Ne-ar plăcea, de asemenea, să aflăm dacă ați rezolvat problema unei baze de date de audit slab performante și cum ați făcut-o.
