John Boyer ir Mike Norris tinklaraštis.
Įvadas
Svarbu turėti „Cognos“ audito funkciją, kuri žinotų ir suprastų, kaip „Cognos“ naudoja jūsų vartotojų bendruomenė, ir padėtų atsakyti į tokius klausimus:
-
- Kas naudoja sistemą?
- Kokias ataskaitas jie rengia?
- Koks yra ataskaitos vykdymo laikas?
- Naudojant kitas priemones, pvz MotioCI, koks turinys nenaudojamas?
Atsižvelgiant į tai, kaip svarbu išlaikyti sveiką „Cognos Analytics“ aplinką, stebėtinai mažai buvo parašyta apie jos audito duomenų bazę, išskyrus standartinius produkto dokumentus. Galbūt tai savaime suprantama, tačiau ją naudojančios organizacijos žino, kad laikui bėgant audito duomenų bazės lentelių užklausos pradės lėtėti, ypač jei jūsų organizacijoje yra daug vartotojų, kuriančių daug ataskaitų ir turinti daug istorijos. Be to, pats audito veiklos registravimas gali būti atidėtas, nes, pavyzdžiui, jis yra eilėje, kai jo negalima pakankamai greitai pridėti prie duomenų bazės. Tuomet pradėsite galvoti apie duomenų bazės našumą, kaip ir apie bet kurią veikiančią duomenų bazę, kuriai taikomi ataskaitų teikimo reikalavimai.
Didelės lentelės paprastai lėtina užklausų našumą. Kuo didesnė lentelė, tuo ilgiau reikia įterpti ir pateikti užklausą. Atminkite, kad šios lentelės ir audito duomenų bazė iš esmės yra veikianti duomenų bazė; rašo dažnai ir veikia prieš mus, nes mes negalime sutelkti jų tik į skaitymo operacijas, kaip tai darytumėte naudodami duomenų martą.
Panašiai kaip turinio parduotuvė, „Cognos“ aplinkos būklė taip pat turi atsižvelgti į audito duomenų bazės būklę. Neribotas audito duomenų bazės augimas laikui bėgant gali tapti problema ir ilgainiui gali turėti įtakos bendram „Cognos“ aplinkos našumui. Daugelyje organizacijų, kurioms taikomi išorės teisės aktai, neturėdami išsamaus audito įrašo, jie gali atsidurti nesilaikymo situacijoje ir turėti rimtų padarinių. Taigi, kaip mums elgtis, kai reikia išlaikyti tiek daug duomenų istorinio audito tikslais (kai kuriais atvejais iki 10 metų), tačiau vis tiek gauti ataskaitas, kurių mums reikia, kad išlaikytume aplinką ir naudotojai būtų patenkinti našumu?
Iššūkis
-
- Neribotas audito duomenų bazės augimas neigiamai veikia „Cognos“ aplinkos sveikatą
- Audito duomenų bazės ataskaitų teikimas tapo lėtas arba netinkamas
- „Cognos“ vėluoja įrašyti įrašus į audito duomenų bazę
- Audito duomenų bazėje trūksta vietos diske
Visa tai reiškia, kad nukenčia ne tik ataskaitos, pagrįstos audito duomenų baze, bet dažnai ir visa sistema. Jei audito duomenų bazė yra tame pačiame serveryje kaip ir „Cognos“ turinio saugykla, toje aplinkoje bus paveiktas visų „Cognos“ veikimas.
Sąranka
Mes manome:
-
- „Cognos Analytics“ įdiegta ir veikia
- „Cognos“ sukonfigūruota prisijungti prie audito duomenų bazės
-
- Turėkite audito duomenų bazę
- „Cognos“ administravime nustatykite tinkamus audito registravimo lygius
- Įrašą į duomenų bazę įrašo „Cognos“
- Audito duomenų bazė naudojama daugiau nei metus
- Aplinka yra labai aktyvi vartotojams ir vykdymams
- „Audito“ paketas naudojamas „Cognos“ naudojimo duomenims atskleisti
- Siekiame pagerinti audito duomenų bazės ataskaitų teikimo našumą
- Ne visada galima iš naujo pradėti ar ištrinti senus įrašus
Jei to dar nepadarėte, turite įdiegti ir sukonfigūruoti „Cognos Audit“, „Lodestar Solutions“, a Motio partneris, turi puikų paštu kaip įgalinti auditą „Cognos BI /CA“.
Sprendimas
Yra keletas galimų sprendimų, kurie greitai pateikiami:
-
- Sumažinkite duomenų kiekį:
-
- Kai kurių senesnių duomenų perkėlimas į kitą duomenų bazę
- Kai kurių senesnių duomenų perkėlimas į kitą tos pačios duomenų bazės lentelę
- Tiesiog ištrinkite arba lankąhive kai kuriuos duomenis ir nesijaudinkite
- Gyvenk su juo. Nuleiskite skardinę žemyn road ir stumkite duomenų bazės administratorių, kad jis veiktų
patobulinimus, uždedant jiems antrankius, neleidžiant keisti schemos arba
indeksai
Mes nesvarstysime 3 varianto. 2 variantas, ištrinti duomenis, nėra geras pasirinkimas, ir aš rekomenduočiau išlaikyti bent 18 mėnesių vertę. Bet jei esate taip linkę, IBM teikia naudą, „AuditDBCleanup“ („Cognos BI“) arba a scenarijus („Cognos Analytics“), kuri tai ir padarys. „Cognos BI“ programa ištrina įrašus pagal laiko žymę, o „Cognos Analytics“ scenarijai tiesiog ištrina indeksus ir lenteles.
Anksčiau klientams pateiktos rekomendacijos šiuo klausimu buvo suskirstytos į dvi duomenų bazes:
-
- Auditas - tiesioginis: yra paskutinės savaitės duomenų
- Auditas - istorinis: yra istorinių duomenų (iki N metų)
Trumpai tariant, procesas vyksta kas savaitę, kad naujausi įrašai būtų perkelti iš „Audit Live“ į „Audit Historical“. Po šio proceso „Audit Live“ prasideda kaip tuščias lapas.
-
- „Live DB“ yra greitas ir sandarus, todėl įdėklai gali įvykti kuo greičiau
- Audito užklausos yra skirtos tik istorinei DB
Naudojant šį metodą, nėra tiesioginio tiesioginių duomenų ir istorinių duomenų „sujungimo“. Manyčiau, kad jūs tikriausiai norite tai išlaikyti.
„Cognos Administration“ galite pridėti du skirtingus audito duomenų šaltinio ryšius. Kai vartotojas paleidžia ataskaitą apie audito paketą, jis paraginamas, kurį ryšį jis nori naudoti:
Atsitiktinai, kai norite pažvelgti į tiesioginio audito duomenis, o ne į ankstesnius audito duomenis, tiesiog paraginti pasirenkate ryšį „Auditas - tiesioginis“ (tai turėtų būti išimtis, o ne norma).
Jei TIKRAI taip pat norite pateikti konsoliduotą „Live“ ir „Historical“ vaizdą, galite tai padaryti, tačiau tai paveiktų našumą.
Pvz., Galite sukurti trečiąją duomenų bazę, pavadintą „Auditas - konsoliduotas vaizdas“, ir tada kiekvienai audito schemos lentelei sukurti identiškai pavadintą vaizdą, kuris yra SQL sąjunga tarp tiesioginės DB lentelės ir lentelės. istorinė DB. Panašiai tai būtų galima pasiekti ir naudojant „Framework Manager“ modelį, tačiau vėlgi, našumas būtų pagrindinis dalykas.
Kai kurie mūsų klientai sukūrė konsoliduotą vaizdą. Mūsų nuomone, tai greičiausiai yra perdėta. Šiame konsoliduotame rodinyje našumas visada būtų prastesnis, ir mes nesame susidūrę su daugeliu naudojimo atvejų, kuriuose naudojami tiek tiesioginiai duomenų rinkiniai, tiek istoriniai. „Live“ naudojamas trikčių šalinimui, o „Historical“ - tendencijų ataskaitoms.
Nuo „Cognos Analytics 11.1.7“ audito duomenų bazė išaugo iki 21 lentelės. Daugiau informacijos rasite kitur audito duomenų bazėje, audito ataskaitų pavyzdžių ir „Framework Manager“ modelio. Numatytasis registravimo lygis yra Minimalus, tačiau galbūt norėsite naudoti kitą lygį, Basic, kad užfiksuotumėte naudojimo užklausas, vartotojo abonemento valdymą ir vykdymo laiko naudojimą. Vienas iš būdų išlaikyti sistemos našumą yra išlaikyti žemiausią reikalaujamą registravimo lygį. Akivaizdu, kad kuo daugiau registruoja serveris, tuo daugiau įtakos gali turėti bendras serverio našumas.
Pagrindinės lentelės, kurias domins dauguma administratorių, yra 6 lentelės, kuriose registruojama vartotojo veikla ir ataskaitų teikimo veikla sistemoje.
- COGIPF_USERLOGON: saugo vartotojo prisijungimo informaciją (įskaitant atsijungimą)
- COGIPF_RUNREPORT: saugo informaciją apie ataskaitų vykdymą
- COGIPF_VIEWREPORT: Saugo informaciją apie ataskaitų peržiūros užklausas
- COGIPF_EDITQUERY: saugo informaciją apie užklausų vykdymus
- COGIPF_RUNJOB: saugo informaciją apie darbo užklausas
- COGIPF_ACTION: įrašo vartotojo veiksmus „Cognos“ (ši lentelė gali augti daug greičiau nei kitos)
Išorinė konfigūracija atrodo taip:
Rekomenduojama konfigūracija:
„Cognos Audit Database - Live“ yra 1 savaitės audito duomenys. Senesni nei 1 savaitės duomenys perkeliami į istorinę „Cognos“ audito duomenų bazę.
Eilutė iš „Cognos“ audito duomenų bazės - tiesioginė į „Cognos“ audito duomenų bazę - istorinė diagramoje yra atsakinga už:
- Duomenų kopijavimas iš tiesioginio audito į istorinį auditą
- Pašalinkite visas eilutes tiesioginiame audite, kurios yra senesnės nei 1 savaitė
- Pašalinkite visas istorinio audito eilutes, kurios yra senesnės nei x metų
- Pašalinkite visas COGIPF_ACTION eilutes, kurios yra senesnės nei 6 mėnesiai
Indeksai
Skirtingi duomenų bazių tipai turi skirtingus indeksavimo tipus. Duomenų bazės indeksas yra duomenų struktūra, susieta su lentele (arba rodiniu), naudojama siekiant pagerinti užklausų vykdymo laiką, kai gaunami duomenys iš tos lentelės (arba rodinio). Dirbkite su savo DBA, kad sukurtumėte optimalią strategiją. Jie norės žinoti atsakymus į tokius klausimus, kad galėtų priimti geriausius sprendimus, kokius stulpelius indeksuoti. Akivaizdu, kad duomenų bazės administratorius galėtų sužinoti atsakymus į kai kuriuos ar visus šiuos klausimus be jūsų pagalbos, tačiau tam prireiks šiek tiek tyrimų ir šiek tiek laiko:
- Kiek įrašų turi lentelės ir kokio dydžio jūs tikitės, kad jie augs? (Lentelės indeksavimas nebus naudingas, nebent lentelėje yra daug įrašų.)
- Ar žinote, kurios kolonos yra unikalios? Ar jie leidžia NULL reikšmes? Kurių stulpelių duomenų tipas yra sveikasis arba didelis sveikasis skaičius? (Stulpeliai su skaitmeniniais duomenų tipais ir unikalūs, o ne NULL yra stiprūs kandidatai dalyvauti rodyklės rakte.)
- Kur šiandien yra pagrindinės jūsų veiklos problemos? Ar jie renka duomenis? Ar yra konkrečių užklausų ar ataskaitų, kurios kelia didesnę problemą? (Dėl to duomenų bazės administratorius gali būti nukreiptas į tam tikrus stulpelius, kuriuos galima optimizuoti.)
- Kokie laukai naudojami jungiant lenteles ataskaitoms teikti?
- Kokie laukai naudojami filtravimui, rūšiavimui, grupavimui ir kaupimui?
Nenuostabu, kad tai yra tie patys klausimai, į kuriuos reikėtų atsakyti, norint pagerinti bet kokių duomenų bazių lentelių našumą.
IBM palaikymas rekomenduoja kuriant rodyklę stulpeliuose „COGIPF_REQUESTID“, „COGIPF_SUBREQUESTID“ ir „COGIPF_STEPID“ šioms lentelėms, siekiant pagerinti našumą:
- COGIPF_NATIVEQUERY
- COGIPF_RUNJOB
- COGIPF_RUNJOBSTEP
- COGIPF_RUNREPORT
- COGIPF_EDITQUERY
Plius kitose mažiau naudojamose lentelėse:
- COGIPF_POWERPLAY
- COGIPF_HUMANTASKSERVICE
- COGIPF_HUMANTASKSERVICE_DETAIL
Galite tai naudoti kaip atskaitos tašką, tačiau norėčiau rasti atsakymą į aukščiau pateiktus klausimus, kad gautumėte geriausią jūsų organizacijos atsakymą.
Kitos aplinkybės
- Audito FM modelis. Atminkite, kad IBM pateiktas „Framework Manager“ modelis yra sukurtas pagal numatytas lenteles ir laukus. Bet kokie ataskaitų lentelių pakeitimai turi būti atspindėti modelyje. Šių pakeitimų paprastumas ar sudėtingumas arba jūsų organizacinė kompetencija atlikti šiuos pakeitimus gali turėti įtakos jūsų pasirinktam sprendimui.
- Papildomi laukai. Jei ketinate tai padaryti, dabar pats laikas pridėti papildomų laukų, skirtų kontekstui ar nuorodų duomenims, kad pagerintumėte audito ataskaitas.
- Suvestinės lentelės. Užuot tiesiog nukopijavę duomenis į savo istorinę lentelę, suspauskite juos. Galite sujungti duomenis į dienos lygį, kad būtų efektyviau teikti ataskaitas.
- Vaizdai vietoj stalų. Kiti sako: „Taigi, užuot turėję„ dabartinę “duomenų bazę ir„ istorinę “duomenų bazę, turėtumėte turėti tik vieną duomenų bazę, o visos jos lentelės turi būti priešdėl„ istorinės “. Tada turėtumėte sukurti rodinių rinkinį, po vieną kiekvienai lentelei, kurią norite matyti kaip „dabartinę“, ir leisti kiekvienam rodiniui filtruoti istorines eilutes, kurių nenorite matyti, ir leisti praeiti tik dabartinėms. “
https://softwareengineering.stackexchange.com/questions/276395/two-database-architecture-operational-and-historical/276419#276419
Išvada
Esmė ta, kad turėdami čia pateiktą informaciją turėtumėte būti gerai pasirengę produktyviam pokalbiui su savo DBA. Didelė tikimybė, kad ji anksčiau išsprendė panašias problemas.
Siūlomi „Cognos“ audito duomenų bazės architektūros pakeitimai pagerins tiek tiesioginių ataskaitų, tiek trečiųjų šalių programų, kurios ja remiasi, našumą. MotioS ReportCard ir Inventorius.
Beje, jei jūs kalbėjotės su savo DBA, mes norėtume apie tai išgirsti. Taip pat norėtume išgirsti, ar išsprendėte prastai veikiančios audito duomenų bazės problemą ir kaip tai padarėte.
