Блог за ревизија на Коњос - Совети и трикови за средини со голем и голем обем

Блог на Johnон Бојер и Мајк Норис.

Вовед

Важно е да имате способност за ревизија на Cognos за да знаете и разберете како Cognos се користи од вашата корисничка заедница и да помогнете да одговорите на прашања како што се:

• • Кој го користи системот?
  • Какви извештаи водат?
  • Какви се времињата на известување?
  • Со помош на други алатки, како MotioCI, која содржина е неискористена?

Со оглед на тоа колку е критично да се одржуваат здрави средини на Cognos Analytics, изненадувачки малку е напишано за неговата база на податоци за ревизија надвор од стандардната документација за производот. Можеби, се зема здраво за готово, но организациите што го користат знаат дека со текот на времето пребарувањето на табелите на базата на податоци за ревизија ќе почне да забавува - особено ако вашата организација има многу корисници кои водат многу извештаи и има многу историја. Уште повеќе е што самата евиденција на ревизорската активност може да биде одложена затоа што се реди кога не може да се додаде доволно брзо во базата на податоци, на пример. Тоа е кога ќе почнете да размислувате за перформансите на базата на податоци, како и со секоја оперативна база на податоци што има барања за известување.

Големите табели обично ја забавуваат работата на пребарувањето. Колку е поголема табелата, толку подолго е потребно за вметнување и барање. Запомнете дека овие табели и базата на податоци за ревизија се во основа оперативна база на податоци; пишувањата се случуваат често и работат против нас, бидејќи не можеме да ги фокусираме само за операции за читање, како што би правеле со податочен март.

Слично како и продавницата за содржини, здравјето на околината Коњос, исто така, мора да го земе предвид здравјето на базата на податоци за ревизија. Неограничениот раст на базата на податоци за ревизија може да стане проблем со текот на времето и на крајот може дури и да влијае на целокупната изведба на опкружувањето Коњос. Во многу организации со надворешни регулативи што ги врзуваат, немањето целосна евиденција за ревизија може да ги доведе во ситуација на непочитување со тешки последици. Значи, како да се справиме со тоа што треба да одржуваме толку многу податоци за историски цели на ревизија - во некои случаи и до 10 години - но сепак ги добиваме потребните извештаи за да ја одржуваме животната средина и да ги одржуваме корисниците задоволни со перформансите?

Предизвик

• • Неограничениот раст на базата на податоци за ревизија негативно влијае на здравјето на околината Коњос
  • Известувањето од базата на податоци за ревизија стана бавно или неупотребливо
  • Коњос доживува одложувања во записите што се пишуваат во базата на податоци за ревизија
  • На базата на податоци за ревизија истекува простор на дискот

Сето ова значи дека не страдаат само извештаите што се потпираат на базата на податоци за ревизија, туку често и целиот систем. Ако базата на податоци за ревизија е на ист сервер со продавницата за содржини Cognos, перформансите на сите работи Cognos ќе бидат засегнати во таа средина.

На подесување

Претпоставуваме:

1. 1. Cognos Analytics е инсталиран и работи
   2. Cognos е конфигуриран да се најавува на база на податоци за ревизија
   1. • Имајте база на податоци за ревизија
      • Поставете соодветни нивоа на регистрација на ревизија во администрацијата на Cognos
      • Записот се запишува во базата на податоци од Cognos
   3. Базата на податоци за ревизија се користи повеќе од една година
   4. Theивотната средина е многу активна со корисници и извршувања
   5. Пакетот за ревизија се користи за да се прикажат податоците за користењето на Cognos
   6. Ние бараме да ги подобриме перформансите на известување за базата на податоци за ревизија
   7. Почнувањето од почеток или бришење стари записи не е секогаш опција

Ако с don't уште не го имате инсталирано и конфигурирано Cognos Audit, Lodestar Solutions, a Motio партнер, има одличен пост за овозможување на ревизија во Cognos BI /CA.

Решението

Постојат некои можни решенија кои брзо се прикажуваат:

1. 1. Намалете го обемот на податоци со:
   1. • Преместување на некои од постарите податоци во друга база на податоци
      • Преместување на некои од постарите податоци на друга табела во истата база на податоци
   2. Само избришете или лакhive некои од податоците и не грижете се за тоа
   3. Liveивеј со тоа. Клоцајте ја конзервата надолу road и притиснете го администраторот на базата на податоци за изведба
      подобрувања додека ги врзуваат со лисици на рацете со тоа што не дозволуваат измени на шемата или
      индекси

