Cognose auditi ajaveeb - näpunäiteid suure ja suuremahulise keskkonna jaoks

John Boyeri ja Mike Norrise ajaveeb.

Sissejuhatus

Oluline on, et Cognose auditeerimisvõimalus töötaks, et teada saada ja mõista, kuidas teie kasutajaskond Cognost kasutab, ning aidata vastata järgmistele küsimustele:

• • Kes süsteemi kasutab?
  • Milliseid aruandeid nad esitavad?
  • Millised on aruande esitamise ajad?
  • Teiste tööriistade abil, näiteks MotioCI, mis sisu on kasutamata?

Arvestades seda, kui oluline on säilitada terved Cognos Analyticsi keskkonnad, on selle auditeerimisandmebaasist üllatavalt vähe kirjutatud peale tavapärase toote dokumentatsiooni. Võib -olla peetakse seda iseenesestmõistetavaks, kuid seda kasutavad organisatsioonid teavad, et aja jooksul hakkab auditi andmebaasi tabelite päring aeglustuma - eriti kui teie organisatsioonil on palju kasutajaid, kes töötavad palju aruandeid ja millel on palju ajalugu. Veelgi enam, audititegevuse logimine ise võib viibida, kuna see pannakse järjekorda, kui seda ei saa näiteks piisavalt kiiresti andmebaasi lisada. See on siis, kui hakkate mõtlema andmebaasi toimivusele nagu iga toimiva andmebaasi puhul, millel on aruandlusnõuded.

Suured tabelid aeglustavad tavaliselt päringu toimimist. Mida suurem on tabel, seda kauem võtab selle sisestamine ja päring. Pidage meeles, et need tabelid ja auditi andmebaas on põhimõtteliselt toimiv andmebaas; kirjutab sageli ja töötab meie vastu, kuna me ei saa neid keskenduda ainult lugemisoperatsioonidele, nagu te seda teeksite andmetega.

Sarnaselt sisupoega tuleb ka Cognose keskkonna tervises arvestada auditiandmebaasi tervisega. Auditi andmebaasi piiramatu kasv võib aja jooksul muutuda probleemiks ja võib lõpuks isegi mõjutada Cognose keskkonna üldist toimivust. Paljudes organisatsioonides, mille välised eeskirjad on neile peale surutud, võib täieliku auditi puudumine viia nad nõuetele mittevastavasse olukorda, millel on tõsised tagajärjed. Kuidas me siis tegeleme sellega, et peame säilitama nii palju andmeid ajaloolise auditeerimise eesmärgil - mõnel juhul kuni 10 aastat -, kuid saame siiski aruanded, mida vajame keskkonna säilitamiseks ja kasutajate toimivusega rahul hoidmiseks?

Challenge

• • Auditi andmebaasi piiramatu kasv mõjutab negatiivselt Cognose keskkonna tervist
  • Auditi andmebaasi aruandlus on muutunud aeglaseks või kasutamiskõlbmatuks
  • Cognos esineb viivitusi auditiandmebaasi kirjete kirjutamisel
  • Auditi andmebaasis on kettaruum otsas

Kõik see tähendab, et mitte ainult auditiandmebaasile tuginevad aruanded, vaid sageli ka kogu süsteem ei kannata. Kui auditiandmebaas asub Cognose sisupoega samas serveris, mõjutab see Cognose toimivust selles keskkonnas.

Setup

Me eeldame:

1. 1. Cognos Analytics on installitud ja töötab
   2. Cognos on konfigureeritud logima auditi andmebaasi
   1. • Koostage auditi andmebaas
      • Määrake Cognose halduses sobivad auditi logimise tasemed
      • Rekordi kirjutab andmebaasi Cognos
   3. Auditi andmebaas on kasutusel olnud üle aasta
   4. Keskkond on kasutajate ja teostuste osas väga aktiivne
   5. Auditi paketti kasutatakse Cognose kasutusandmete kuvamiseks
   6. Soovime parandada auditi andmebaasi aruandlust
   7. Vanade kirjete uuesti alustamine või kustutamine pole alati valik

Kui te seda veel ei tee, on Cognos Audit installitud ja konfigureeritud, Lodestar Solutions, a Motio partner, tal on suurepärane pärast auditi lubamise kohta Cognos BI /CA -s.

Lahendus

On mitmeid võimalikke lahendusi, mis esitavad end kiiresti:

1. 1. Vähendage andmete mahtu:
   1. • Osa vanemate andmete teisaldamine teise andmebaasi
      • Mõnede vanemate andmete teisaldamine samasse andmebaasi teise tabelisse
   2. Lihtsalt kustutage või kaarhive osa andmeid ja ärge muretsege selle pärast
   3. Elage sellega. Löö purk alla road ja vajutage jõudluse tagamiseks andmebaasi administraatorit
      täiustusi, samal ajal käeraudu pannes, mitte lubades skeemi muuta või
      indeksid

