MaxL Python Module

Essbase.py is a Python module that provides access to Oracle Essbase multi-dimensional databases using MaxL for Python programs. It is similar in function and usage to the Oracle Essbase Perl module Essbase.pm.

The Essbase Python module interfaces with Oracle Essbase using a Python ctypes module wrapper for the primary MaxL dll (essmaxl.dll or essmaxlu.dll). The ctypes module is standard in Python 2.5+. Versions of the wrapper are included for Essbase 6.5, for Essbase 7-11.1.2.1, and for Essbase 11.1.2.2.

The version 7 wrapper is operational with Essbase 9.3.1 and 11.1.2.1.

The version 11.1.2.2 wrapper is for Essbase 11.1.2.2 (and perhaps above).

Product's homepage

Essbase. Облако. Обучение

Евгений Расюк продолжает развивать свою виртуальную школу Essbase.

Кроме виртуальных тестов на проверку знаний, недавно он запустил EssBase в своем “облаке”. Такой вариант будет интересен тем, кто хочет начать изучение, но не имеет инфраструктуры для работы.

Подробности на essbase.ru.

IBH в базе Essbase

Редко, но можно столкнуться с проблемой появления некорректных (дефектных) заголовков блоков - invalid block headers (IBH), которая описывается в логе приложения Essbase примерно так:

[Wed May 16 22:51:58 2012]Local/AppName/Cube/admin@Native Directory/Error(1006068)

Недопустимый статус транзакции для блока. Для поиска и устранения проблемы воспользуйтесь служебными программами поиска и устранения IBH.

Причинами могут быть:

1. Какой-то сторонний процесс пытается получить доступ с блокировкой к файлам базы данных (куба) Essbase. Например, антивирус или ПО резервного копирования
2. Служба Essbase была остановлена во время извлечения данных или выполнения расчетов. Иными словами, некорректная остановка или "падение" базы данных
3. Проблемы с дисковой подсистемой сервера. Например, ошибки в работе RAID-массивов, bad blocks на накопителях информации
4. Закончилось место на диске
5. Сильная фрагментация диска
6. Сильная фрагментация базы данных (куба)
7. Использование Direct I/O 
8. Слишком маленький кэш данных куба
9. Подобные ошибки встречались в Essbase 6.х и 7.х
    

После проверки всех пунктов из списка выше для решения проблемы можно выполнить на проблемной базе данных (кубе) MaxL скрипт:

alter application 'AppName' disable connects;

alter system logout session on database 'AppName'.'Cube';

alter database 'AppName'.'Cube' validate data to local logfile 'f:\IBH.log';

alter database 'AppName'.'Cube' repair invalid_block_headers;

alter application 'AppName' enable connects;

Этот скрипт проверяет куб на наличие IBH и записывает найденные блоки в указанный лог-файл, а затем удаляет дефектные блоки из базы данных (куба).

Иногда после выполнения скрипта необходимо выполнить реструктуризацию куба, чтобы indeх файл был перестроен с учетом исправления IBH. В идеале - выгрузить данные из куба, очистить его и загрузить данные обратно.

UPD: Кроме того, имеет смысл иметь опцию в essbase.cfg:

IBHFIXTHRESHOLD AppName Cube 10

Эта команда говорит Essbase, что нужно проверять наличие IBH на кубе (это происходит и без указания опции в явном виде) и, в случае превышения порога 10% (пример), базу данных следует корректно остановить. Это сделано, с целью показать, что критическая масса IBH накоплена, и нужно что-то делать. Однако, в EPM 11 за работоспособность Essbase отвечает сервис OPMN, который регулярно пингует службу OLAP-сервера и может заставить запуститься приложение заново.

Наш соратник Евгений Расюк добавляет, и я его поддерживаю:

• Всегда нужно иметь бэкап с выгруженными данными в текст. Это хоть и долго, на гораздо надежнее простого копирования файлов куба - "это видимость бэкапа" - в таком случае все проблемы (например, IBH) будут также занесены в бэкап
• Нужно стараться проектировать модели таким образом, чтобы исключить кастом расчеты на агрегируемых уровнях

