Цогнос Аудитинг Блог - Савети и трикови за окружења великих и великих количина

Блог Јохна Боиера и Микеа Норриса.

увод

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

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

С обзиром на то колико је важно одржавати здрава окружења Цогнос аналитике, изненађујуће је мало написано о његовој ревизорској бази података изван стандардне документације о производу. Можда се то узима здраво за готово, али организације које га користе знају да ће с временом упити у табеле Аудит Датабасе почети да се успоравају - посебно ако ваша организација има много корисника који покрећу много извештаја и имају много историје. Штавише, и само бележење активности ревизије може каснити јер се ставља у ред ако се не може додати у базу података довољно брзо, на пример. Тада почињете размишљати о перформансама базе података као о свакој оперативној бази података која има захтјеве за извјештавање.

Велике таблице обично успоравају перформансе упита. Што је табела већа, потребно је више времена за уметање и постављање упита. Упамтите да су ове табеле и база података ревизије у основи оперативна база података; писања се дешавају често и раде против нас јер их не можемо усредсредити само на операције читања, као што бисте то учинили са податковном таблицом.

Слично као и складиште садржаја, здравље Цогнос окружења такође мора узети у обзир здравље базе података ревизије. Неограничени раст базе података ревизије може временом постати проблем и на крају може чак утицати на укупне перформансе Цогнос окружења. У многим организацијама са спољашњим прописима, непостојање потпуне ревизорске евиденције може их довести у ситуацију неусклађености са великим посљедицама. Дакле, како да се носимо са тим да морамо чувати толико података за историјске сврхе ревизије - у неким случајевима и до 10 година - а да ипак добијемо извештаје који су нам потребни за одржавање окружења и одржавање корисника задовољним учинком?

Изазов

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

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

Подешавање

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

1. 1. Цогнос Аналитицс је инсталиран и ради
   2. Цогнос је конфигурисан за пријављивање у ревизорску базу података
   1. • Поставите ревизорску базу података
      • Подесите одговарајуће нивое евидентирања ревизије у Цогнос администрацији
      • Цогнос записује записе у базу података
   3. Ревизорска база података је у употреби више од годину дана
   4. Окружење је веома активно са корисницима и извршењима
   5. Пакет Аудит се користи за приказивање података о употреби Цогноса
   6. Желимо да побољшамо перформансе извештавања у ревизорској бази података
   7. Покретање или брисање старих записа није увек опција

Ако још нисте, инсталирајте и конфигурирајте Цогнос Аудит, Лодестар Солутионс, а Motio партнер, има одлично пост о омогућавању ревизије у Цогнос БИ /ЦА.

Решење

Постоји неколико могућих решења која се брзо представљају:

1. 1. Смањите количину података за:
   1. • Премештање неких старијих података у другу базу података
      • Премештање неких старијих података у другу табелу у истој бази података
   2. Само избришите или направите лукhive неки од података и не брините због тога
   3. Живите с тим. Спустите лименку road и гурните администратора базе података за перформансе
      побољшања док им се стављају лисице тако што не дозвољавају измене шеме или
      индексе

Нећемо се бавити опцијом 3. Опција 2, брисање података, није добра опција и препоручио бих да вредност од најмање 18 месеци буде минимална. Али, ако сте толико склони, ИБМ нуди услужни програм, АудитДБЦлеануп (Цогнос БИ) или а скрипта (Цогнос Аналитицс) који ће управо то учинити. Помоћни програм за Цогнос БИ брише записе на основу временске ознаке, док скрипте за Цогнос Аналитицс само бришу индексе и табеле.

Препоруке које смо претходно дали клијентима о томе биле су да се раздвоје у две базе података:

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

Укратко, процес се одвија недељно за премештање најновијих записа из Аудит Ливе у Аудит Хисторицал. Аудит Ливе почиње поново као празна плоча након што се овај процес покрене.

1. 1. Ливе ДБ је брз и чврст, омогућавајући уметање што је брже могуће
   2. Ревизорски упити се искључиво упућују на Историјску базу података

Користећи овај приступ, не постоји имплицитно „спајање“ података уживо и историјских података. Рекао бих да вероватно желите да тако и остане.

У администрацији Цогнос можете додати две различите везе за извор података о ревизији. Када корисник покрене извештај против пакета Аудит, од њега ће бити затражено коју везу жели да користи:

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

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

На пример, могли бисте да креирате трећу базу података под називом „Ревизија - консолидовани приказ“, а затим за сваку табелу у шеми ревизије: направите идентично назван поглед који представља СКЛ унију између табеле у активној бази података и табеле у историјски ДБ. Слично, ово би се такође могло постићи у моделу Фрамеворк Манагер -а, али опет би перформансе биле кључна ствар.

Неки од наших клијената су створили консолидован приказ. Наше је мишљење да је ово вероватно претјерано. У овом консолидованом приказу перформансе би увек биле лошије и нисмо наишли на многе случајеве употребе који користе и скупове података уживо и историју. Ливе се користи за решавање проблема, а Хисторицал за извештавање о трендовима.

