Настройка протоколов аудита работы Essbase

 

Essbase предоставляет простую и мощную систему для контроля своей работы, которую можно масштабировать, в зависимости от предъявляемых требований к системе. Существует несколько уровней логирования от info до critical, определяемых параметрами AGENTLOGMESSAGELEVEL и LOGMESSAGELEVEL в конфигурационном файле essbase.cfg, располагающимся в каталоге %HYPERION_HOME%\AnalyticServices\bin.

 

В системе предусмотрено двухуровневое логирование : на уровне сервера и на уровне приложения.

1 Анализ логов

Происходит посредством «ручного» просмотра файла с логами работы системы. Обычно это требуется при возникновении «внешних» признаков неработоспособности системы

•    неприемлемо долгое время ответа системы на запрос получения данных

•    генерация *.xcp файлов

•    и прочие ошибки

На основе файла логов приложения можно , с помощью инструментария предоставляемого Administration Service Console, анализировать активность пользователей и загрузку сервера.

Подробности о количестве и составе файлов, в которых пишется деятельность сервера, и о протоколируемой информации в Analytic Server смотрите в документе

2 Настройки системы, влияющие на состав и уровень протоколируемой информации

 

2.1. Настройки протоколирование на уровне сервера

AGENTLOGMESSAGELEVEL – настройка файла essbase.cfg, которая определяет, что бы Analytic Server писал все сообщения (INFO), либо сообщения о предупреждениях (WARNING), либо только сообщения об ошибках (ERROR) в файл протоколирования Analytic Server.

PORTUSAGELOGINTERVAL – настройка файла essbase.cfg, которая определяет интервал для записи в лог количество свободных и занятых портов

2.2. Настройки протоколирование на уровне приложения

LOGMESSAGELEVEL (INFO,WORNING,ERROR) настройка файла essbase.cfg, которая определяет что бы Analytic Server писал либо все сообщения, либо предупреждения, либо ошибки в файл логов приложения

TIMINGMESSAGES (TRUE | FALSE) настройка файла essbase.cfg, которая определяет что бы Analytic Server писал длительность выполнения каждого пользовательского запроса на получения данных.

SSLUNKNOWN (TRUE | FALSE) настройка файла essbase.cfg, которая определяет что бы Analytic Server писал сообщения о ошибке включающие в себя запросы на получение значений с несуществующих элементов.

SET MSG настройка в файле скрипта, которая определяет как и что Analytic Server буде писать в лог приложения (Суммарную статистику по этому скрипту, расширенную стистику, настрйку уровней сообщений (без них, ошибки, предупреждения, все сообщения)

2.3. Настройка протоколирования пользовательских запросов

Для включения опции протоколирования пользовательских запросов, создайте файл dbname.cfg в директории базы данных используя следующей синтаксис:

•    Определение направления, обращения к которому будет протоколироваться QUERYLOG [dimension_name]

•    Глубина протоколирования по поколениям или по уровням: QUERYLOG GENERATION generation-range or QUERYLOG LEVEL level-range)

•    Исключение из протокола запросов: QUERYLOG NONE GENERATION generation-range or QUERYLOG NONE LEVEL level-range

•    Включать в протокол запросы к элементам нулевого уровня при HOLAP QUERYLOG LOGHAMBRS ON | OFF

•    Месторасположение файла логов QUERYLOG LOGPATH path-expression

•    Формат логов файлов QUERYLOG LOGFORMAT CLUSTER | TUPLE

•    Размер одного файла логов QUERYLOG LOGFILESIZE n

•    Общий размер всех файлов QUERYLOG TOTALLOGFILESIZE n

•    Включить или выключить логирование при следующем запуске базы QUERYLOG ON | OFF

 

Пример файла
# Log the Product dimension
QUERYLOG [Product]
# Log Hybrid Analysis members of Product, if applicable
QUERYLOG LOGHAMBRS ON
# Log the Market dimension
QUERYLOG [Market]
# Log members of generation 2 of Market by generation number
QUERYLOG GENERATION 2
# Display log output in cluster format
QUERYLOG LOGFORMAT CLUSTER
# Create log file in C:\QUERYLOG\
QUERYLOG LOGPATH C:\QUERYLOG\
# Start a new log file after an individual log file size reaches 2 MB
QUERYLOG LOGFILESIZE 2
# Turn off query logging after the total size of all log files reaches 1024 MB (1 GB)
QUERYLOG TOTALLOGFILESIZE 1024
# Enable query logging
QUERYLOG ON

2.4. Настройка протоколирование изменений структуры метаданных

OUTLINECHANGELOG (TRUE | FALSE) настройка файла essbase.cfg, которая имеет значение TRUE, для создания файла протоколов изменений

OUTLINECHANGELOGFILESIZE n настройка файла essbase.cfg, которая определяет максимальный размер файла протокола.

2.5. Настройка протоколирования создания направлений

DATAERRORLIMIN n настройка файла essbase.cfg, которая определяет максимальное количество записей в файле dataload.err

2.6. Очистка файла протоколов работы сервера

CLEARLOGFILE (TRUE | FALSE) настройка файла essbase.cfg, в значении TRUE очищает лог сервера или приложений в случае их перезапуска

Transparent partition

Transparent partition

 

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

 

 

Так как данные берутся прямо из источника, пользователь получает их последнюю версию. При обновлении данных пользователем, сделанные изменения переносятся обратно в источник. Это означает, что как у пользователей, находящихся у источника, так и у тех, кто находится у получателя данных, имеется непосредственный доступ к этим изменениям.

 

