Блог Cognos Auditing - Поради та хитрощі для середовищ великого та великого обсягу

by Травень 17, 2021Аудиткоментарі 0

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

Вступ

Важливо, щоб можливості аудиту Cognos працювали, щоб знати і розуміти, як Cognos використовується вашою спільнотою користувачів, і допомагати відповідати на такі питання, як:

    • Хто користується системою?
    • Які звіти вони складають?
    • Який час виконання звіту?
    • За допомогою інших інструментів, наприклад MotioCI, який вміст не використовується?

Враховуючи наскільки критично важливо підтримувати здорові середовища Cognos Analytics, про її базу аудиту напрочуд мало написано, окрім стандартної документації на продукт. Можливо, це сприймається як належне, але організації, які його використовують, знають, що з часом запити до таблиць Аудиторської бази даних почнуть сповільнюватися, особливо якщо у вашій організації багато користувачів, які створюють багато звітів і мають багато історії. Більше того, що саме журналювання аудиторської діяльності може затримуватися, оскільки вона поставлена ​​в чергу, коли її, наприклад, неможливо додати до бази даних досить швидко. Саме тоді ви починаєте думати про продуктивність бази даних так само, як і з будь -якою оперативною базою даних, яка має вимоги до звітності.

Великі таблиці зазвичай уповільнюють роботу запитів. Чим більша таблиця, тим більше часу потрібно на вставлення та запит. Пам’ятайте, що ці таблиці та база даних аудиту - це в основному оперативна база даних; записи трапляються часто і працюють проти нас, оскільки ми не можемо зосередити їх лише на операціях зчитування, як це робиться з таблицею даних.

Як і сховище вмісту, стан середовища Cognos також повинен враховувати стан бази даних аудиту. Необмежене зростання бази даних аудиту з часом може стати проблемою і в кінцевому підсумку може навіть вплинути на загальну продуктивність середовища Cognos. У багатьох організаціях, на яких накладаються зовнішні нормативні акти, відсутність повної аудиторської документації може привести їх до ситуації невідповідності з великими наслідками. Тож як ми поводимося з тим, що ми маємо зберігати стільки даних для цілей історичного аудиту - у деяких випадках до 10 років - але все одно отримувати необхідну звітність для підтримки середовища та задоволення користувачів результатами роботи?

Виклики

    • Необмежене зростання бази даних аудиту негативно позначається на стані середовища Cognos
    • Звітування з бази даних аудиту стало повільним або непридатним для використання
    • Cognos відчуває затримки запису записів до бази даних аудиту
    • У базі даних аудиту вичерпано місце на диску

Все це означає, що страждають не лише звіти, які покладаються на Базу даних аудиту, а часто й уся система. Якщо база даних аудиту знаходиться на тому самому сервері, що і сховище вмісту Cognos, у цьому середовищі це вплине на продуктивність усіх речей Cognos.

Налаштування

Ми припускаємо:

    1. Cognos Analytics встановлено та запущено
    2. Cognos налаштовано для входу до бази даних аудиту
        • Розмістіть базу даних аудиту
        • Встановіть відповідні рівні ведення журналу аудиту в адміністрації Cognos
        • Cognos записує записи в базу даних
    3. База даних аудиту використовується більше року
    4. Середовище дуже активне з користувачами та виконанням
    5. Пакет аудиту використовується для отримання даних про використання Cognos
    6. Ми прагнемо покращити ефективність звітування бази даних аудиту
    7. Початок заново або видалення старих записів - не завжди варіант

Якщо ви цього ще не зробили, встановіть та налаштуйте Cognos Audit, Lodestar Solutions, a Motio партнер, має відмінника після про включення аудиту в Cognos BI /CA.

Рішення

Є кілька можливих рішень, які швидко з’являються:

    1. Зменшіть обсяг даних за допомогою:
        • Перенесення деяких старих даних до іншої бази даних
        • Переміщення деяких старих даних до іншої таблиці в тій же базі даних
    2. Просто видаліть або дугуhive деякі дані і не турбуйтеся про це
    3. Живи з цим. Збийте банку вниз road і натиснути адміністратора бази даних для підвищення продуктивності
      поліпшення, прив'язуючи їх наручниками, не допускаючи зміни схеми або
      покажчики

Ми не збираємося розглядати варіант 3. Варіант 2, видалення даних, не є хорошим варіантом, і я б рекомендував зберігати мінімум 18 місяців. Але, якщо ви настільки схильні, IBM надає утиліту, AuditDBCleanup (Cognos BI) або a сценарій (Cognos Analytics), яка буде робити саме це. Утиліта для Cognos BI видаляє записи на основі мітки часу, тоді як сценарії для Cognos Analytics просто видаляють індекси та таблиці.

Рекомендації, які ми раніше давали клієнтам щодо цього, полягали в тому, щоб розділити на дві бази даних:

    1. Аудит - живий: містить дані за останній тиждень
    2. Аудит - історичний: містить історичні дані (до N років)

Коротше кажучи, процес запускається щотижня для переміщення останніх записів з Audit Live в Audit Historical. Аудит Live починається з чистого аркуша після завершення цього процесу.

    1. Live DB є швидким і щільним, що дозволяє вставляти дані якомога швидше
    2. Аудиторські запити направляються виключно до історичної БД

