Скрытые параметры essbase в 11.1.2.4

В процессе обновления essbase до 11.1.2.4 (c 11.1.2.3.500) столкнулись с несколькими проблемами. Хочу поделиться частью из них.

Во-первых, это (вполне закономерно) новый параметр QUERYRESULTLIMIT. Значение по-умолчанию 1,000,000 и этого слишком мало. Параметр ограничивает количество возвращаемых запросом строк. Кажется, что 1,000,000 – это уже очень много и столько данных форма показать не способна. Проблема здесь в том, что это прогноз возвращаемых данных ещё до выполнения запроса. В нашем случае этот прогноз давал неверные оценки (в реальности возвращалось несколько чисел), так что пришлось увеличить значение параметра до 3,000,000.

Во-вторых, гибридный режим вычислений. Узнать о том, что essbase производит вычисления в гибридном режиме, можно по записям в его логе

Hybrid Aggregation Mode enabled.
MaxL DML Execution Elapsed Time : [0.23] seconds

Однако гибридный режим работы в релизе 11.1.2.3.500 поддерживает не все функции. И после вхождения в гибридный режим в случае использования такой функции essbase может из этого режима выйти и дальнейшие вычисления производить классически. Но в лог уже об этом ничего не пишет.
У нас была одна такая форма, где использовалась shared иерархия с функциями, т.к. считалась численность:


SELECT {{CROSSJOIN({[Period].[DEC],[Period].[YearTotal]},CROSSJOIN({[Level].[LV_Total]},{[Currency].[RC_RUB]}))}} ON COLUMNS,
NONEMPTYBLOCK {CROSSJOIN({Descendants([BudOwnerCONS].[BO_PnL],[BudOwnerCONS].Levels(0))},CROSSJOIN({Descendants([LegalEntity].[LE_PnL],[LegalEntity].Levels(0))},CROSSJOIN({Descendants([CostCenterCONS].[CC_PnL],[CostCenterCONS].Levels(0))},CROSSJOIN({Descendants([Add].[Add_PnL],[Add].Levels(0))},CROSSJOIN({Descendants([Program].[PRG_PnL],[Program].Levels(0))},CROSSJOIN({Descendants([Service].[SE_PnL],[Service].Levels(0))},{Descendants([Reserved].[LO_PnL],[Reserved].Levels(0))}))))))} ON ROWS
FROM H_ALLOC.H_ALLOC
WHERE ([Years].[FY16],[Scenario].[BUD],[Version].[VR_Work],[AccountCONS].[XSTATHEADT],[Channel].[CH_C0],[LegalEntityICP].[ICO_0000],[ReservedALLOC].[R2_ALLOC_NA],[Contractor].[CO_NONE],[Detail].[DET_NA])

Узнали мы об этой особенности работы гибридного режима уже только после перехода на 11.1.2.4 🙂 В этом релизе список функций, поддерживающих гибридный режим, был существенно расширен. Соответственно система переключалась в гибрид и там и оставалась! Запрос продолжал выполняться бесконечно долго (при этом данных он не возвращал – специально сделали такой test case для правильного описания ситуации в Service Request).
После всестороннего анализа получили такую вот интересную рекомендацию от support: выставить значение параметра

__QPDF_SIMU app_name db_name 128

Это скрытый параметр в essbase! В oracle database мы уже все привыкли к скрытым параметрам, но в essbase я такое встречаю впервые 🙂
Технически проблема с запросом была в сочетании факторов: в этом MDX потенциально могло быть до 7,7*10^13 ячеек, а также была простая формула для [Period].[YearTotal] плюс cross-dimensional зависимости с измерением Account. В блоках данных в действительности данных не было и формула вычислялась в пустое множество. Значение параметра специфично для нашего outline (т.е. правильное значение может подсказать только support), описания его я не нашел, но, насколько я могу понять, это лимиты размерности количества ячеек для переключения между разными режимами обработки (гибрид и классический).
Небольшое исследование файлов *.so показало. что такой параметр в essbase не один:

# strings /opt/hyperion/EPMSystem11R1/products/Essbase/EssbaseServer/bin/libesscfgu.so | grep __
__ASOFRMLQRYMEM
__ASOFRMLSUBQRYMEM
__ASOFRMLINDXTHRESHOLD1
__ASOFRMLINDXTHRESHOLD2
__ASOFRMLINDXMEMPCT
__ALLOWSMARTCOMPRESSIONCHOICE
__ASO__DISABLE_CORRECTION
__ASOANONYMOUSEXPORT
__ASOCACHEOVERFLOWPERCENT
__COMPRESSIONSTATSFILE
__DLASOFLUSHASYNC
__HEALTHMONITORCRASHAGENT
__MAINTENANCEWARNING
__NO_CALCPARALLEL__
__NOFULLSECFILEWRITE
__NOLOGOUTATRESTRUCT
__NOWARNINGNEWERAPIVERSION
__QPDF_ARR_LIMIT
__QPDF_REVERT_NAMES_FILE
__QPDF_TRACE
__QPDF_SIMU
__RECORDKERNELQUERIES
__SECFILEFAULTINJECTION
__SERVERTHREADS
__SM__ADAPTIVE_PAGE_SPLIT
__SM__DUAL_FILE_OPEN
__SM__HIGH_DIRTY_BLOCK_THRESH
__SM__LOW_DIRTY_BLOCK_THRESH
__SM__MIN_DAT_FRAG_SIZE
__SM__NO_TRANS_MODE
__SM__PAGE_PRESPLIT
__SM__PRE_INIT_BLOCK_RATIO
__SM__SERIAL_MODE
__SM__SWAP_DAT_PH_BUFFERS
__SM__UKRAINE
__USRLICCHECKOUTATSTART
__BSOKRNL1019019__
__UDAOPT__
__SSL_NETDELAY
__NUMBLOCKSTORESERVE__
__ENABLEXREFOPTIMIZATION__
__DLABORTHIGHEXP
__LARGENUMAPAGE
__DISABLELOGMSGINDEXWRITE__
__NODEADLOCKDETECTTIMEOUT__
__HEALTHMONITORCRASHAGENTTHRESHOLDTIME
__NO_SECFILEWRITE_TILLSHUTDOWN__
__NO_SECFILEWRITEFULL_ON_SHUTDOWN__
__SM__HIGH_DIRTY_PHBLOCK_THRESH
__SM__LOW_DIRTY_PHBLOCK_THRESH

Не уверен, что все их можно менять через essbase.cfg. Но для __QPDF_SIMU есть даже специальный параметр __QPDF_TRACE – вероятно, для отладки. Правда правильно воспользоваться им не получилось.

В-третьих, в тестинге (уже практически перед установкой в production) обнаружили, что при ad-hoc анализе некоторые данные отображаются некорректно: неверно считаются total либо данные показываются не в тех строках. Причем проявляется это весьма странно: запрос не всегда отрабатывает некорректно, а после определенного набора действий. Оказалось, что всему виной этот скрытый параметр и его пришлось исключить. Завели Bug “DYNAMICALLY CALCULATED MEMBERS ARE RETRIEVING DIFFERENT VALUES BETWEEN REFRESH”, а иерархию пришлось переделывать, убрать функции из проблемных мест.

Такая вот история пока что без Happy End.

P.S. Большое спасибо слать Игорю Хатько и Георгию Лихолетову, которые раскопали все это.

Advertisements
Скрытые параметры essbase в 11.1.2.4