Blogê Kontrolkirina Cognos - Serişte û Serişteyên ji bo Jîngehên Mezinahî & Bilind

Blogek ji hêla John Boyer û Mike Norris ve.

Pêşkêş

Girîng e ku meriv kapasîteya Kontrolkirina Cognos bixebite da ku bizanibe û fam bike ka Cognos ji hêla civata bikarhênerên we ve çawa tê bikar anîn û dibe alîkar ku pirsên mîna:

• • Kî pergalê bikar tîne?
  • Çi raporên wan dimeşin?
  • Demên xebitandina raporê çi ne?
  • Bi alîkariya amûrên din, mîna MotioCI, kîjan naverok nayê bikar anîn?

Bihesibînin ka çiqas girîng e ku meriv hawîrdorên saxlem ên Cognos Analytics biparêze, ecêb hindik di derheqê databasa lêpirsîna wê de ji belgeyên hilbera standard pê ve hatî nivîsandin. Dibe ku, ew jixweber tê girtin, lê rêxistinên ku wê bikar tînin dizanin ku bi demê re lêpirsîna tabloyên Databaza Kontrolê dê hêdî hêdî dest pê bike - nemaze ku di rêxistina we de gelek bikarhêner gelek rapor dimeşînin û pir dîrok heye. Tiştê din ev e ku têketina çalakiya vekolînê bixwe dibe ku dereng bimîne ji ber ku gava ku ew nekare bi têra xwe zû li databasê were zêdekirin, tê rêz kirin. Wê hingê hûn dest bi fikirîna li ser performansa databasê dikin mîna ku hûn bi her databasa xebitandinê ya ku hewcedariyên raporkirinê heye re bifikirin.

Tabloyên mezin bi gelemperî performansa lêpirsînê hêdî dikin. Tablo çiqas mezin be, têra xwe lêxistin û lêpirsînê dirêjtir dibe. Bînin bîra xwe ku ev tablo û Databaza Kontrolê bi bingehîn databasek xebitandinê ne; nivîsandin bi gelemperî diqewimin û li dijî me dixebitin ji ber ku em nekarin wan tenê ji bo operasyonên xwendinê wekî ku hûn bi daneya mart re dikin balê bikişînin.

Mîna dikana naverokê, divê tenduristiya hawîrdora Cognos jî tenduristiya Databaza Kontrolê bigire. Pêşveçûna bêsînor a Databaza Kontrolê dikare bi demê re bibe pirsgirêkek û dibe ku di dawiyê de tewra li ser performansa giştî ya jîngehek Cognos jî bandor bike. Li gelek rêxistinên ku rêziknameyên derveyî li wan dixin, nebûna tomarek venêrtinê ya bêkêmasî dikare wan di rewşek ne-bicîhbûnê de bi encamên giran bihêle. Ji ber vê yekê em çawa mijûl dibin ku pêdivî ye ku em ji bo mebestên venêrana dîrokî - di hin rewşan de heya 10 salan - ew qas daneyan biparêzin lê dîsa jî em ê raporê bigirin ku em hewce ne ku jîngehê biparêzin û bikarhêneran ji performansê dilxweş bikin?

Rallenge

• • Pêşveçûna bêsînor a Databaza Kontrolê bandorek neyînî li tenduristiya hawîrdora Cognos dike
  • Raporkirina ji Danegeha Kontrolê hêdî an bêkêr bûye
  • Cognos di tomarên ku ji Databaza Kontrolê re têne nivîsandin de dereng dimîne
  • Databaza Auditê cîhê dîskê xilas dike

Hemî ev tê vê wateyê ku ne tenê raporên ku xwe dispêrin Databaza Kontrolê zirarê digirin, lê pir caran tevahiya pergalê. Ger Databaza Kontrolê li ser servera heman dikana naveroka Cognos e, performansa hemî tiştên Cognos dê di wê hawîrdorê de bandor bibe.

The Setup

Em texmîn dikin:

