get Oracle SmartView plugin

essbase: Number of Databases per Application

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

/* У меня есть одно желание –  , всех кто осознано использует более одной БД в приложении Planning отправлять к “столбу позора” */

Continue reading “essbase: Number of Databases per Application”

EssBase AntiPatern: Использование SumRange

Снова об АнтиПатерн, теперь поговорим о
использовании SumRange

Бизнес – требование :
Требуется вычислить показатель в разрезе какой-либо аналитике по указанному признаку
Как можно сделать :
использовать функции @SumRange ()
в виде SalesExpenses= @SumRange (Expenses,@UDA(CFO,”SALES”))

Почему так делать не стоит:
Essbase вынужден обращаться к OTL для расчета каждого кореспондирующего значения CFO

Что делать:
использовать неявные циклы в Essbase

CFO_Sales_NA(
SalesExpenses=0;
)
Fix(@UDA(CFO,”SALES”))
SalesExpenses(
SalesExpenses->CFO_Sales_NA=SalesExpenses->CFO_Sales_NA+SalesExpenses;
)
endfix

Переход с SUN JVM на BEA Jrockit

Неплохая статья, по поводу миграции параметров в новой Java машине

Ниже примерные стартовые параметры , с которых нужно начать настройку распределения памяти в Hyperion Planning 11.1.2.х

Эти параметры не являются готовым рецептом для всех окружений. Используйте их на свой страх и риск.
Continue reading “Переход с SUN JVM на BEA Jrockit”

EssBase AntiPatern: Адресация внутри расчета

Продолжаю цикл АнтиПатерн, теперь поговорим о
Адресации внутри скрипта

Бизнес – требование :
Требуется один из показателей рассчитать нарастающим итогом, т.е. каждый следующий элемент должен содержать сумму предыдущих
Как можно сделать :
использовать функции @PRIOR (), @CURRMBRRANGE(“Analytics” ,LEV, 0, -1, -1)

Почему так делать не стоит:
Для того что бы посчитать текущее значение EssBAse должен выгрузить предыдущее, т.е. цикл расчета состоит из следующих этапов
1) получить текущее значение
2) получить предыдущее значение
3) посчитать
4) сохранить

Что делать:
использовать переменные Essbase, что бы цикл сократился до 3-х шагов.
например след. образом

var vAdditiveValue = 0;

Fix(@RELATIVE(Analytics,0))
Account1(
if (not @ISMBR(AnalyticsFirstMember) )
Account2=vAdditiveValue+ Account1;
vAdditiveValue= Account2;
else
vAdditiveValue= Account1; /* vAdditiveValue=0;*/
endif;
)
endfix

EssBase Calc Performance: еще раз о производительности

Последнее время я посветил настройке производительности расчетов Essbase на одном из проектов в телекоме. Благодаря грамотно поставлено целям и правильной мотивацией ) были решены задачи повышения скорости расчетов , например с 6 часов до 15 минут.
После всего этого, я утвердился в истинности пяти простых правил, которые позволяют сразу делать “быстрые” расчеты

Хоть они уже и банальны, но их стоить обозначить для ориентира :

1) всегда рассчитываем наименьший возможный срез данных
а) aгрегировать значения только с помощью каскадных функций
b) категоричный запрет в использовании расчетов от модели (CREATENONMISSINGBLK ON )
c) разбавляем одну или две sparce аналитики d-calc элементами
d) запрет на повсеместное использование SUMRANGE, – особенно в Dcalc.
e) использовать переменных расчетов EssBAse (или “технические” срезы), что бы сократить кол-во переходов по срезам данных
g) промежуточный расчеты обязательно сохраняем , лишний раз не пересчитываем.

2) Если модель больше 14 измерений, то блок состоит из 3-х аналитик
a) Размер блока может быть любым, пик оптимальности в районе 350K
b) Если периоды в блоке , то кварталы всегда динамические
с) Прочий DCALC в блоке должен быть максимально простым, вся вычурная логика в расчетах.

3) Минимизация автоматических транзакций между приложениями
a) Все партиции, XWRITE и Xref заменяем на export -> import
b) ReportScript и MDX не должны обращаться к более чем двум Sparce DCALC
c) В ряде случаев самым оптимальным вариантом – это создание промежуточных приложений, чем “долгий” ReportScript или DataExport

4) Реструктуризация приложений на регулярной основе
а) Для ввода используется только элементы нулевого уровня
b) Агрегаты – это действительно агрегаты , а не произвольный функциональный расчет на элементах верхнего уровня.
c) Придерживаемся золотого правила – одно приложение – один куб

5) Любое предположение по оптимизации нуждается в проверке
а) Разработчик должен разрабатывать и тестировать модель в изолированной среде на всем возможном (производственном) объеме данных
b) Допускается первичные итерации на “технических” данных и “приближенных” моделях