Блог за одит на Cognos - Съвети и трикове за среда с голям обем

by Май 17, 2021Одиторски0 коментари

Блог на Джон Бойер и Майк Норис.

Въведение

Важно е способността на Cognos Auditing да работи, за да знае и разбира как Cognos се използва от вашата потребителска общност и да ви помогне да отговорите на въпроси като:

    • Кой използва системата?
    • Какви отчети пускат?
    • Какво е времето за изпълнение на отчета?
    • С помощта на други инструменти, като MotioCI, какво съдържание е неизползвано?

Като се има предвид колко е критично да се поддържа здрава среда на Cognos Analytics, изненадващо малко е написано за нейната база данни за одит извън стандартната документация на продукта. Може би това се приема за даденост, но организациите, които го използват, знаят, че с течение на времето търсенето на таблици на базата данни за одит ще започне да се забавя - особено ако вашата организация има много потребители, изпълняващи много отчети и има много история. Нещо повече, самото регистриране на одитната дейност може да се забави, защото се поставя на опашка, когато не може да бъде добавено достатъчно бързо към базата данни, например. Тогава започвате да мислите за ефективността на базата данни, както бихте правили с всяка оперативна база данни, която има изисквания за отчитане.

Големите таблици обикновено забавят производителността на заявките. Колкото по -голяма е таблицата, толкова по -дълго е необходимо за вмъкване и заявка. Не забравяйте, че тези таблици и Базата данни за одит са основно оперативна база данни; записите се случват често и работят срещу нас, тъй като не можем да ги фокусираме само за операции на четене, както бихте направили с март с данни.

Подобно на хранилището за съдържание, здравето на средата Cognos също трябва да отчита здравето на базата данни за одит. Неограниченият растеж на одиторската база данни може да се превърне в проблем с течение на времето и в крайна сметка може дори да повлияе на цялостната производителност на Cognos среда. В много организации, на които им се налагат външни разпоредби, липсата на пълен одит може да ги постави в ситуация на несъответствие с тежки последици. И така, как да се справим с това, че трябва да поддържаме толкова много данни за целите на историческия одит - в някои случаи до 10 години - и все пак да получаваме отчетите, от които се нуждаем, за да поддържаме околната среда и да поддържаме потребителите доволни от представянето?

The Challenge

    • Неограничен растеж на базата данни за одит оказва отрицателно въздействие върху здравето на средата Cognos
    • Отчитането на базата данни за одит е станало бавно или неизползваемо
    • Cognos изпитва закъснения при запис на записи в базата данни за одит
    • Базата данни за одит изчерпва дисковото пространство

Всичко това означава, че страдат не само докладите, които разчитат на базата данни за одит, но често и цялата система. Ако базата данни за одит е на същия сървър като хранилището за съдържание на Cognos, производителността на всички неща, които Cognos ще бъде засегната в тази среда.

The Setup

Предполагаме:

    1. Cognos Analytics е инсталиран и работи
    2. Cognos е конфигуриран да влиза в база данни за одит
        • Създайте база данни за одит
        • Задайте подходящи нива на регистриране на одита в администрацията на Cognos
        • Записите се записват в базата данни от Cognos
    3. Базата данни за одит се използва повече от година
    4. Средата е много активна с потребители и изпълнения
    5. Пакетът Audit се използва за извеждане на данни за използването на Cognos
    6. Ние се стремим да подобрим ефективността на отчитането на базата данни за одит
    7. Стартирането или изтриването на стари записи не винаги е опция

Ако все още не сте, инсталирайте и конфигурирайте Cognos Audit, Lodestar Solutions, a Motio партньор, има отличен пускат за активиране на одита в Cognos BI /CA.

Решението

Има някои възможни решения, които бързо се представят:

    1. Намалете обема на данните чрез:
        • Преместване на някои от по -старите данни в друга база данни
        • Преместване на някои от по -старите данни в друга таблица в същата база данни
    2. Просто изтрийте или дъгатаhive част от данните и не се притеснявайте за това
    3. Живей с това. Хвърлете консервата надолу road и натиснете администратора на базата данни за производителност
      подобрения, като им се поставят белезници, като не се допускат промени в схемата или
      индекси

Няма да се занимаваме с вариант 3. Вариант 2, изтриване на данните, не е добър вариант и бих препоръчал да запазите поне 18 месеца стойност. Но ако сте толкова склонни, IBM предоставя помощна програма, Одит DBCleanup (Cognos BI) или a писменост (Cognos Analytics), която ще направи точно това. Помощната програма за Cognos BI изтрива записи въз основа на времева отметка, докато скриптовете за Cognos Analytics просто изтриват индексите и таблиците.

Препоръките, които направихме на клиентите преди това, бяха да се разделят на две бази данни:

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

Накратко, процесът протича седмично за преместване на най -новите записи от Audit Live към Audit Historical. Audit Live започва отначало като празен лист след края на този процес.

    1. Live DB е бърз и стегнат, което позволява вмъкването да става възможно най -бързо
    2. Одитните заявки се насочват изключително към Историческата БД