Ние нема да се занимаваме со опцијата 3. Опцијата 2, бришењето на податоците, не е добра опција и би препорачал да се чува минимум 18 месеци. Но, ако сте толку наклонети, IBM обезбедува алатка, AuditDBCleanup (Cognos BI) или а скрипта (Cognos Analytics) што ќе го стори токму тоа. Алатката за Cognos BI ги брише записите базирани на временска ознака, додека скриптите за Cognos Analytics само ги бришат индексите и табелите.

Препораките што претходно им ги дадовме на клиентите беа да се поделат на две бази на податоци:

1. 1. Ревизија - во живо: ги содржи податоците од најновата недела
   2. Ревизија - Историски: содржи историски податоци (до N години)

Накратко, процесот тече неделно за да ги премести најновите записи од „Ревизија во живо“ во „Ревизија на историјата“. Ревизија во живо започнува како празна плоча по извршување на овој процес.

1. 1. Live DB е брз и тесен, овозможувајќи вметнувањата да се случат што е можно побрзо
   2. Прашањата за ревизија се исклучиво упатени кон Историскиот ДБ

Користејќи го овој пристап, не постои имплицитно „спојување“ на податоците во живо и историските податоци. Јас би се расправал дека веројатно сакате да го задржите на тој начин.

Во Cognos Administration, можете да додадете две различни врски за Изворот на податоци за ревизија. Кога корисникот ќе објави извештај против пакетот Ревизија, добива известување за тоа каква врска сака да користи:

Во случај на исклучување, сакате да ги погледнете податоците за ревизија во живо, а не историски податоци за ревизија, само изберете ја врската „Ревизија - Во живо“ кога ќе ви биде побарано (треба да биде исклучок, а не норма.)

Ако НАВИСТИНА исто така сакате да обезбедите консолидиран поглед и на живото и на историското, би можеле да го направите тоа, но тоа би влијаело на перформансите.

На пример, може да создадете трета база на податоци наречена „Ревизија - Консолидиран преглед“, а потоа, за секоја табела во шемата за ревизија: креирајте идентично именуван приказ што е SQL унија помеѓу табелата во живата ДБ и табелата во историски ДБ. Слично на тоа, ова исто така може да се постигне во моделот Рамковен менаџер, но, повторно, перформансите би биле клучно внимание.

Некои од нашите клиенти создадоа консолидиран поглед. Наше мислење е дека ова најверојатно е претерано. Перформансите секогаш би биле полоши во овој консолидиран поглед и не наидовме на многу случаи на употреба што користат и сетови на податоци во живо и Историски. Во живо се користи за смена на проблеми и Историски за известување трендови.

Што се однесува до Cognos Analytics 11.1.7, базата на податоци за ревизија порасна на 21 табела. Можете да најдете повеќе информации на друго место на базата на податоци за ревизија, примероци од ревизорски извештаи и модел на Рамковен менаџер. Стандардното ниво на најавување е минимално, но можеби ќе сакате да го користите следното ниво, Основно, за да ги снимите барањата за употреба, управување со корисничка сметка и употреба на време на траење. Еден начин на кој можете да ги одржите перформансите на системот е со одржување на нивото на најавување на најниското ниво што е потребно. Очигледно, колку повеќе најавување е направено од серверот, толку повеќе може да се засегнат вкупните перформанси на серверот.

Клучните табели за кои ќе бидат заинтересирани повеќето администратори се 6 -те табели кои ја евидентираат корисничката активност и активноста за известување во системот.

• COGIPF_USERLOGON: Чува информации за најавување на корисникот (вклучително и одјавување)
• COGIPF_RUNREPORT: Чува информации за извршување извештаи
• COGIPF_VIEWREPORT: Чува информации за барањата за приказ на извештај
• COGIPF_EDITQUERY: Склади информации за извршените прашања
• COGIPF_RUNJOB: Чува информации за барања за работа
• COGIPF_ACTION: Ги евидентира дејствата на корисниците во Cognos (оваа табела може да расте многу побрзо од другите)

Конфигурацијата надвор од кутијата изгледа вака:

Препорачана конфигурација:

База на податоци за ревизија Cognos - во живо содржи 1 недела податоци од ревизија. Податоците постари од 1 недела се преместуваат во базата на податоци за ревизија Cognos - Историски.

Линијата од базата на податоци за ревизија Коњос - База на податоци за ревизија во живо до Коњос - Историската во дијаграмот е одговорна за:

• Копирање податоци од ревизија во живо на историска ревизија
• Отстранете ги сите редови во Ревизија во живо што се постари од 1 недела
• Отстранете ги сите редови во Историска ревизија кои се постари од x години
• Отстранете ги сите редови во COGIPF_ACTION што се постари од 6 месеци

Индекси

Различни типови на бази на податоци имаат различни типови на индексирање. Индексот на базата на податоци е структура на податоци, поврзана со табела (или приказ), која се користи за подобрување на времето на извршување на прашањата при добивање на податоците од таа табела (или приказ). Работете со вашата DBA за да креирате оптимална стратегија. Тие ќе сакаат да ги знаат одговорите на вакви прашања за да донесат најдобри одлуки за тоа кои колумни ќе се индексираат. Очигледно, администраторот на базата на податоци може да ги дознае одговорите на некои или на сите овие прашања без ваша помош, но за тоа ќе бидат потребни некои истражувања и некое време:

• Колку записи имаат табелите и до која големина очекувате да пораснат? (Индексирањето на табелата нема да биде корисно, освен ако табелата нема голем број на записи.)
• Дали знаете кои колони се единствени? Дали дозволуваат NULL вредности? Кои колони имаат тип на податоци цел број или голем цел број? (Колоните со нумерички типови на податоци и кои се ЕДИНСТВЕНИ и НЕМАЛИ се силни кандидати за учество во индекс клучот.)
• Каде се вашите главни проблеми со перформансите денес? Дали тие ги добиваат податоците? Дали постојат конкретни прашања или извештаи што се повеќе проблем? (Ова може да го доведе администраторот на базата до некои специфични колони што може да се оптимизираат.)
• Кои полиња се користат при спојување табели за известување?
• Кои полиња се користат за филтрирање, сортирање, групирање и собирање?

Не е изненадувачки, ова се истите прашања на кои треба да се одговори за подобрување на перформансите на сите табели со бази на податоци.

Поддршка на IBM препорачува создавање индекс на колоните „COGIPF_REQUESTID“, „COGIPF_SUBREQUESTID“ и „COGIPF_STEPID“ за следните табели за подобрување на перформансите:

• COGIPF_NATIVEQUERY
• COGIPF_RUNJOB
• COGIPF_RUNJOBSTEP
• COGIPF_RUNREPORT
• COGIPF_EDITQUERY

Плус на други помалку користени табели:

• COGIPF_POWERPLAY
• COGIPF_HUMANTASKSERVICE
• COGIPF_HUMANTASKSERVICE_DETAIL

Можете да го користите ова како почетна точка, но јас би поминал низ вежбата да одговорам на горните прашања за да го најдам најдобриот одговор за вашата организација.

други мислења

1. Ревизија FM модел. Запомнете дека моделот Framework Manager што го обезбедува IBM е моделиран според стандардните табели и полиња. Сите промени што ги правите во табелите за известување ќе треба да се рефлектираат во моделот. Леснотијата или сложеноста на овие промени - или вашата организациска компетентност да ги направите овие промени - може да влијае на решението што ќе го изберете.
2. Дополнителни полиња. Ако го правите тоа, сега е време да додадете дополнителни полиња за контекст или референтни податоци за да го подобрите ревизорското известување.
3. Сумирачки табели. Наместо само копирање на податоците на вашата историска табела, компресирајте ги. Можете да ги соберете податоците на дневно ниво за да ги направите поефикасни за известување.
4. Прегледи наместо табели. Други велат: „Значи, наместо да имате„ тековна “база на податоци и„ историска “база на податоци, треба да имате само една база на податоци, и сите табели во неа треба да се префиксираат со„ историска “. Потоа, треба да креирате збир на прегледи, по еден за секоја табела што сакате да ја видите како „актуелна“ и секој приказ да ги филтрира историските редови што не сакате да ги видите и да дозволите да минуваат само сегашните “.
   https://softwareengineering.stackexchange.com/questions/276395/two-database-architecture-operational-and-historical/276419#276419

Заклучок

Во крајна линија е дека со информациите дадени овде треба да бидете добро подготвени да имате продуктивен разговор со вашата DBA. Големи се шансите дека и порано решила слични проблеми.

Предложените промени во архитектурата на базата на податоци за ревизија Cognos ќе ги подобрат перформансите и во директното известување, како и во апликациите од трети страни кои се потпираат на тоа, како Motio"S ReportCard и Инвентар.

Патем, ако сте го имале тој разговор со вашата DBA, би сакале да слушнеме за тоа. Исто така, би сакале да слушнеме дали сте го решиле прашањето за базата на податоци за ревизија со слаб перформанс и како сте го направиле тоа.