Me ei hakka 3. valikuga tegelema. Valik 2, andmete kustutamine, ei ole hea valik ja ma soovitaksin hoida vähemalt 18 kuu väärtuse. Kui aga nii kaldute, pakub IBM utiliiti, AuditDBCleanup (Cognos BI) või a käsikiri (Cognos Analytics), mis teeb täpselt seda. Cognos BI utiliit kustutab kirjed ajatempli alusel, Cognos Analyticsi skriptid aga lihtsalt indeksid ja tabelid.

Soovitused, mida oleme klientidele selle kohta varem andnud, olid jagada kahte andmebaasi:

1. 1. Audit - Live: sisaldab viimase nädala andmeid
   2. Audit - ajalooline: sisaldab ajaloolisi andmeid (kuni N aastat)

Lühidalt öeldes toimub protsess kord nädalas, et viia viimased kirjed Audit Live'ist Audit Historicalisse. Audit Live algab pärast selle protsessi käivitamist tühja lehena.

1. 1. Live DB on kiire ja tihe, võimaldades sisestusi võimalikult kiiresti juhtuda
   2. Kontrollipäringud on suunatud ainult ajaloolisele andmebaasile

Seda lähenemisviisi kasutades ei toimu reaalajas andmete ja ajalooliste andmete kaudset ühendamist. Ma vaidleksin vastu, et ilmselt soovite seda nii hoida.

Cognose halduses saate auditi andmeallika jaoks lisada kaks erinevat ühendust. Kui kasutaja käivitab aruande auditipaketi kohta, küsitakse temalt, millist ühendust ta soovib kasutada.

Kui soovite vaadata reaalajas auditi andmeid, mitte ajaloolisi auditiandmeid, valite küsimisel lihtsalt ühenduse „Audit - Live” (see peaks olema erand, mitte norm.)

Kui soovite TEGELIKULT pakkuda ka konsolideeritud ülevaadet nii reaalajas kui ka ajaloolisest, võiksite seda teha, kuid see mõjutaks jõudlust.

Näiteks võite luua kolmanda andmebaasi nimega „Audit - konsolideeritud vaade” ja seejärel luua iga auditeerimisskeemi tabeli jaoks identse nimega vaade, mis on SQL -liide reaalajas DB tabeli ja tabeli vahel. ajalooline DB. Sarnaselt on seda võimalik saavutada ka raamistikuhalduri mudeli puhul, kuid jällegi on tulemuslikkus võtmetähtsusega.

Mõned meie kliendid on loonud konsolideeritud vaate. Meie arvates on see tõenäoliselt liialdus. Toimivus oleks selles konsolideeritud vaates alati halvem ja me pole kohanud palju kasutusjuhtumeid, mis kasutavad nii reaalajas andmekogumeid kui ka ajaloolisi andmeid. Live'i kasutatakse tõrkeotsinguks ja ajaloolist trendide aruandluseks.

Alates Cognos Analytics 11.1.7 -st on auditiandmebaas kasvanud 21 tabelini. Lisateavet leiate mujalt auditiandmebaasist, auditiaruannete näidistest ja Framework Manageri mudelist. Logimise vaiketase on minimaalne, kuid võite soovida kasutada järgmist taset, Basic, et jäädvustada kasutustaotlusi, kasutajakonto haldamist ja käitusaega. Üks võimalus süsteemi toimivust säilitada on hoida logimistase madalaimal nõutaval tasemel. On selge, et mida rohkem server logib, seda rohkem võib see mõjutada serveri üldist jõudlust.

Põhitabelid, millest enamik administraatoreid huvitab, on 6 tabelit, mis logivad kasutaja tegevust ja aruandlust süsteemis.

• COGIPF_USERLOGON: salvestab kasutaja sisselogimisteabe (sh väljalogimise)
• COGIPF_RUNREPORT: salvestab teabe aruannete täitmise kohta
• COGIPF_VIEWREPORT: salvestab teabe aruannete vaatamistaotluste kohta
• COGIPF_EDITQUERY: salvestab teabe päringute kohta
• COGIPF_RUNJOB: salvestab teavet töösoovide kohta
• COGIPF_ACTION: salvestab kasutajate toiminguid Cognos (see tabel võib kasvada palju kiiremini kui teised)

Valmis konfiguratsioon näeb välja selline:

Soovitatav konfiguratsioon:

Cognos Audit Database - Live sisaldab 1 nädala auditi andmeid. Vanemad kui 1 nädal andmed teisaldatakse Cognos Auditi andmebaasi - ajalooline.

Diagrammis olev Cognose auditi andmebaasi - reaalajas - Cognose auditi andmebaas - ajalooline rida vastutab:

• Andmete kopeerimine reaalajas auditist ajaloolisse auditi
• Eemaldage reaalajas auditi kõik read, mis on vanemad kui 1 nädal
• Eemaldage ajaloolises auditis kõik read, mis on vanemad kui x aastat
• Eemaldage kõik COGIPF_ACTION ridad, mis on vanemad kui 6 kuud