Използвайки този подход, няма неявно „свързване“ на данните на живо и на историческите данни. Бих казал, че вероятно искате да продължите така.

В Cognos Administration можете да добавите две различни връзки за източника на данни за одит. Когато потребителят изпълнява отчет срещу пакета за одит, той получава подкана за връзката, която иска да използва:

Одит на бази данни

В случай, че искате да разгледате одитни данни на живо, а не исторически одитни данни, просто избирате връзката „Одит - на живо“, когато бъдете подканени (трябва да бъде изключение, а не норма.)

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

Например, можете да създадете трета база данни, наречена „Одит - консолидиран изглед“ и след това, за всяка таблица в схемата за одит: създайте идентичен изглед, който представлява SQL съюз между таблицата в активната база данни и таблицата в историческа БД. По подобен начин това може да се постигне и в модела на Framework Manager, но отново ефективността би била ключово съображение.

Някои от нашите клиенти са създали консолидиран изглед. Нашето мнение е, че това вероятно е прекалено много. Производителността винаги би била по -лоша в този консолидиран изглед и не сме срещали много случаи на използване, които използват както наборите от данни на живо, така и исторически. Live се използва за отстраняване на неизправности и Historical за отчитане на тенденции.

От Cognos Analytics 11.1.7 базата данни за одит нарасна до 21 таблици. Можете да намерите повече информация другаде в базата данни за одит, примерни одитни доклади и модела на Framework Manager. Нивото на регистриране по подразбиране е Минимално, но може да искате да използвате следващото ниво, Basic, за улавяне на заявки за използване, управление на потребителски акаунт и използване по време на изпълнение. Един от начините да поддържате производителността на системата е като поддържате нивото на регистриране до най -ниското необходимо ниво. Очевидно е, че колкото повече регистриране се извършва от сървъра, толкова по -обща производителност на сървъра може да бъде засегната.

Ключовите таблици, от които повечето администратори ще се интересуват, са 6 -те таблици, които регистрират активността на потребителя и отчитането в системата.

  • COGIPF_USERLOGON: Съхранява информация за влизане на потребителя (включително излизане)
  • COGIPF_RUNREPORT: Съхранява информация за изпълнението на отчета
  • COGIPF_VIEWREPORT: Съхранява информация за заявките за преглед на отчета
  • COGIPF_EDITQUERY: Съхранява информация за изпълнения на заявки
  • COGIPF_RUNJOB: Съхранява информация за заявките за работа
  • COGIPF_ACTION: Записва действия на потребителите в Cognos (тази таблица може да расте много по -бързо от останалите)

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

Конфигурация на одита по подразбиране

Препоръчителна конфигурация:

Препоръчителна конфигурация на одита

Базата данни за одит Cognos - на живо съдържа 1 седмица данни за одит. Данните, по -стари от 1 седмица, се преместват в базата данни на Cognos Audit - Исторически.

Редът от базата данни за одит на Cognos - База данни за одит на живо към Cognos - Исторически в диаграмата отговаря за:

  • Копиране на данни от одит на живо в исторически одит
  • Премахнете всички редове в одита на живо, които са по -стари от 1 седмица
  • Премахнете всички редове в Историческия одит, които са по -стари от x години
  • Премахнете всички редове в COGIPF_ACTION, които са по -стари от 6 месеца

Индекси

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

  • Колко записи имат таблиците и до какъв размер очаквате те да нараснат? (Индексирането на таблица няма да бъде полезно, освен ако таблицата има голям брой записи.)
  • Знаете ли кои колони са уникални? Позволяват ли NULL стойности? Кои колони имат тип данни от цяло или голямо цяло число? (Колоните с числови типове данни, които са UNIQUE и NOT 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 Audit Database ще подобрят производителността както в директните отчети, така и в приложенията на трети страни, които разчитат на нея, като MotioЕ ReportCard и инвентар.

Между другото, ако сте имали този разговор с вашия DBA, бихме искали да чуем за това. Бихме искали също да чуем дали сте решили проблема с лошо работеща база данни за одит и как сте го направили.

ОдиторскиBI/Аналитика
Готови ли сте за одит?

Готови ли сте за одит?

Готови ли сте за одит? Автори: Ки Джеймс и Джон Бойър Когато за първи път прочетете заглавието на тази статия, вероятно сте потръпнали и веднага сте се сетили за вашия финансов одит. Това може да е страшно, но какво да кажем за одитите за съответствие? Готови ли сте за...

Вижте повече

ОдиторскиBI/Аналитика
Има ли дупка във вашия сокс? (съответствие)

Има ли дупка във вашия сокс? (съответствие)

Анализ и Sarbanes-Oxley Управление на съответствието на SOX с BI инструменти за самообслужване като Qlik, Tableau и PowerBI Следващата година SOX ще бъде достатъчно стар, за да купува бира в Тексас. Той е роден от „Счетоводната реформа на публичните дружества и Закона за защита на инвеститорите“,...

Вижте повече