Blogo de John Boyer kaj Mike Norris.
Enkonduko
Gravas, ke la Cognos-Revizia kapablo funkciu por scii kaj kompreni kiel Cognos estas uzata de via uzantkomunumo kaj helpi respondi demandojn kiel:
-
- Kiu uzas la sistemon?
- Kiujn raportojn ili prizorgas?
- Kiuj estas la raportaj tempoj?
- Kun la helpo de aliaj iloj, kiel MotioCI, kia enhavo estas neuzata?
Konsiderante kiom kritike estas konservi sanajn mediojn de Cognos Analytics, surprize malmulton oni skribis pri sia revizia datumbazo preter la norma produkta dokumentado. Eble, ĝi estas donita kiel certa, sed organizoj, kiuj uzas ĝin, scias, ke dum tempo pridemandi la tabelojn de Audit Database komencos malrapidiĝi - precipe se via organizo havas multajn uzantojn administrantajn multajn raportojn kaj multan historion. Krome, la registrado de la kontrola agado mem povas esti prokrastita ĉar ĝi estas atendata kiam ĝi ne povas esti aldonita al la datumbazo sufiĉe rapide, ekzemple. Jen kiam vi ekpensas pri datumbaza agado kiel vi farus kun iu ajn operacia datumbazo kun raportaj postuloj.
Grandaj tabloj tipe malrapidigas demandon. Ju pli granda estas la tablo, des pli longa ĝi bezonas enmeti kaj pridemandi. Memoru, ke ĉi tiuj tabeloj kaj la Revizia Datumbazo baze estas funkcia datumbazo; skriboj okazas ofte kaj funkcias kontraŭ ni, ĉar ni ne povas enfokusigi ilin nur por legi operaciojn kiel vi farus kun datumaro.
Tre simile al la enhava butiko, la sano de la medio Cognos ankaŭ devas konsideri la sanon de la Revizia Datumbazo. Senlima kresko de la Revizia Datumbazo povas fariĝi problemo kun la tempo kaj eble eĉ eĉ efiki la ĝeneralan agadon de Cognos-medio. En multaj organizoj kun eksteraj regularoj, ne havi plenan revizan registron povas meti ilin en nerespektan situacion kun fortaj postefikoj. Do kiel ni traktas devi konservi tiom da datumoj por historiaj reviziaj celoj - en iuj kazoj ĝis 10 jaroj - tamen ankoraŭ ricevi la raportadon, kiun ni bezonas por konservi la medion kaj feliĉigi uzantojn pri la agado?
la defio
-
- Senlima kresko de la Revizia Datumbazo negative efikas sur la sanon de la medio Cognos
- Raporti pri la Revizia Datumbazo fariĝis malrapida aŭ neuzebla
- Cognos spertas malfruojn en registroj skribitaj al la Revizia Datumbazo
- La Revizia Datumbazo elĉerpigas diskospacon
Ĉio ĉi signifas, ke suferas ne nur la raportoj, kiuj dependas de la Revizia Datumbazo, sed ofte la tuta sistemo. Se la Revizia Datumbazo estas sur la sama servilo kiel la enhava butiko Cognos, efikeco de ĉiuj aferoj Cognos influos tiun medion.
La Agordo
Ni supozas:
-
- Cognos Analytics estas instalita kaj funkcianta
- Cognos estas agordita por ensaluti al Revizia Datumbazo
-
- Havi Kontrolan Datumbazon en loko
- Fiksu taŭgajn kontrolajn registradajn nivelojn en administrado de Cognos
- Rekordo estas skribita al la datumbazo de Cognos
- La Revizia Datumbazo estas uzata de pli ol jaro
- La medio estas tre aktiva ĉe uzantoj kaj ekzekutoj
- La Audit-pakaĵo estas uzata por aperigi datumojn pri uzado de Cognos
- Ni celas plibonigi la agadon de raportado de Audit-Datumbazo
- Rekomenci aŭ forigi malnovajn diskojn ne ĉiam estas elektebla
Se vi ankoraŭ ne havas, Cognos Audit estas instalita kaj agordita, Lodestar Solutions, a Motio partnero, havas bonegan post pri ebligado de Revizio en Cognos BI / CA.
la Solvo
Estas iuj eblaj solvoj, kiuj rapide sin prezentas:
-
- Reduktu la volumon de datumoj per:
-
- Movante iujn el la pli malnovaj datumoj al alia datumbazo
- Movante iujn el la pli malnovaj datumoj al alia tabelo en la sama datumbazo
- Simple forigu aŭ arĉuhive iuj datumoj kaj ne zorgu pri ĝi
- Vivu kun ĝi. Piedbatu la ladskatolon road kaj puŝu la Datumbazan Administranton por agado
plibonigoj dum mankatenado de ili ne permesante ŝanĝojn de la skemo aŭ
indeksoj
Ni ne traktos opcion 3. Opcio 2, forigi la datumojn, ne estas bona elekto kaj mi rekomendus konservi almenaŭ 18 monatojn. Sed, se vi emas, IBM provizas utilecon, AuditDBCleanup (Cognos BI) aŭ a skripto (Cognos Analytics) kiu faros ĝuste tion. La ilo por Cognos BI forigas registrojn bazitajn sur tempostampo dum la skriptoj por Cognos Analytics simple forigas la indeksojn kaj tabelojn.
La rekomendoj, kiujn ni antaŭe faris al klientoj pri tio, estis disigi en du datumbazojn:
-
- Revizio - Vive: enhavas la plej freŝan semajnan valoron de datumoj
- Revizio - Historia: enhavas historiajn datumojn (ĝis N jaroj)
Resume, la procezo funkcias ĉiusemajne por movi plej lastatempajn diskojn de Audit Live al Audit Historical. Audit Live rekomencas kiel malplena ardezo post ĉi tiu procezo.
-
- La Live DB estas rapida kaj streĉa, permesante enmetojn okazi kiel eble plej rapide
- Kontrolaj demandoj estas ekskluzive direktitaj al la Historia DB
Uzante ĉi tiun aliron, ne ekzistas implica "kunkudrado" de la Vivaj datumoj kaj la Historiaj datumoj. Mi argumentus, ke vi probable volas daŭrigi ĝin tiel.
En Cognos Administration, vi povas aldoni du malsamajn ligojn por la Revizia Datuma Fonto. Kiam uzanto lanĉas raporton kontraŭ la Audit-pakaĵo, oni petas al ili, kiun ligon ili volas uzi:
Se vi volas rigardi vivajn kontrolajn datumojn anstataŭ historiajn kontrolajn datumojn, vi simple elektas la ligon "Revizio - Viva" kiam vi petas (estu la escepto, ne la normo.)
Se vi VERE ankaŭ volas provizi solidan vidon pri kaj Viva kaj Historia, vi povus fari tion, sed tio efikus.
Ekzemple, vi povus krei trian datumbazon nomatan "Revizio - Firmigita Vido" kaj tiam, por ĉiu tabelo en la Audit-skemo: kreu identan nomitan vidon, kiu estas SQL-kuniĝo inter la tabelo en la viva DB kaj la tabelo en la historia DB. Simile, ĉi tio povus ankaŭ esti atingita en la modelo de Framework Manager, sed denove agado estus ŝlosila konsidero.
Iuj el niaj klientoj kreis solidan vidon. Estas nia opinio, ke ĉi tio probable troas. Efikeco ĉiam estus pli malbona en ĉi tiu firmigita vidpunkto kaj ni ne renkontis multajn uzokazojn, kiuj uzas ambaŭ Live Data-arojn kaj Historical. La Viva uzata por problemoj kaj la Historia por raportado pri tendencoj.
De Cognos Analytics 11.1.7, la Revizia Datumbazo kreskis al 21 tabloj. Vi povas trovi pliajn informojn aliloke pri la Revizia Datumbazo, specimenaj auditoraj raportoj kaj la modelo de Framework Manager. La defaŭlta registrada nivelo estas Minimuma, sed vi eble volas uzi la sekvan nivelon, Bazan, por kapti uzpetojn, administradon de uzanto-konto kaj rultempan uzadon. Unu maniero, kiel vi povas subteni rendimenton de la sistemo, estas konservi la registradan nivelon ĝis la plej malalta nivelo postulata. Evidente, ju pli da registrado estas farita de la servilo, des pli ĝenerala servila efikeco povas esti trafita.
La ŝlosilaj tabeloj, kiujn plej multaj administrantoj interesos, estas la 6 tabloj, kiuj registras la uzantan agadon kaj raportan agadon en la sistemo.
- COGIPF_USERLOGON: Stokas informojn pri ensaluto de la uzanto (inkluzive elŝalto)
- COGIPF_RUNREPORT: Stokas informojn pri raportaj ekzekutoj
- COGIPF_VIEWREPORT: Stokas informojn pri petoj pri raporto
- COGIPF_EDITQUERY: Stokas informojn pri petoj
- COGIPF_RUNJOB: Stokas informojn pri laborpostuloj
- COGIPF_ACTION: Registras agojn de uzantoj en Cognos (ĉi tiu tablo povas kreski multe pli rapide ol la aliaj)
La preta agordo aspektas jene:
Rekomendita agordo:
La Cognos Audit Database - Live enhavas 1 semajnon da kontrolaj datumoj. Datumoj pli aĝaj ol 1 semajno estas movitaj al la Datumbaza Kontrolado de Cognos - Historia.
La linio de la Datumbazo de Kontrolado de Cognos - Viva al Datumaro de Kontrolado de Cognos - Historia en la diagramo respondecas pri:
- Kopiante datumojn de Viva Revizio al Historia Revizio
- Forigu ĉiujn vicojn en la Viva Revizio pli ol 1 semajno
- Forigu ĉiujn vicojn en Historia Revizio pli aĝaj ol x jaroj
- Forigu ĉiujn vicojn en COGIPF_ACTION pli aĝaj ol 6 monatoj
indeksoj
Malsamaj datumbazaj tipoj havas malsamajn indeksajn specojn. Datumbaza indekso estas datuma strukturo, asociita kun Tabelo (aŭ Vido), uzata por plibonigi demandojn pri ekzekuto dum prenado de la datumoj de tiu tabelo (aŭ Vido). Laboru kun via DBA por krei la plej bonan strategion. Ili volos scii la respondojn al tiaj demandoj por fari la plej bonajn decidojn pri kiaj kolumnoj indeksi. Evidente, la datumbaza administranto povus ekscii la respondojn al iuj aŭ ĉiuj ĉi tiuj demandoj sen via helpo, sed necesus iom da esplorado kaj iom da tempo:
- Kiom da diskoj havas la tabeloj kaj laŭ kia grandeco vi atendas, ke ili kreskos? (Indeksado de tabelo ne utilos krom se la tabelo havas grandan nombron da registroj.)
- Ĉu vi scias, kiuj kolumnoj estas unikaj? Ĉu ili permesas NULajn valorojn? Kiuj kolumnoj havas datuman tipon de entjero aŭ granda entjero? (La kolumnoj kun numeraj datumtipoj kaj UNIKAJ kaj NE NULOJ estas fortaj kandidatoj por partopreni en la indeksa ŝlosilo.)
- Kie estas viaj ĉefaj agadproblemoj hodiaŭ? Ĉu ili retrovas la datumojn? Ĉu estas specifaj demandoj aŭ raportoj, kiuj pli problemas? (Ĉi tio eble kondukos la datumbazan administranton al iuj specifaj kolumnoj optimumigeblaj.)
- Kiuj kampoj estas uzataj en kunigaj tabeloj por raportado?
- Kiuj kampoj estas uzataj por filtri, ordigi, grupigi kaj agordi?
Ne surprize, ĉi tiuj estas la samaj demandoj, kiujn necesus respondi por plibonigi la rendimenton de iuj datumbazaj tabeloj.
IBM-Subteno rekomendas kreante indekson en kolumnoj "COGIPF_REQUESTID", "COGIPF_SUBREQUESTID", kaj "COGIPF_STEPID" por la jenaj tabeloj por plibonigi rendimenton:
- COGIPF_NATIVEQUERY
- COGIPF_RUNJOB
- COGIPF_RUNJOBSTEP
- COGIPF_RUNREPORT
- COGIPF_EDITQUERY
Plus sur aliaj malpli uzataj tabloj:
- COGIPF_POWERPLAY
- COGIPF_HUMANTASKSERVICE
- COGIPF_HUMANTASKSERVICE_DETAIL
Vi povas uzi ĉi tion kiel deirpunkton, sed mi ekzercus respondi la supre demandojn por atingi la plej bonan respondon por via organizo.
aliaj Konsideroj
- Audit FM Model. Memoru, ke la modelo de Framework Manager, kiun IBM provizas, estas laŭ la defaŭltaj tabeloj kaj kampoj. Ĉiuj ŝanĝoj, kiujn vi faras al la raporttabeloj, devos esti reflektitaj en la modelo. La facileco aŭ komplekseco de ĉi tiuj ŝanĝoj - aŭ via organiza kompetenteco por fari ĉi tiujn ŝanĝojn - eble influos la solvon, kiun vi elektas.
- Pliaj kampoj. Se vi faros ĝin, nun estas la tempo aldoni pliajn kampojn por kunteksto aŭ referencaj datumoj por plibonigi kontrolajn raportojn.
- Resumaj tabeloj. Anstataŭ nur kopii la datumojn al via historia tabelo, kunpremu ĝin. Vi povus kunigi la datumojn al la taga nivelo por pli efikigi ĝin por raportado.
- Vidoj anstataŭ tabloj. Aliaj diras, "Do, anstataŭ havi" aktualan "datumbazon kaj" historian "datumbazon, vi devas havi nur unu datumbazon, kaj ĉiuj tabeloj en ĝi estu prefiksitaj kun" historia ". Tiam vi devas krei aron da vidpunktoj, po unu por ĉiu tablo, kiun vi volas vidi kiel 'aktuala', kaj ke ĉiu vido filtru la historiajn vicojn, kiujn vi ne volas vidi, kaj lasu trairi nur la nunajn. "
https://softwareengineering.stackexchange.com/questions/276395/two-database-architecture-operational-and-historical/276419#276419
konkludo
La esenca afero estas, ke kun la donitaj informoj ĉi tie vi devas esti bone preta havi produktivan konversacion kun via DBA. Bonŝancoj estas, ke ŝi solvis similajn problemojn antaŭe.
La proponitaj ŝanĝoj en la arkitekturo de Cognos Audit Database plibonigos rendimenton en rekta raportado kaj en triaj programoj, kiuj dependas de ĝi, kiel Motio's ReportCard kaj Inventaro.
Cetere, se vi havis tiun konversacion kun via DBA, ni tre ŝatus aŭdi pri ĝi. Ni ankaŭ tre ŝatus aŭdi, ĉu vi solvis la aferon pri malbone plenumanta Revizia Datumbazo kaj kiel vi faris ĝin.
