XREF vs Partitions

Наверное на каждом проекте мы сталкиваемся с необходимостью обмениваться данными между кубами. Для этого в Essbase есть специальные инструменты: XREF, Replicated Partition, Transparent Partition.

Рассмотрим их по порядку.

XREF - cамый простой и безболезненый способ получить данные из другого куба, минусы - это низкая производительность и проблемы с созданием блоков (в 11.1.2 добавили @XWRITE). Не рекомендую использовать XREF в формулах динамических элементов (Dynamic Calc) т.к. на больших срезах это приводит к потере производительности.
Пример использования: получить значение по ограниченному срезу.

Replicated partition -  если вам надо копировать блоки нижнего уровня 1:1 без всяких расчетов и транформаций, то что надо. Есть функциональность по переносу только обновленных данных.
Пример использования: передать данные по статье A по нижнему уровню из Source в Target.

Дополнительная информация - http://essbase.ru/2010/10/replicated-partitions/

Transparent partition - мощный инструмент для маштабирования. Если сравнивать с Oracle RDB - это аналог view или updateable view. Имеет ряд особенностей связанных с тем, что данные не хранятся в Target кубе, а подтягиваются налету. Пример: в Target по данным из партиции невозможно создать блоки, выгрузить данные с помощью Dataexport и т.д. Но что очень интерестно - из Target можно обновлять данные в Source!
Пример использования: разделение приложения на Факт и План с партицией по сценарию, разделение по странам, версиям и т.д.

Дополнительная информация - http://essbase.ru/2010/10/transparent-partition/

Сравнительная таблица:

* в 11.1.2 добавлена функция @XWRITE, которая позволяет записывать данные в Target
** данные изменяются только после запуска обновления партиции или вызова XREF
*** write-back функциональность

Пример MaxL создание Replicated partition и ее обновление:

create or replace replicated partition 'RP_ACT'.'RP'
area '"ACT"' sourcearea1
to 'RP_BUD'.'RP'
area '"ACT"' targetarea1;

refresh replicated partition RP_ACT.RP to RP_BUD.RP at 'localhost' all data;

refresh replicated partition RP_ACT.RP to RP_BUD.RP at 'localhost' updated data; 

P.S. Выгрузка и загрузка данных с помощью Dataexport, Report script, MDX в данном случае не рассматривались
P.S.S. Source - это куб источник. Target - куб получатель данных.
P.S.S.S. Если производительности XREF не хватает, смотрите в сторону партиций. Если партиции не устраивают, то используйте Dataexport

Берегись пустых блоков

Агрегирует ли Essbase пустые блоки? Сейчас узнаем.

1. Очищаем куб Sample.Basic и смотрим количество существующих блоков:

2. Вводим число 1.

3. Меняем 1 на #Missing

4. Смотрим количество существующих блоков:

• Existing level 0 blocks - 1
• Existing upper-level blocks - 0

5. Запускаем скрипт агрегации:

     SET AGGMISSG ON;
     CALC ALL;

6. Смотрим количество существующих блоков:

• Existing level 0 blocks - 1
• Existing upper-level blocks - 8!!!

Вывод - независимо от того есть ли данные в какой-либо ячейке или нет Essbase агрегирует данные (создает блоки верхнего уровня), что приводит к увеличению времени расчета и увеличению размера БД.

Что делать - удалить пусты блоки можно командой "CLEARBLOCK Empty;"

Как еще бороться с ненужными данными:

• Удаляйте нули (часто пользователи вместо #Missing вносят "0")
• Правильно удаляйте ненужные срезы командами CLEARBLOCK или CLEARDATA (не фиксируйте плотные элементы).
• Выгружайте нулевой срез в реляционную таблицу и анализируйте данные (часто много ненужных цифр залипают на Begbalance, архивных статьях и т.д.)

P.S. Еще один пример скрипта и его краткого лога, где агрегация работает неэффективно

/* параметр логировая */
SET MSG SUMMARY;

/* удаляем все блоки*/
CLEARBLOCK ALL;

/* создаем один блок c Jan = 100*/
SET CREATENONMISSINGBLK ON;
FIX ("New York",    "100-10",    "Sales", "Actual")
    "Jan" = 100;
ENDFIX
SET CREATENONMISSINGBLK OFF;

/* агрегируем Feb */
SET AGGMISSG ON;
FIX ("Feb")
   CALC DIM ("Measures", "Product", "Market", "Scenario");
ENDFIX

/* удалили */
Clearing all data blocks from [(ALL)] partition
Removed [9] data blocks

/* создали один блок */
Calculating [ Year(Jan)] with fixed members [Sales; 100-10; New York; Actual]
Create Blocks on Equations: [Enabled]
Create Non #Missing Blocks: [Enabled]
Total Block Created: [1.0000e+000] Blocks

/* создали 7 блоков */ 
Calculating [ Measures, Scenario, Product, Market, with fixed members [Year(Feb)]
Aggregate #Missing values:  [Enabled]
Total Block Created: [7.0000e+000] Blocks

Я сделал запись в Jan, а агрегировал по Feb - все равно блоки создаются. Это конечно же не ошибка, а особенность работы Essbase, которую надо учитывать.

Hyperion Roadmap 2011

Hyperion Essbase 11.1.3

• Full integration with BI Foundation installation
• Oracle Business Intelligence Essbase Integrator
• Fusion Middleware Integration
• Active-Active high availability clustering
• User-defined objects
• ASO calc extensions
• Storage optimization
• Metadata integration
• Fast-restructure of ASO outline changes
• BSO restructure performance improvements
• Parallel-calc performance improvements
• Enterprise Manager replace EAS admin functionality
• Unify capabilities in Studio and EAS
• Essbase as a Studio Source

Hyperion EPM 11.1.3

• New Project Planning module
• New Chart of Accounts Manager module
• Portfolio wide Enterprise 2.0 adoption
• Hyperion Financial Management
• Configurable Dimensionality
• Financial Close
• Variance Monitoring
• Disclosure Management
• Collaborative document authoring
• Smart Rounding & Footing
• Hyperion Planning
• PSB Commitment control
• Valid combinations
• ASO Integration

http://www.oracle.com/ocom/groups/public/@opnpublic/documents/webcontent/177623.pdf

Парсер логов calcmgrlaunch.log

Предлагаю вашему вниманию парсер логов расчетов Calc Manager 11.1.1.x. Данный парсер ищет окончание расчета и выводит результат в удобном виде.

1. Скачиваем файл Excel с макросом BR_log.xls

2. Копируем файл /logs/calcmgr/calcmgrlaunch.log на локальный компьютер

3. Открываем BR_log.xls и жмем кнопку "Open calcmgrlaunch.log"

3. Наслаждаемся видом :)

P.S. Файл лога обязательно должен называться calcmgrlaunch.log