1. 1. Cognos Analytics sazkirî ye û dixebite
   2. Cognos tête mîheng kirin ku têkeve Databasek Kontrolê
   1. • Di cîh de Databasek Kontrolê hebe
      • Di rêveberiya Cognos de astên tomarkirinê yên guncan bicîh bikin
      • Tomar ji hêla Cognos ve li databasê têne nivîsandin
   3. Databaza Kontrolê zêdetirî salekê ye ku tê bikar anîn
   4. Jîngeh bi bikarhêner û darvekirinan re pir çalak e
   5. Pakêta Kontrolê ji bo danîna daneyên karanîna Cognos tê bikar anîn
   6. Em lê digerin ku performansa raporkirina Databaza Audit baştir bikin
   7. Destpêkirin an rakirina tomarên kevn her gav ne vebijarkek e

Heke hûn, hîna jî, Cognos Audit saz nekirine û vesaz kirine, Lodestar Solutions, a Motio hevalbend, xwedan hêja ye koz li ser çalakkirina Kontrolê li Cognos BI /CA.

Çareseriya

Hin çareseriyên mimkun hene ku zû xwe diyar dikin:

1. 1. Hêjeya daneyê kêm bikin:
   1. • Hin daneyên kevn veguhezînin databasek din
      • Di heman danegehê de hin daneyên kevintir veguhezînin tabloyek din
   2. Tenê jêbirin an archive hin daneyan û ji vê yekê netirsin
   3. Bi wê bijîn. Kanî bikişînin jêr road û ji bo performansê Rêvebirê Danegehê bişkînin
      çêtirkirinên dema ku wan bi kelepçekirin destûr nadin guheztinên şemayê an
      indexes

Em ê bi vebijarka 3. re mijûl nebin. Vebijarka 2, jêbirina daneyan, vebijarkek ne baş e û ez pêşniyar dikim ku herî kêm nirxê 18 mehan 'bi kêmî ve bigirin. Lê, ger hûn ew qas dilxwaz in, IBM amûrek peyda dike, AuditDBCleanup (Cognos BI) an a nivîs (Cognos Analytics) ku dê wiya rast bike. Bikaranîna ji bo Cognos BI tomarên li gorî demjimêrek radike dema ku nivîsên ji bo Cognos Analytics tenê index û tabloyan jê dikin.

Pêşniyarên ku me berê ji muwekîlên xwe re kiribûn ev bûn ku bibin du databas:

1. 1. Kontrol - Zindî: Daneya hefteya herî paşîn a daneyê heye
   2. Kontrol - Dîrokî: Daneyên dîrokî hene (heya N salan)

Bi kurtasî, pêvajo heftane dimeşe da ku tomarên herî dawîn ji Audit Live -ê berbi Audit Historical veguhezîne. Piştî ku ev pêvajo dimeşe Audit Live ji nû ve wekî rûpelek vala dest pê dike.

1. 1. DB -ya Zindî bilez û zexm e, dihêle ku pêvek bi qasî ku gengaz dibe
   2. Pirsên lêpirsînê bi taybetî ji DB -a Dîrokî re têne rêve kirin

Bi karanîna vê nêzîkatiyê, "pêvekirina hevûdu" ya daneyên Zindî û daneyên Dîrokî tune. Ez ê bibêjim ku hûn guman dixwazin wiya wiya bihêlin.

Di Rêveberiya Cognos de, hûn dikarin ji bo Çavkaniya Daneya Kontrolê du girêdanên cûda lê zêde bikin. Gava ku bikarhênerek li dijî pakêta Kontrolê raporek dimeşîne, ji wan tê pirsîn ka kîjan pêwendiyê dixwazin bikar bînin:

Li ser derfeta ku hûn dixwazin li daneyên venêrana zindî binihêrin ne li daneyên venêrana dîrokî, hûn tenê gava ku tê xwestin pêwendiya "Kontrol - Zindî" hildibijêrin (divê îstîsna be, ne norm be.)

Ger hûn bi rastî jî dixwazin dîmenek yekbûyî ya Zindî û Dîrokî bidin, hûn dikarin wiya bikin, lê ew ê bandorê li performansê bike.

Mînakî, hûn dikarin Databaseke 3yemîn a bi navê "Kontrol - Dîtina Tevhevkirî" biafirînin û dûv re jî, ji bo her tabloyek di şemaya Kontrolê de: Dîmenek bi heman navî biafirînin ku yekîtiyek SQL ye di navbera maseya DB -ya zindî û tabloya di dîrokî DB. Bi vî rengî, ev dikare di modela Gerînendeyê Çarçuve de jî were bidestxistin, lê dîsa, performans dê nirxandinek bingehîn be.