Настройка сервера и клиента для работы со SmartView

В ходе эксплуатации системы во время работы, SmartView (над Planning/Essbase) может "обрадовать" пользователя сообщениями вроде:

• The request timed out. Contact your administrator to increase netRetrycount and netRetryInterval
• Request grid size is more than allowed limit

Чтобы избежать первой проблемы, связанной с сетевыми параметрами, необходимо корректно настроить как серверную, так и клиентскую стороны системы:

1. Прописываем сетевые параметры на сервере в essbase.cfg (или через EAS Console):

NETDELAY 1000
NETRETRYCOUNT 600
NETTCPCONNECTRETRYCOUNT 1000

2. В соответствии с рекомендацией Oracle "The Combined Parameters of NETDELAY and NETRETRYCOUNT" [ID 877432.1] произведение параметров NETDELAY и NETRETRYCOUNT не должно превышать 10 минут. На этот лимит и будем всё настраивать. Пример расчета:

1000 for NETDELAY
600  for NETRETRYCOUNT
1000 x 600 = 600000
Divide by 1000 = 600
Divide by 60 = 10 minutes

3. Перезапускаем сервер Essbase (службу OPMN), чтобы изменения вступили в силу.
4. Готовим изменения реестра операционных систем на клиентских станциях (на базе Windows XP; Windows 7), используя параметры: 
   
   • KeepAliveTimeout (интервал проверки активности HTTP-соединений) и ServerInfoTimeout, причем второй нам понадобится, т.к. значение первого превысит 2 минуты; значение второго параметра идентично значению первого
   • ReceiveTimeout (ограничение на время возврата данных от сервера)
5. В соответствии с рекомендацией Oracle "Smart View Error: The request timed out. Contact your administrator to increase netRetrycount and netRetryInterval" [ID 744559.1] и "FDM Timeout on Import When Using Internet Explorer 7" [ID 1246294.1] получаем файл (*.reg) для внесения изменений в реестр на клиентской станции:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings]
"ReceiveTimeout"=dword:000927c0
"ServerInfoTimeout"=dword:000927c0
"KeepAliveTimeout"=dword:000927c0

где 000927c0 - это 600000 мсек в HEX-представлении

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

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

1. Прописываем параметр на сервере в essbase.cfg (или через EAS Console):

MAX_REQUEST_GRID_SIZE EssbaseAppName 5000000

2. В соответствии с рекомендацией Oracle "When Executing MDX Query Network Error Occurs: "[10054] Cannot Send Data" [ID 1071407.1] необходимо также настроить сетевые параметры на сервере. Это мы уже сделали, борясь с первой проблемой :)
3. Перезапускаем сервер Essbase (службу OPMN), чтобы изменения вступили в силу.

MaxL по расписанию

Часто бывает необходимым поставить выполнение MaxL скрпита в расписание. Причем этот скрипт создан в EAS Console и хранится на сервере. Я решил эту задачу созданием batch файла, который ставится в расписание Windows Server:

@echo off
rem - Input parameter is a name of MaxL script (only name w/out extension)

Входящим параметром является имя MaxL скрпита без расширения.

setlocal
cls

Rem Set Variables
SET ESSSETENV=F:\Oracle\Middleware\user_projects\epmsystem1\EssbaseServer\essbaseserver1\bin\setEssbaseEnv.bat
SET SERVER=EssbaseServerNameOrIP
SET USER=Ess_admin_name
SET PASSWORD=Ess_password
Rem See more info about Encyption on https://forums.oracle.com/forums/thread.jspa?threadID=1021677
SET PKE=set_your_Public_Key_for_Encryption
SET PKD=set_your_Private_Key_for_Decryption
SET MaxLPath=F:\Oracle\Middleware\EPMSystem11R1\products\Essbase\eas\storage\mxlscripts\%USER%
SET EADMaxl=%MaxLPath%\%1