Прозрачные области, разделяемые схемами источника и получателя, не обязательно должны быть абсолютно одинаковыми. Главное требование – установить их соответствие друг другу. Это значит,что необходимо указать, каким образом каждое аналитическое направление и элемент источника будут отображены в соответствующих аналитических направлениях и элементах получателя.

Отображение соответствия схем данных источника и получателя не обязательно для схем неразделяемых областей.

Прозрачный раздел можно создать поверх реплицированного. Иными словами, можно создать получатель прозрачного раздела, используя источник реплицированного раздела.

Прозрачный раздел нельзя создавать поверх более чем одного раздела иного рода. Другими словами, нельзя создать получатель прозрачного раздела на основании нескольких источников.

Причина в том, что каждая ячейка базы данных берется только из одного места – локального или удаленного диска.

 

Преимущества :

Требуется меньше пространства на диске, так как информация хранится в одной базе данных.

Данные, запрашиваемые из получателя, всегда последние по времени.

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

Размер отдельных баз данных меньше, поэтому расчеты производятся быстрее.

Распределение данных невидимо для конечного пользователя и его инструментов.

Данные можно загружать и из источника, и из получателя.

 

Недостатки :

Прозрачные разделы повышают нагрузку на сеть, так как данные переносятся по сети от источника к получателю. Повышенная нагрузка на сеть приводит к замедлению получения данных пользователями.

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

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

Некоторые административные операции можно выполнять только на локальных данных. Например, если архивируется получатель, то при этом не архивируется источник данных. Следующие административные операции выполняются только на локальных данных:

•    CLEARDATA;

•    DATACOPY;

•    EXPORT;

•    VALIDATE;

•    BEGINARCHIVE и ENDARCHIVE;

•    прочие операции по преобразованию в Диспетчере приложения;

 

Настройки производительности для Transparent Partitions

 

  • Разделение плотных аналитических направлений в прозрачном разделе может значительно замедлить скорость работы. Причина в том, что плотные аналитические направления используются для определения структуры и содержания блоков данных. Если база данных разделена только по плотному аналитическому направлению у получателя, системе потребуется составление блоков данных путем выполнения сетевых запросов удаленных данных в прозрачном разделе, помимо ввода-вывода данных для локальной части блока.
  • Загрузка данных в источник из получателя значительно снижает скорость работы. Данные по возможности следует загружать в источник локально.
  • Время извлечения информации замедляется, так как пользователи запрашивают данные через сеть
  • Для контроля работы можно использовать параметр ENABLE_DIAG_TRANSPARENT_PARTITION в файле essbase.cfg

 

Использование в расчетах Transparent Partitions

Когда выполняется расчет на transparent partition, Essbase выполняет расчет с использованием существующих значений локальных данных и зависимых от партиции. Когда расчет доходит до данных из партиции, то он работает в режиме bottom-up, если выполняется условие по оптимальному использованию кеша калькулятора. Увеличение его размера значительно повышает производительность расчетов, за счет уменьшения итераций по выборке данных из источника – это можно наблюдать, просматривая лог расчета, в сообщениях об использовании кеша калькулятора в целевой БД. Так же расчет сильно зависит от top-down формул на элементах.

Если вы абсолютно уверены в том, что ваш расчет не зависит от данных, лежащих на удаленной БД , можете смело использовать команду SET REMOTECALC OFF

 

 

 

 

 

Описание иерархий

Связи между направлениями и элементами.

Essbase использует иерархическую ( поколения(generations) и уровни(level); и корни (roots) и листья(leaves)) и «родительские» описание ( родители(parents), дети(children), братья(siblings); потомки(descendants) и прародители(ancestors)) для определения ролей и связей элементов в измерениях в описании метаданных МДБ.

 Member Generation and Level Numbers


Родители (parents), дети (children) и братья (siblings)

 

Потомки(descendants) и прародители(ancestors)

Узлы(roots) и листья (leaves )

Поколения (generations) и уровни (levels)

Элементы направлений и Измерения

В данном разделе объясняются понятия Outlin’a, измерений и направлений в многомерной базе данных (МБД).

Измерения(направления) – это самый верхний уровень в описании метаданных МБД. Описание метаданных (Outline) содержит в себе древовидную структуру с выделенными связями консолидации. Например, на картинке , элемент Year – это направление ( с типом Time) и Qtr1 это элемент.

Essbase имеет как стандартные так и атрибутивные направления.

Стандартные направления – это центральный компонент бизнес планирования , напрямую отображающее предметную функциональность реализованную в модели. Примеры стандартных измерений : Time, Accounts, Product Line, Market и Division. Измерения изменяются гораздо менее чаще, чем элементы, из которых они состоят.

Аттрибутивные направления связаны со стандартными измерениями. Через атрибутивные направления можно группировать и анализировать элементы стандартного направления основываясь на характеристиках этого элемент. Например, можно анализировать продажи по типу, цвету, вкусу, продаваемой продукции, которая может иметь другую группировку элементов в основной иерархии.

Элементы направления – это независимые друг от друга сущности измерений. Например , Product A, Product B, and Product C могут быть элементами направления Product. Каждый элемент должен иметь уникальное имя (данное поведение определяется настройками МБД), и иметь множество псевдонимов (10?32?) определенных в алиасных таблицах. Essbase хранит данные элементы ассоциировано и сменем этого элемента, и это напрямую влияет на перестройку модели в случае массового переименования элементов. Так же данные могут быть рассчитаны динамически , на основании формулы, хранимой в свойствах элемента.