Indexes

Erinevatel andmebaasitüüpidel on erinevad indekseerimistüübid. Andmebaasi indeks on tabeliga (või vaatega) seotud andmestruktuur, mida kasutatakse päringute täitmise aja parandamiseks selle tabeli (või vaate) andmete toomisel. Optimaalse strateegia loomiseks tehke koostööd oma DBA -ga. Nad tahavad teada vastuseid sellistele küsimustele, et teha parimaid otsuseid selle kohta, milliseid veerge indekseerida. Ilmselgelt saaks andmebaasi administraator mõnele või kõigile neile küsimustele vastused ilma teie abita teada, kuid see võtaks natuke uurimistööd ja natuke aega:

• Kui palju kirjeid tabelitel on ja kui suureks te nende kasvamist eeldate? (Tabeli indekseerimine ei ole kasulik, kui tabelis pole palju kirjeid.)
• Kas teate, millised veerud on ainulaadsed? Kas nad lubavad NULL väärtusi? Milliste veergude andmetüüp on täis- või suur täisarv? (Numbriliste andmetüüpidega veerud, mis on UNIKAALSED ja MITTE NULL -id, on tugevad kandidaadid indeksivõtmes osalemiseks.)
• Kus on teie peamised jõudlusprobleemid täna? Kas nad otsivad andmeid? Kas on konkreetseid päringuid või aruandeid, mis tekitavad rohkem probleeme? (See võib viia andmebaasi administraatori teatud kindlatesse veergudesse, mida saab optimeerida.)
• Milliseid välju kasutatakse tabelite ühendamiseks aruandluseks?
• Milliseid välju kasutatakse filtreerimiseks, sortimiseks, rühmitamiseks ja koondamiseks?

Pole üllatav, et need on samad küsimused, millele oleks vaja vastuseid andmebaasitabelite toimivuse parandamiseks.

IBMi tugi soovitab toimivuse parandamiseks järgmiste tabelite jaoks veergude „COGIPF_REQUESTID”, „COGIPF_SUBREQUESTID” ja „COGIPF_STEPID” indeksi loomine:

• COGIPF_NATIVEQUERY
• COGIPF_RUNJOB
• COGIPF_RUNJOBSTEP
• COGIPF_RUNREPORT
• COGIPF_EDITQUERY

Lisaks muudele vähemkasutatavatele tabelitele:

• COGIPF_POWERPLAY
• COGIPF_HUMANTASKSERVICE
• COGIPF_HUMANTASKSERVICE_DETAIL

Võite seda lähtepunktina kasutada, kuid ma vastaksin ülaltoodud küsimustele, et jõuda teie organisatsioonile parima vastuseni.

Muud kaalutlused

1. Auditi FM mudel. Pidage meeles, et IBMi pakutav raamistikuhalduri mudel on modelleeritud vaiketabelite ja -väljade järgi. Kõik aruandlustabelites tehtud muudatused peavad kajastuma mudelis. Nende muudatuste lihtsus või keerukus - või teie organisatsiooniline pädevus nende muudatuste tegemiseks - võib mõjutada teie valitud lahendust.
2. Lisaväljad. Kui kavatsete seda teha, on nüüd aeg lisada auditi aruandluse parandamiseks konteksti- või viiteandmete jaoks täiendavaid välju.
3. Kokkuvõtvad tabelid. Selle asemel, et kopeerida andmed lihtsalt oma ajalootabelisse, pakkige need kokku. Aruandluse tõhusamaks muutmiseks võiksite andmed koondada päevasele tasemele.
4. Tabelite asemel vaated. Teised ütlevad: „Nii et praeguse andmebaasi ja ajaloolise andmebaasi asemel peaks teil olema ainult üks andmebaas ja kõik selle tabelid peaksid olema eesliitega„ ajalooline ”. Seejärel peaksite looma vaadete komplekti, iga tabeli kohta, mida soovite praeguse kujul näha, ning laskma iga vaate filtreerida välja ajaloolised read, mida te ei soovi näha, ja laske ainult praegustel läbida. ”
   https://softwareengineering.stackexchange.com/questions/276395/two-database-architecture-operational-and-historical/276419#276419

Järeldus

Lõpptulemus on see, et siin esitatud teabe abil peaksite olema hästi valmis oma DBA -ga produktiivseks vestluseks. Võimalik, et ta on varem sarnaseid probleeme lahendanud.

Kavandatud muudatused Cognose auditi andmebaasi arhitektuuris parandavad nii otsese aruandluse kui ka sellele tuginevate kolmanda osapoole rakenduste toimivust, nt Motio'S ReportCard ja Inventuur.

Muide, kui olete oma DBA -ga seda vestlust pidanud, tahaksime sellest kuulda. Samuti tahaksime kuulda, kas olete lahendanud halvasti toimiva auditi andmebaasi probleemi ja kuidas seda tegite.