Вся информация сохранится в логе, имя файла которого задается переменной EXECLOG.

SET EXECLOG=AutoStartMaxL-%1.log
SET RunMaxl=AutoStartMaxL.mxl
SET CurrDir=%CD%

echo Started: %date% @ %time% > %CurrDir%\%EXECLOG%

Поскольку в консоли вход и подключение производить не нужно, а внешним скриптом - необходимо, добавляем строки входа (login) и завершения работы (logout и exit).

Rem - Generate MaxL Script - Start
echo login '%USER%' '%PASSWORD%' on '%SERVER%'; > %CurrDir%\%RunMaxl%

Сам скрипт считываем из исходного файла на сервере.

Rem - Read original MaxL
For /F "eol=; delims=/" %%i In (%EADMaxl%) Do (
    echo %%i ) >>  %CurrDir%\%RunMaxl%

echo logout; >> %CurrDir%\%RunMaxl%
echo exit; >> %CurrDir%\%RunMaxl%
Rem - Generate MaxL Script - Finish

Rem Set Essbase Env
call %ESSSETENV%

Сам скрипт запускаем в шифрованном виде. 

Rem Encrypt MaxL Script
essmsh -E %CurrDir%\%RunMaxl% %PKE% > nul
Rem Del Original MaxL Script
del %CurrDir%\%RunMaxl% > nul
Rem Run Encrypted MaxL Script with LOG
essmsh -D %CurrDir%\%RunMaxl%s %PKD% >> %CurrDir%\%EXECLOG%

echo ... >>  %CurrDir%\%EXECLOG%
echo Script: >>  %CurrDir%\%EXECLOG%
For /F "eol=; delims=/" %%i In (%CurrDir%\%RunMaxl%s) Do (
    echo %%i ) >>  %CurrDir%\%EXECLOG%
echo ... >>  %CurrDir%\%EXECLOG%

Rem Del Encrypted MaxL Script
del %CurrDir%\%RunMaxl%s >> %CurrDir%\%EXECLOG%

echo Finished: %date% @ %time%  >> %CurrDir%\%EXECLOG%

Добавляем в расписание (Task Scheduler) задачу на выполнение нашего bat-файла с параметром - именем MaxL скрпита.

 

17,7 секунд - быстро, но долго

Перемещено из блога Oracle Hyperion Planning: заметки администратора с разрешения автора - Романа Удальцова

Запуск бизнес-правил из командной строки с использованием Hyperion CmdLineLauncher – это удобно в ситуации, когда необходимо многократно запускать вручную кучу последовательностей, содержащих в себе большое число бизнес-правил. Один раз автоматизировал, и сиди себе запускай батничек.

Но обнаружилась интересная особенность. При запуске из командной строки любое бизнес-правило выполняется на некоторую константу дольше, чем при запуске его же из нативной последовательности Essbase. Покажу на примере...

У меня запускается ряд последовательностей, содержащих в себе в общей сложности 547 бизнес-правил. Очень многие из них, судя по hbrlaunch.log, выполняются за доли секунды.

Статистика автоматизированного запуска из командной строки выглядит следующим образом (число бизнес-правил / время выполнения):

Самое интересное происходит в левой части графика:

Видно, что ни одно бизнес-правило не выполнилось быстрей, чем за 17,7 секунд.

Простая арифметика показывает, что на моем примере это целых... 17,7 х 547 = 9681,9 сек. = 2 часа 41 минута 21,9 секунды, потраченные непонятно на что! Распараллеливание запусков бизнес-правил несколько уменьшает это время (примерно до полутора часов), но от этого не легче.

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

UPD
Завёл по этому поводу SR, за 3 дня переписки ничего толкового не посоветовали.
Их резюме – «I'm afraid that we have no other reports of this timing difference nor any documentation that would explain why it might occur. If you believe that this is a significant issue I could test it and then raise it with Development as a bug, although I'm not sure they would accept it as such.»