Використовуючи цей підхід, не існує неявного «зшивання» живих даних та історичних даних. Я б стверджував, що ви, мабуть, хочете так і залишитися.

У адмініструванні Cognos ви можете додати два різних з'єднання для джерела даних аудиту. Коли користувач запускає звіт щодо пакета аудиту, йому пропонується, яке з'єднання він хоче використовувати:

Аудит баз даних

На випадок, якщо ви хочете подивитися дані аудиту в реальному часі, а не дані минулого аудиту, ви просто вибираєте з’єднання «Аудит - живий», коли буде запропоновано (це має бути винятком, а не нормою.)

Якщо ви ДІЙСНО також хочете надати консолідовану картину як в прямому ефірі, так і в історичному, ви можете це зробити, але це вплине на продуктивність.

Наприклад, ви можете створити третю базу даних під назвою «Аудит - консолідований вигляд», а потім для кожної таблиці в схемі аудиту: створити ідентично подане ім'я, яке є об'єднанням SQL між таблицею в реальній БД та таблицею в історична БД. Так само цього можна досягти і в моделі Framework Manager, але знову ж таки продуктивність буде ключовим фактором.

Деякі з наших клієнтів створили консолідований вигляд. На нашу думку, це, ймовірно, зайве. У цьому консолідованому поданні продуктивність завжди була б гіршою, і ми не зустрічали багатьох випадків використання, які використовують як набори даних Live, так і Historical. Live використовується для усунення несправностей, а Historical - для звітування про тенденції.

Станом на Cognos Analytics 11.1.7 база даних аудиту зросла до 21 таблиці. Додаткову інформацію можна знайти в іншій базі даних аудиту, зразки аудиторських звітів та модель Framework Manager. Рівень ведення журналу за замовчуванням - Мінімальний, але ви можете скористатися наступним рівнем, базовим, для запису запитів на використання, керування обліковими записами користувачів та використання під час виконання. Одним із способів підтримки продуктивності системи є підтримка рівня журналювання на найнижчому необхідному рівні. Очевидно, що чим більше журналювання проводиться сервером, тим більше це може вплинути на загальну продуктивність сервера.

Ключові таблиці, які зацікавлять більшість адміністраторів, - це 6 таблиць, які реєструють активність користувачів та звітність у системі.

  • COGIPF_USERLOGON: Зберігає інформацію про вхід користувача (включаючи вихід)
  • COGIPF_RUNREPORT: Зберігає інформацію про виконання звітів
  • COGIPF_VIEWREPORT: Зберігає інформацію про запити на перегляд звітів
  • COGIPF_EDITQUERY: Зберігає інформацію про виконання запитів
  • COGIPF_RUNJOB: Зберігає інформацію про запити на роботу
  • COGIPF_ACTION: Записує дії користувачів у Cognos (ця таблиця може зростати набагато швидше, ніж інші)

Початкова конфігурація виглядає так:

Конфігурація аудиту за замовчуванням

Рекомендована конфігурація:

Рекомендована конфігурація аудиту

База даних аудиту Cognos - Live містить дані за 1 тиждень аудиту. Дані старше 1 тижня переміщуються до бази даних аудиту Cognos - Історичні.

Рядок із бази даних аудиту Cognos - База даних аудиту в реальному часі - Історія на діаграмі відповідає за:

  • Копіювання даних з Live Audit в Historical Audit
  • Видаліть усі рядки в Аудиті, які старше 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_HUMANTASKSSERVICE
  • 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

Висновок

Підсумок полягає в тому, що з наданою тут інформацією ви повинні бути добре підготовлені до продуктивної розмови зі своїм адміністратором баз даних. Велика ймовірність, що вона раніше вирішувала подібні проблеми.

Запропоновані зміни в архітектурі бази даних аудиту Cognos покращать продуктивність як прямого звітування, так і сторонніх додатків, які на нього покладаються, наприклад MotioАвтора ReportCard та Інвентаризація.

До речі, якби ви мали таку розмову зі своїм адміністратором банку даних, ми хотіли б почути про це. Ми також хотіли б почути, якщо ви вирішили проблему з неякісною базою даних аудиту та як ви це зробили.

АудитBI/Аналітика
Ви готові до аудиту?

Ви готові до аудиту?

Ви готові до аудиту? Автори: Кі Джеймс і Джон Бойер Коли ви вперше прочитали назву цієї статті, ви, ймовірно, здригнулися і відразу подумали про свій фінансовий аудит. Це може бути страшно, але як щодо перевірок відповідності? Чи готові ви до...

Детальніше

АудитBI/Аналітика
У вашому носку діра? (Відповідність)

У вашому носку діра? (Відповідність)

Аналітика та Сарбейнс-Окслі. Керування відповідністю SOX за допомогою інструментів самообслуговування BI, таких як Qlik, Tableau та PowerBI. Наступного року SOX буде достатньо дорослим, щоб купувати пиво в Техасі. Його виникло на основі «Закону про реформу бухгалтерського обліку державних компаній та захисту інвесторів»,...

Детальніше