Hin xerîdarên me nêrînek yekgirtî çêkirine. Li gorî nerîna me ev dibe ku zêde zêde be. Di vê nêrîna yekbûyî de performans dê her dem xirabtir be û em bi gelek dozên karanîna ku hem koma daneyên Zindî û hem jî Dîrokî bikar tînin re nehatine. Zindî ji bo çareserkirina pirsgirêkan û Dîrokî ji bo ragihandina trendê têne bikar anîn.

Li gorî Cognos Analytics 11.1.7, Databaza Kontrolê gihîştiye 21 tabloyan. Hûn dikarin li cîhek din li ser Databaza Kontrolê, nimûneyên raporên vekolînê û modela Rêveberê Çarçuve bêtir agahiyê bibînin. Asta têketinê ya xwerû Kêm e, lê dibe ku hûn bixwazin asta pêşîn, Bingehîn, bikar bînin da ku daxwazên karanînê, rêveberiya hesabê bikarhêner û karanîna dema xebitandinê bigirin. Yek awayek ku hûn dikarin performansa pergalê bidomînin ev e ku hûn asta têketinê li asta herî nizm a pêwîst bigirin. Eşkere ye, ku bêtir têketina ku ji hêla serverê ve tê kirin, dê performansa servera giştkî bêtir bandor bibe.

Tabloyên sereke yên ku pir rêvebir dê pê eleqedar bibin 6 tabloyên ku çalakiya bikarhêner û çalakiya ragihandinê di pergalê de tomar dikin in.

• COGIPF_USERLOGON: Agahdariya têketina bikarhêner (tevî têketinê) diparêze
• COGIPF_RUNREPORT: Agahiyên di derbarê darvekirina raporê de diparêze
• COGIPF_VIEWREPORT: Di derbarê daxwaznameyên dîtina raporê de agahdarî diparêze
• COGIPF_EDITQUERY: Agahdariya li ser xebitandina pirsan diparêze
• COGIPF_RUNJOB: Di derbarê daxwazên kar de agahdarî diparêze
• COGIPF_ACTION: Kiryarên bikarhêner li Cognos tomar dike (dibe ku ev tablo ji yên din pir zûtir mezin bibe)

Veavakirina der-qutî wiha xuya dike:

Veavakirina pêşniyar:

Danegeha Kontrolê ya Cognos - Zindî 1 hefte daneyên venêranê vedigire. Daneyên ji 1 hefte kevintir têne veguheztin Danegeha Kontrolê ya Cognos - Dîrokî.

Rêzeya ji Databaza Kontrolê ya Cognos - Databaza Kontrolê ya Zindî heya Cognos - Dîroka di şemayê de berpirsiyar e:

• Kopîkirina daneyan ji Kontrolê Zindî li Kontrola Dîrokî
• Di Ragihandina Zindî de hemî rêzên ku ji 1 hefteyê kevintir in rakin
• Hemî rêzên di Kontrola Dîrokî de ku ji x salan kevintir in rakin
• Hemî rêzên di COGIPF_ACTION de ku ji 6 mehan kevintir in rakin

Indexes

Cûreyên databasên cihêreng celebên navnîşkirinê yên cihêreng hene. Indeksa databasê avahiyek daneyê ye, ku bi Tabloyek (an Nêrînek) ve girêdayî ye, ji bo baştirkirina dema bicihanîna pirsan dema ku daneyê ji wê tabloyê (an Dîtin) digire. Bi DBA -ya xwe re bixebitin ku stratejiya çêtirîn biafirînin. Ew ê bixwazin bersivên pirsên mîna van bizanibin da ku biryarên çêtirîn li ser kîjan stûnan destnîşan bikin. Bê guman, rêvebirê databasê bêyî alîkariya we dikare bersivên hin an hemî van pirsan bibîne, lê ew ê hin lêkolîn û dem hewce bike:

• Çend qeydên tabloyan hene û hûn li bendê ne ku bi çi mezinahî mezin bibin? (Indeksa tabloyek heya ku di tabloyê de hejmarek tomar tune be dê ne kêrhatî be.)
• Ma hûn dizanin kîjan stûn bêhempa ne? Ma ew destûr didin nirxên NULL? Di kîjan stûnan de tîpa daneyê ya jimareyek an jimareyek mezin heye? (Stûnên bi celebên daneya hejmarî û yên UNIQUE û NOT NULL berendamên bihêz in ku beşdarî mifteya indexê bibin.)
• Pirsgirêkên weyên sereke yên performansê îro li ku ne? Ma ew di wergirtina daneyan de ne? Pirs û raporên taybetî hene ku bêtir pirsgirêk in? (Dibe ku ev rêvebirê databasê ber bi hin stûnên taybetî yên ku dikarin bêne xweşbîn kirin ve bibe.)
• Di tevlîbûna tabloyên ji bo raporkirinê de kîjan war têne bikar anîn?
• Ji bo parzûnkirin, rêzkirin, komkirin û berhevkirinê kîjan war têne bikar anîn?

Ne ecêb e, ev heman pirs in ku ji bo baştirkirina performansa her maseyên databasê hewce ne ku werin bersivandin.

Piştgiriya IBM pêşniyar dike li ser stûnên "COGIPF_REQUESTID", "COGIPF_SUBREQUESTID", û "COGIPF_STEPID" ji bo tabloyên jêrîn indexek çêbikin ku performansê baştir bikin:

• COGIPF_NATIVEQUERY
• COGIPF_RUNJOB
• COGIPF_RUNJOBSTEP
• COGIPF_RUNREPORT
• COGIPF_EDITQUERY

Zêdetir li ser maseyên din ên kêm-bikar anîn:

• COGIPF_POWERPLAY
• COGIPF_HUMANTASKSERVICE
• COGIPF_HUMANTASKSERVICE_DETAIL

Hûn dikarin vê yekê wekî xala destpêkê bikar bînin, lê ez ê werzîşa bersivdana pirsên li jor derbas bikim da ku bigihîjim bersiva çêtirîn ji bo rêxistina we.

din Ramanên

1. Audit Model FM. Bînin bîra xwe ku modela Gerînendeya Çarçuve ya ku IBM peyda dike li gorî tablo û zeviyên xwerû hatî çêkirin. Guheztinên ku hûn di tabloyên raporkirinê de dikin dê hewce be ku di modelê de bêne xuyang kirin. Hêsanbûn an tevliheviya van guherînan - an jêhatîbûna weya rêxistinî ya ji bo pêkanîna van guherînan - dibe ku bandorê li çareseriya ku we hilbijartî bike.
2. Zeviyên zêde. Ger hûn ê wiya bikin, naha dem dema zêdekirina qadên pêvek an daneya referansê ye da ku rapora vekolînê baştir bike.
3. Tabloyên kurtebirî. Li şûna ku hûn tenê daneyê li maseya xweya dîrokî kopî bikin, wê berhev bikin. Hûn dikarin daneyan berhev bikin asta rojê da ku Ew ji bo ragihandinê bêtir bikêrhatî be.
4. Dîtinên li şûna maseyan. Yên din dibêjin, "Ji ber vê yekê, li şûna ku databasek 'heyî' û databasek 'dîrokî' hebe, divê hûn tenê yek databasek hebe, û hemî tabloyên tê de divê bi 'dîrokî' ve bêne pêşandan. Dûv re, divê hûn komek nêrîn, yek ji bo her maseya ku hûn dixwazin wekî 'heyî' bibînin, biafirînin, û her nêrînek rêzên dîrokî yên ku hûn naxwazin bibînin parzûn bikin û bihêlin ku tenê yên heyî derbas bibin. "
   https://softwareengineering.stackexchange.com/questions/276395/two-database-architecture-operational-and-historical/276419#276419

Xelasî

Rêzeya jêrîn ev e ku bi agahdariya ku li vir tê peyda kirin divê hûn baş amade bin ku bi DBA -ya xwe re danûstendinek hilberîner bikin. Derfetên baş hene ku wê berê pirsgirêkên bi vî rengî çareser kiriye.

Guherandinên pêşniyazkirî yên di mîmariya Databaza Kontrolê ya Cognos de dê hem di ragihandina rasterast de û hem jî di sepanên partiya sêyemîn ên ku xwe dispêrin wê de, performansê çêtir bike, mîna Motio's ReportCard û Inventory.

Bi awayê, ger we ew danûstendin bi DBA -ya xwe re kiribe, em hez dikin ku li ser wê bibihîzin. Em ê her weha hez bikin ku bibihîzin ger we pirsgirêka Databaza Auditê ya ku performansa wê kêm e û we çawa kirî çareser kir.