Džona Bojera un Maika Norisa emuārs.
Ievads
Ir svarīgi, lai Cognos audita iespējas darbotos, lai zinātu un saprastu, kā jūsu lietotāju kopiena izmanto Cognos, un palīdzētu atbildēt uz šādiem jautājumiem:
-
- Kas izmanto sistēmu?
- Kādus pārskatus viņi izmanto?
- Kādi ir pārskatu izpildes laiki?
- Ar citu rīku palīdzību, piemēram MotioCI, kāds saturs ir neizmantots?
Ņemot vērā to, cik svarīgi ir uzturēt veselīgu Cognos Analytics vidi, pārsteidzoši maz ir rakstīts par tās revīzijas datu bāzi, izņemot standarta produkta dokumentāciju. Iespējams, tas tiek uzskatīts par pašsaprotamu, taču organizācijas, kas to izmanto, zina, ka laika gaitā vaicājumi par revīzijas datu bāzes tabulām sāks palēnināties - it īpaši, ja jūsu organizācijā ir daudz lietotāju, kuri izpilda daudz pārskatu un kuriem ir daudz vēstures. Turklāt revīzijas darbību reģistrēšana var aizkavēties, jo tā tiek ievietota rindā, ja, piemēram, to nevar pietiekami ātri pievienot datu bāzei. Tieši tad jūs sākat domāt par datu bāzes veiktspēju tāpat kā ar jebkuru operatīvu datu bāzi, kurai ir prasības ziņot.
Lielas tabulas parasti palēnina vaicājumu darbību. Jo lielāka ir tabula, jo ilgāk nepieciešams ievietot un veikt vaicājumus. Atcerieties, ka šīs tabulas un revīzijas datu bāze būtībā ir darbības datu bāze; raksti notiek bieži un darbojas pret mums, jo mēs nevaram tos koncentrēt tikai lasīšanas darbībām, kā jūs to darītu ar datu martu.
Līdzīgi kā satura veikalā, arī Cognos vides veselībai ir jāņem vērā revīzijas datu bāzes stāvoklis. Neierobežots revīzijas datu bāzes pieaugums laika gaitā var kļūt par problēmu un galu galā var pat ietekmēt Cognos vides kopējo darbību. Daudzās organizācijās, uz kurām attiecas ārējie noteikumi, pilnīga revīzijas ieraksta neesamība var novest pie neatbilstības situācijas ar nopietnām sekām. Tātad, kā rīkoties, ja mums ir jāuztur tik daudz datu vēsturiskas revīzijas nolūkos - dažos gadījumos līdz pat 10 gadiem -, tomēr saņemot ziņojumus, kas mums nepieciešami, lai saglabātu vidi un apmierinātu lietotājus ar sniegumu?
Challenge
-
- Neierobežota revīzijas datubāzes izaugsme negatīvi ietekmē Cognos vides veselību
- Ziņošana par revīzijas datu bāzi ir kļuvusi lēna vai nelietojama
- Cognos kavējas ierakstu ierakstīšana revīzijas datu bāzē
- Audita datu bāzē trūkst vietas diskā
Tas viss nozīmē, ka ne tikai ziņojumi, kas balstās uz revīzijas datu bāzi, cieš, bet bieži vien visa sistēma. Ja revīzijas datu bāze atrodas tajā pašā serverī, kurā atrodas Cognos satura veikals, šajā vidē tiks ietekmēta visu Cognos darbību veiktspēja.
Setup
Mēs pieņemam:
-
- Cognos Analytics ir instalēts un darbojas
- Cognos ir konfigurēts, lai reģistrētos revīzijas datu bāzē
-
- Izveidojiet revīzijas datu bāzi
- Iestatiet atbilstošus audita reģistrēšanas līmeņus Cognos administrācijā
- Ierakstu datu bāzē raksta Cognos
- Revīzijas datu bāze tiek izmantota vairāk nekā gadu
- Vide ir ļoti aktīva ar lietotājiem un izpildēm
- Audita pakete tiek izmantota, lai parādītu Cognos lietošanas datus
- Mēs cenšamies uzlabot revīzijas datu bāzes pārskatu sniegšanu
- Sākt no jauna vai dzēst vecos ierakstus ne vienmēr ir iespēja
Ja vēl neesat instalējis un konfigurējis Cognos Audit, Lodestar Solutions, a Motio partneris, ir lielisks nosūtīt par audita iespējošanu Cognos BI /CA.
Risinājums
Ir daži iespējamie risinājumi, kas ātri parādās:
-
- Samaziniet datu apjomu:
-
- Dažu vecāku datu pārvietošana uz citu datu bāzi
- Dažu vecāku datu pārvietošana uz citu tabulu tajā pašā datu bāzē
- Vienkārši izdzēsiet vai lokahive dažus datus un neuztraucieties par to
- Dzīvo ar to. Nolaidiet kannu lejā road un spiediet datu bāzes administratoru uz veiktspēju
uzlabojumus, saslēdzot tos rokudzelžos, neļaujot mainīt shēmu vai
indeksi
Mēs nerunāsim par 3. iespēju. 2. iespēja, datu dzēšana, nav laba iespēja, un es ieteiktu saglabāt vismaz 18 mēnešu vērtību. Bet, ja esat tik noskaņots, IBM nodrošina utilītu, AuditDBCleanup (Cognos BI) vai a scenārijs (Cognos Analytics), kas darīs tieši to. Cognos BI utilīta izdzēš ierakstus, pamatojoties uz laika zīmogu, bet Cognos Analytics skripti tikai izdzēš indeksus un tabulas.
Ieteikumi, ko iepriekš esam snieguši klientiem, bija sadalīt divās datu bāzēs:
-
- Audits - tiešraide: satur pēdējās nedēļas vērtīgos datus
- Revīzija - vēsturiska: satur vēsturiskus datus (līdz N gadiem)
Īsāk sakot, process notiek katru nedēļu, lai jaunākos ierakstus pārvietotu no Audit Live uz Audit Historical. Pēc šī procesa pabeigšanas Audit Live sākas no jauna.
-
- Live DB ir ātrs un saspringts, ļaujot ieliktņiem notikt pēc iespējas ātrāk
- Revīzijas vaicājumi ir vērsti tikai uz vēsturisko DB
Izmantojot šo pieeju, nav tiešu datu un vēsturisko datu netiešas “savienošanas”. Es iebilstu, ka jūs droši vien vēlaties to saglabāt tādā veidā.
Programmā Cognos Administration varat pievienot divus dažādus savienojumus audita datu avotam. Kad lietotājs izpilda pārskatu par revīzijas pakotni, viņam tiek prasīts, kuru savienojumu viņš vēlas izmantot:
Gadījumā, ja vēlaties apskatīt reāllaika revīzijas datus, nevis vēsturiskos audita datus, pēc pieprasījuma vienkārši izvēlieties savienojumu “Audits - tiešraide” (tam vajadzētu būt izņēmumam, nevis normai).
Ja jūs TIEŠĀM arī vēlaties nodrošināt konsolidētu priekšstatu par tiešraidi un vēsturi, varat to darīt, taču tas ietekmēs veiktspēju.
Piemēram, jūs varat izveidot trešo datu bāzi ar nosaukumu “Audits - konsolidētais skats” un pēc tam katrai tabulai revīzijas shēmā izveidot identiski nosauktu skatu, kas ir SQL savienība starp tiešās DB tabulu un tabulu vēsturiskā DB. Līdzīgi to varētu sasniegt arī Framework Manager modelī, taču atkal galvenais ir veiktspēja.
Daži no mūsu klientiem ir izveidojuši konsolidētu skatu. Mūsuprāt, tas, iespējams, ir pārspīlēts. Šajā konsolidētajā skatā veiktspēja vienmēr būtu sliktāka, un mēs neesam saskārušies ar daudziem lietošanas gadījumiem, kuros tiek izmantotas gan reāllaika datu kopas, gan vēsture. Tiešraide tiek izmantota problēmu novēršanai un vēsture - tendenču ziņošanai.
Sākot ar Cognos Analytics 11.1.7, revīzijas datu bāze ir palielinājusies līdz 21 tabulai. Plašāku informāciju varat atrast citur revīzijas datu bāzē, revīzijas ziņojumu paraugus un Framework Manager modeli. Reģistrācijas noklusējuma līmenis ir minimāls, taču, iespējams, vēlēsities izmantot nākamo līmeni Basic, lai fiksētu lietošanas pieprasījumus, lietotāja konta pārvaldību un izpildlaika izmantošanu. Viens veids, kā uzturēt sistēmas veiktspēju, ir saglabāt reģistrēšanas līmeni zemākajā nepieciešamajā līmenī. Acīmredzot, jo vairāk reģistrēšanas veic serveris, jo vairāk var tikt ietekmēta servera vispārējā veiktspēja.
Galvenās tabulas, kas interesēs lielāko daļu administratoru, ir 6 tabulas, kurās tiek reģistrētas lietotāju darbības un ziņošanas darbības sistēmā.
- COGIPF_USERLOGON: saglabā lietotāja pieteikšanās informāciju (ieskaitot izrakstīšanos)
- COGIPF_RUNREPORT: saglabā informāciju par pārskatu izpildi
- COGIPF_VIEWREPORT: saglabā informāciju par pārskatu skatīšanas pieprasījumiem
- COGIPF_EDITQUERY: saglabā informāciju par vaicājumu izpildēm
- COGIPF_RUNJOB: saglabā informāciju par darba pieprasījumiem
- COGIPF_ACTION: reģistrē lietotāju darbības programmā Cognos (šī tabula var pieaugt daudz straujāk nekā citas)
Iepakojumā esošā konfigurācija izskatās šādi:
Ieteicamā konfigurācija:
Cognos revīzijas datu bāzē - Live ir 1 nedēļas revīzijas dati. Dati, kas vecāki par 1 nedēļu, tiek pārvietoti uz vēsturisko Cognos audita datubāzi.
Diagrammas rindiņa no Cognos audita datu bāzes - tiešraides uz Cognos audita datubāzi - vēsturiskā ir atbildīga par:
- Datu kopēšana no tiešās revīzijas uz vēsturisko auditu
- Noņemiet visas tiešās revīzijas rindas, kas ir vecākas par 1 nedēļu
- Noņemiet visas vēstures audita rindas, kas ir vecākas par x gadiem
- Noņemiet visas COGIPF_ACTION rindas, kas ir vecākas par 6 mēnešiem
Indeksi
Dažādiem datu bāzes veidiem ir dažādi indeksēšanas veidi. Datu bāzes indekss ir ar tabulu (vai skatu) saistīta datu struktūra, ko izmanto, lai uzlabotu vaicājumu izpildes laiku, izgūstot datus no šīs tabulas (vai skata). Strādājiet ar savu DBA, lai izveidotu optimālu stratēģiju. Viņi vēlēsies uzzināt atbildes uz šādiem jautājumiem, lai pieņemtu vislabākos lēmumus par to, kuras kolonnas indeksēt. Acīmredzot datu bāzes administrators bez jūsu palīdzības varētu uzzināt atbildes uz dažiem vai visiem šiem jautājumiem, taču tas prasītu zināmu izpēti un kādu laiku:
- Cik daudz ierakstu ir tabulām un cik lielā apjomā, jūsuprāt, tās pieaugs? (Tabulas indeksēšana nebūs noderīga, ja vien tabulā nav liels ierakstu skaits.)
- Vai jūs zināt, kuras kolonnas ir unikālas? Vai tie pieļauj NULL vērtības? Kurās kolonnās ir vesels skaitlis vai liels vesels skaitlis? (Slejas ar ciparu datu tipiem, kas ir UNIKĀLAS un NAV NULL, ir spēcīgas kandidātes, lai piedalītos indeksa atslēgā.)
- Kur ir jūsu galvenās darbības problēmas šodien? Vai viņi izgūst datus? Vai ir īpaši jautājumi vai ziņojumi, kas rada lielākas problēmas? (Tādējādi datu bāzes administrators var tikt novirzīts uz noteiktām kolonnām, kuras var optimizēt.)
- Kādi lauki tiek izmantoti tabulu savienošanai pārskatu sniegšanai?
- Kādi lauki tiek izmantoti filtrēšanai, kārtošanai, grupēšanai un apkopošanai?
Nav pārsteidzoši, ka šie ir tie paši jautājumi, uz kuriem būtu jāatbild, lai uzlabotu datu bāzes tabulu veiktspēju.
IBM atbalsts iesaka izveidojot rādītāju kolonnās “COGIPF_REQUESTID”, “COGIPF_SUBREQUESTID” un “COGIPF_STEPID” šādām tabulām, lai uzlabotu veiktspēju:
- COGIPF_NATIVEQUERY
- COGIPF_RUNJOB
- COGIPF_RUNJOBSTEP
- COGIPF_RUNREPORT
- COGIPF_EDITQUERY
Plus uz citām mazāk lietotajām tabulām:
- COGIPF_POWERPLAY
- COGIPF_HUMANTASKSERVICE
- COGIPF_HUMANTASKSERVICE_DETAIL
Jūs to varat izmantot kā sākumpunktu, bet es atbildētu uz iepriekš minētajiem jautājumiem, lai rastu vislabāko atbildi jūsu organizācijai.
Citi apsvērumi
- Audita FM modelis. Atcerieties, ka IBM nodrošinātais Framework Manager modelis ir veidots pēc noklusējuma tabulām un laukiem. Visas izmaiņas, ko veicat pārskatu tabulās, ir jāatspoguļo modelī. Šo izmaiņu vieglums vai sarežģītība - vai jūsu organizatoriskā kompetence veikt šīs izmaiņas - var ietekmēt jūsu izvēlēto risinājumu.
- Papildu lauki. Ja jūs to darāt, tagad ir īstais laiks pievienot papildu laukus konteksta vai atsauces datiem, lai uzlabotu revīzijas ziņojumus.
- Kopsavilkuma tabulas. Tā vietā, lai vienkārši kopētu datus vēsturiskajā tabulā, saspiediet tos. Jūs varētu apkopot datus dienas līmenī, lai tie būtu efektīvāki pārskatu sniegšanai.
- Skati tabulu vietā. Citi saka: “Tātad, tā vietā, lai būtu“ pašreizējā ”datu bāze un“ vēsturiskā ”datu bāze, jums vajadzētu būt tikai vienai datu bāzei, un visām tabulām jābūt ar“ vēsturisku ”. Pēc tam jums jāizveido skatu kopa, pa vienai katrai tabulai, kuru vēlaties skatīt kā “pašreizējo”, un katram skatam jāfiltrē vēsturiskās rindas, kuras nevēlaties redzēt, un ļaujiet tām iziet cauri tikai tām. ”
https://softwareengineering.stackexchange.com/questions/276395/two-database-architecture-operational-and-historical/276419#276419
Secinājumi
Būtība ir tāda, ka ar šeit sniegto informāciju jums jābūt labi sagatavotam produktīvai sarunai ar savu DBA. Liela iespēja, ka līdzīgas problēmas viņa ir atrisinājusi arī iepriekš.
Ierosinātās izmaiņas Cognos audita datu bāzes arhitektūrā uzlabos veiktspēju gan tiešajos ziņojumos, gan trešo pušu lietojumprogrammās, kas uz to balstās, piemēram, Motio'S ReportCard un inventārs.
Starp citu, ja jums ir bijusi šī saruna ar savu DBA, mēs labprāt uzzinātu par to. Mēs arī labprāt uzzinātu, vai esat atrisinājis problēmu par slikti strādājošu revīzijas datu bāzi un kā to paveicāt.
