Блог Cognos Auditing - Советы и приемы для больших и больших сред

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

Введение

Важно, чтобы функция Cognos Auditing работала, чтобы знать и понимать, как Cognos используется вашим сообществом пользователей, и помогать отвечать на такие вопросы, как:

• • Кто пользуется системой?
  • Какие отчеты они создают?
  • Какое время выполнения отчета?
  • С помощью других инструментов, например MotioCI, какой контент не используется?

Учитывая, насколько критично поддерживать работоспособность сред Cognos Analytics, о его базе данных аудита написано на удивление мало, помимо стандартной документации по продукту. Возможно, это считается само собой разумеющимся, но организации, которые его используют, знают, что со временем запросы к таблицам базы данных аудита начнут замедляться, особенно если в вашей организации много пользователей, которые запускают множество отчетов и имеют много истории. Более того, ведение журнала активности аудита может быть отложено, потому что, например, оно ставится в очередь, когда не может быть добавлено в базу данных достаточно быстро. Именно тогда вы начинаете думать о производительности базы данных, как о любой операционной базе данных, которая требует отчетности.

Большие таблицы обычно снижают производительность запросов. Чем больше таблица, тем больше времени требуется для вставки и запроса. Помните, что эти таблицы и База данных аудита в основном являются оперативной базой данных; записи происходят часто и работают против нас, поскольку мы не можем сосредоточить их только на операциях чтения, как в случае с витриной данных.

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

Условия проведения

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

Все это означает, что страдают не только отчеты, основанные на базе данных аудита, но и вся система в целом. Если база данных аудита находится на том же сервере, что и хранилище контента Cognos, производительность всего Cognos будет затронута в этой среде.

Настройка

Мы предполагаем:

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

Если у вас еще нет установленного и настроенного Cognos Audit, Lodestar Solutions, Motio партнер, имеет отличный после о включении аудита в Cognos BI / CA.

Решение

Есть несколько возможных решений, которые быстро появляются:

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

Мы не собираемся рассматривать вариант 3. Вариант 2, удаление данных, не является хорошим вариантом, и я бы рекомендовал сохранить минимум 18 месяцев. Но, если вы так склонны, IBM предоставляет утилиту, АудитDBCleanup (Cognos BI) или скрипт (Cognos Analytics), который будет делать именно это. Утилита для Cognos BI удаляет записи на основе метки времени, в то время как сценарии для Cognos Analytics просто удаляют индексы и таблицы.

Рекомендации, которые мы давали клиентам ранее по этому поводу, заключались в разделении на две базы данных:

1. 1. Audit - Live: содержит данные за последнюю неделю
   2. Аудит - Исторический: содержит исторические данные (до N лет)

Короче говоря, процесс выполняется еженедельно, чтобы переместить самые последние записи из Audit Live в Audit Historical. Audit Live запускается с чистого листа после запуска этого процесса.

1. 1. Live DB работает быстро и компактно, что позволяет выполнять вставку как можно быстрее.
   2. Запросы аудита направляются исключительно в Историческую БД.

При использовании этого подхода не происходит неявного «сшивания» оперативных данных и исторических данных. Я бы сказал, что вы, вероятно, захотите сохранить это так.

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

Если вы хотите просмотреть данные аудита в реальном времени, а не данные исторического аудита, вы просто выбираете соединение «Audit - Live» при появлении запроса (это должно быть исключением, а не нормой).

Если вы ДЕЙСТВИТЕЛЬНО хотите предоставить консолидированное представление как в реальном времени, так и в истории, вы можете это сделать, но это повлияет на производительность.

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

Некоторые из наших клиентов создали консолидированное мнение. На наш взгляд, это перебор. При таком консолидированном представлении производительность всегда была бы хуже, и мы не сталкивались со многими вариантами использования, в которых используются как наборы данных в реальном времени, так и исторические. 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 Audit - Live содержит данные аудита за 1 неделю. Данные старше 1 недели перемещаются в базу данных Cognos Audit - Историческая.

Строка из базы данных аудита Cognos - Live to Cognos Audit Database - Historical на диаграмме отвечает за:

• Копирование данных из Live Audit в Historical Audit
• Удалите в Live Audit все строки старше 1 недели.
• Удалите все строки в Historical Audit старше x лет.
• Удалите все строки в COGIPF_ACTION старше 6 месяцев.

Индексы

Разные типы баз данных имеют разные типы индексации. Индекс базы данных - это структура данных, связанная с таблицей (или представлением), используемая для улучшения времени выполнения запросов при извлечении данных из этой таблицы (или представления). Вместе со своим администратором баз данных создайте оптимальную стратегию. Они захотят узнать ответы на подобные вопросы, чтобы принять оптимальное решение о том, какие столбцы индексировать. Очевидно, что администратор базы данных мог бы найти ответы на некоторые или все эти вопросы без вашей помощи, но для этого потребуется некоторое исследование и время:

• Сколько записей в таблицах и до какого размера вы ожидаете их увеличения? (Индексирование таблицы бесполезно, если в таблице нет большого количества записей.)
• Вы знаете, какие столбцы уникальны? Допускают ли они значения NULL? Какие столбцы имеют тип данных целое или большое целое число? (Столбцы с числовыми типами данных UNIQUE и NOT NULL являются сильными кандидатами для участия в индексном ключе.)
• Где ваши основные проблемы с производительностью сегодня? Они извлекают данные? Есть ли конкретные запросы или отчеты, которые представляют собой большую проблему? (Это может привести администратора базы данных к некоторым конкретным столбцам, которые можно оптимизировать.)
• Какие поля используются при объединении таблиц для отчетности?
• Какие поля используются для фильтрации, сортировки, группировки и агрегирования?

Неудивительно, что это те же вопросы, на которые потребуется ответить для повышения производительности любых таблиц базы данных.

Служба поддержки IBM рекомендует создание индекса по столбцам «COGIPF_REQUESTID», «COGIPF_SUBREQUESTID» и «COGIPF_STEPID» для следующих таблиц для повышения производительности:

• COGIPF_NATIVEEQUERY
• 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

Заключение

Суть в том, что с предоставленной здесь информацией вы должны быть хорошо подготовлены к продуктивному разговору со своим администратором баз данных. Скорее всего, она уже решала подобные проблемы раньше.

Предлагаемые изменения в архитектуре базы данных Cognos Audit улучшат производительность как прямой отчетности, так и сторонних приложений, которые на нее полагаются, например MotioАвтора ReportCard и инвентарь.

Между прочим, если у вас был этот разговор со своим администратором баз данных, мы были бы рады услышать об этом. Мы также хотели бы узнать, решили ли вы проблему неэффективной базы данных аудита и как вы это сделали.