UPD2
Финальный ответ от Oracle.
Мое предположение подтвердилось. Ну и надо учесть время подключения к EAS:
«I have been able to get an explanation as to why the rules will take longer to run when launched via the cmdlnlauncher: CmdLnLauncher has to connect to remote EAS server in order to launch the rule. For Planning, the rule engine runs within the same JVM and that's why it can launch the rule faster compared to CmdLnlauncher.»

CmdLineLauncher - Параллельное выполнение бизнес-правил

Перемещено из блога Oracle Hyperion Planning: заметки администратора с разрешения автора - Романа Удальцова

Возникла задача ускорить выполнение немаленькой (под 500 шагов) последовательности бизнес-правил. При внимательном рассмотрении выяснилось, что часть из них может выполняться параллельно, чем я и воспользовался с помощью стандартной утилиты Hyperion CmdLineLauncher (лежит в \Hyperion\products\Essbase\eas\console\bin\).

Результатом творческого поиска стала следующая конструкция:

/logs/*.log – логи последнего запуска, старые складываются в logs.rar
/prompts/*.prompts – временные файлы значений переменных
/sys/ – служебные файлы и скрипты, см. подробности далее
Описание последовательности.txt – специально подготовленный текстовый файл
Запуск бизнес-правил.bat – запуск выполнения последовательности

Процесс начинается с подготовки файла Описание последовательности.txt. По сути, это csv-файл следующего вида:

Application;Rule;DBName;Year;Scenario;Version;Entity;Parallel[0/1]
Прил1;Бизнес-правило 1;Plan1;FY11;Budget;Version 1;ЦФО 1;1
Прил1;Бизнес-правило 1;Plan1;FY11;Budget;Version 1;ЦФО 2;0
Прил1;Бизнес-правило 2;Plan1;FY11;Budget;Version 1;-;0

Некоторые пояснения:
– Полное название бизнес-правила включает в себя префикс в виде наименования приложения, оно было выделено в отдельный столбец просто для удобства подготовки файла, позже 1 и 2 столбцы склеиваются
– В столбцах перечисляются все возможные измерения, элементы которых могут встречаться во входных параметрах бизнес-правил
– В случае отсутствия значения (например, Прил1.Бизнес-правило 2 не требует Entity) ставится символ -
– Первая строка форматируется произвольно, т.к. она исключается из обработки
– Parallel можно читать следующим образом: Следующий шаг выполняется [1 – параллельно / 0 – последовательно] с текущим

Таким образом, в приведенном выше примере Прил1.Бизнес-правило 1 будет запущено на параллельное выполнение для ЦФО 1 и ЦФО 2, после чего выполнится Прил1.Бизнес-правило 2 (последовательно).

Далее "Описание последовательности.txt" скармливается скрипту "Запуск бизнес-правил.bat" (запуск из cmd вида "Запуск бизнес-правил.bat" "Описание последовательности.txt" или просто drag-n-drop):

@echo off
chcp 1251 >nul

:: Определение пути к папке HBRLauncher
set HBRPath=%~dp0
set HBRPath=%HBRPath:~0,-1%

:: Определение общих параметров
call "%HBRPath%\sys\Глобальные переменные.cmd" %HBRPath%

:: Архивация старых логов
%HBRPath%\sys\rar.exe m -ep1 -idp %HBRPath%\logs\logs.rar %HBRPath%\logs\*.log >nul

:: Удаление старых временных файлов значений переменных
if exist %HBRPath%\*.prompts del %HBRPath%\*.prompts

:: i:App – j:Rule – k:DBName – l:Year – m:Scenario – n:Version – o:Entity – p:Parallel[0/1] – q:Timeout

for /f "usebackq skip=1 eol=# tokens=1-9 delims=;" %%i in (%1) do (
echo [%%i][%%k][%%l][%%m][%%n][%%j][%%o]
if '%%p'=='1' start "" /d"%HBRPath%\sys\" /min %HBRPath%\sys\RunHBR.bat "%%i" "%%j" "%%k" "%%l" "%%m" "%%n" "%%o"
if '%%p'=='0' start "" /d"%HBRPath%\sys\" /min /w %HBRPath%\sys\RunHBR.bat "%%i" "%%j" "%%k" "%%l" "%%m" "%%n" "%%o"
timeout %%q >nul
)

Основные шаги понятны из комментариев, вот несколько уточнений:
– Строки входного файла можно комментировать символом, указанным в eol, в данном случае #
– Разделители меняются в delims, например, можно заменить ; на или любой другой на ваш вкус
– Между запусками установлен таймаут 4 секунды, если timeout у вас не работает (он входит в Windows Resource Kit), можно использовать конструкцию вида ping -n 5 127.0.0.1>nul (необходимое число секунд + 1)
– skip указывает на число игнорируемых верхних строк

Здесь используется довольно простой скрипт для назначения общих переменных \sys\Глобальные переменные.cmd:

:: Входные переменные: %HBRPath%
@echo off

:: Essbase Administration Server
set EAS=EASServerName

:: Логин
set User=admin

:: Активное приложение
set App=Essbase/EssbaseServerName/AppName/

:: Зашифрованный пароль – файл формируется отдельно (см. \Essbase\eas\console\bin\PasswordEncryption.bat)
set PwdFile=%HBRPath%\sys\%User%.password

Как видно из Запуск бизнес-правил.bat, он построчно обрабатывает входной текстовый файл и в зависимости от параметра Parallel запускает \sys\RunHBR.bat в указанными в строке входного файла параметрами в параллель (1) с промежутками в 4 секунды, либо перед запуском следующего бизнес-правила ожидает завершения текущего (0).

А вот сам \sys\RunHBR.bat, запускающий CmdLineLauncher:

:: 1:App - 2:Rule - 3:DBName - 4:Year - 5:Scenario - 6:Version - 7:Entity

:: Запись входных параметров бизнес-правила (с удалением кавычек)
set Rule=%~1.%~2
set DBName=%~3
set Year=%~4
set Scenario="%~5"
set Version="%~6"
set Entity="%~7"

:: Лог-файл
set Log="%HBRPath%\logs\%date:~6,4%%date:~3,2%%date:~0,2%.%time:~0,2%%time:~3,2%%time:~6,2%%time:~9,2%.%~2.%~7.log"

:: Начало выполнения
echo [%date:~0,2%.%date:~3,2%.%date:~6,4% %time:~0,2%:%time:~3,2%:%time:~6,2%.%time:~9,2%] – Начало выполнения бизнес-правила "%Rule%" (%~7) 1>>%Log%
echo. 1>>%Log%

:: Путь к временному файлу значений входных переменных
set Prompts="%HBRPath%\prompts\%date:~6,4%%date:~3,2%%date:~0,2%.%time:~0,2%%time:~3,2%%time:~6,2%%time:~9,2%.%~2.%~7.prompts"

:: Формирование файла значений переменных
echo %Rule% >>%Prompts%
echo ExecDB::%App%%DBName% >>%Prompts%

if not [%Year%]==[-] echo YearPrompt::"%Year%" >>%Prompts%
if not [%Entity%]==["-"] echo EntityPrompt::"%Entity%" >>%Prompts%
if not [%Version%]==["-"] echo VersionPrompt::"%Version%" >>%Prompts%
if not [%Scenario%]==["-"] echo ScenarioPrompt::"%Scenario%" >>%Prompts%

:: Запуск бизнес-правила
call %HBRPath%\sys\CmdLineLauncher -p:"%PwdFile%" -S%EAS% -U%User% -r"%Rule%" -f%Prompts% 1>>%Log% 2>&1

:: Удаление файла значений переменных
del %Prompts%

echo. 1>>%Log%
echo [%date:~0,2%.%date:~3,2%.%date:~6,4% %time:~0,2%:%time:~3,2%:%time:~6,2%.%time:~9,2%] – Окончание выполнения бизнес-правила "%Rule%" (%~7) 1>>%Log%

exit