Од Цогнос Аналитицс 11.1.7, база података ревизије је порасла на 21 табелу. Више информација можете пронаћи на другом месту у Ревизорској бази података, узорцима ревизорских извештаја и моделу Фрамеворк Манагер -а. Подразумевани ниво евидентирања је Минимални, али можда ћете желети да користите следећи ниво, Основни, за снимање захтева за коришћење, управљање корисничким налогом и коришћење током извођења. Један од начина на који можете одржати перформансе система је држање нивоа евидентирања на најнижем потребном нивоу. Очигледно, што сервер више води евидентирање, то може утицати на свеукупне перформансе сервера.

Кључне табеле које ће занимати већину администратора су 6 табела које бележе активности корисника и активности извештавања у систему.

• ЦОГИПФ_УСЕРЛОГОН: Чува информације о пријављивању корисника (укључујући одјављивање)
• ЦОГИПФ_РУНРЕПОРТ: Чува информације о извршењима извештаја
• ЦОГИПФ_ВИЕВРЕПОРТ: Похрањује информације о захтевима за преглед извештаја
• ЦОГИПФ_ЕДИТКУЕРИ: Похрањује информације о покретању упита
• ЦОГИПФ_РУЊОБ: Чува информације о захтевима за посао
• ЦОГИПФ_АЦТИОН: Бележи корисничке радње у Цогносу (ова табела може расти много брже од осталих)

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

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

База података ревизије Цогнос - уживо садржи 1 недељу података ревизије. Подаци старији од 1 недеље се премештају у базу података Цогнос Аудит - Историјски.

Ред из Цогнос Аудит Датабасе - Ливе то Цогнос Аудит Датабасе - Историјски на дијаграму је одговоран за:

• Копирање података из ревизије уживо у ревизију историје
• Уклоните све редове у ревизији уживо који су старији од 1 недеље
• Уклоните све редове у Историјској ревизији који су старији од к година
• Уклоните све редове у ЦОГИПФ_АЦТИОН који су старији од 6 месеци

Индекси

Различити типови база података имају различите типове индексирања. Индекс базе података је структура података повезана са Табелом (или Погледом) која се користи за побољшање времена извршавања упита приликом преузимања података из те табеле (или Приказа). Радите са својим ДБА -ом на стварању оптималне стратегије. Желеће да знају одговоре на оваква питања како би донели најбоље одлуке о томе које колоне индексирати. Очигледно је да би администратор базе података могао сазнати одговоре на нека или сва ова питања без ваше помоћи, али било би потребно мало истраживања и неко вријеме:

• Колико записа имају столови и до које величине очекујете да ће расти? (Индексирање табеле неће бити корисно осим ако табела има велики број записа.)
• Да ли знате које су колоне јединствене? Да ли дозвољавају НУЛЛ вредности? Које колоне имају тип података цео или велики цео број? (Колоне са нумеричким типовима података које су ЈЕДИНСТВЕНЕ и НИСУ НУЛЛ су јаки кандидати за учешће у индексном кључу.)
• Где су данас ваши главни проблеми са перформансама? Да ли они преузимају податке? Постоје ли специфични упити или извештаји који представљају већи проблем? (Ово може довести администратора базе података до одређених ступаца који се могу оптимизирати.)
• Која поља се користе за придруживање табела за извештавање?
• Која се поља користе за филтрирање, сортирање, груписање и обједињавање?

Није изненађујуће да су то иста питања на која би требало одговорити ради побољшања перформанси било које табеле базе података.

ИБМ Суппорт препоручује креирање индекса у колонама „ЦОГИПФ_РЕКУЕСТИД“, „ЦОГИПФ_СУБРЕКУЕСТИД“ и „ЦОГИПФ_СТЕПИД“ за следеће табеле ради побољшања перформанси:

• ЦОГИПФ_НАТИВЕКУЕРИ
• ЦОГИПФ_РУЊОБ
• ЦОГИПФ_РУЊОБСТЕП
• ЦОГИПФ_РУНРЕПОРТ
• ЦОГИПФ_ЕДИТКУЕРИ

Плус на другим мање коришћеним столовима:

• ЦОГИПФ_ПОВЕРПЛАИ
• ЦОГИПФ_ХУМАНТАСКСЕРВИЦЕ
• ЦОГИПФ_ХУМАНТАСКСЕРВИЦЕ_ДЕТАИЛ

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

Остали разматрања

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

Zakljucak

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

Предложене промене у архитектури Цогнос Аудит Датабасе побољшаће перформансе како у директном извештавању, тако и у апликацијама трећих страна које се на то ослањају, нпр. Motio'С ReportCard и Инвентар.

Успут, ако сте имали тај разговор са вашим администратором за администрацију, волели бисмо да чујемо о томе. Такође бисмо волели да чујете да ли сте решили проблем лоше ревизорске базе података и како сте то урадили.