Oracle Essbase: И снова о производительности

 

Недавно в блоге PAE опубликовали пост , о том как важно вводить ограничения на ресурс в работе EssBase. Хочу поддержать и развить эту тему

Преамбула :

Есть несколько соображений, которые находятся на уровне системного администрирования, и которые нашли отображения в культовом ( прорывном, революционным и пр. и пр. и пр. ) HTTP сервере nginx это:

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

     

Что это означает с практической точки зрения для мира Hyperion:

Согласно 12 принципам Кодда (спасибо Кудрявцеву Юрию за академический OLAP обзор ) , приложение на Oracle Essbase должно быть быстрым , гибким и масштабируемым (есть анекдот, в котором говорят , что авторы Essbase спонсировали Кодда, который писал свои принципы, опираясь на функционал Essbase). Критерии скорости во многом зависят от инструмента, но не последнюю скрипку играет правильность его использования. И здесь хочется сказать огромное человеческое спасибо за то, что в EssBаse заложен функционал по контролю за действиями разработчика: это параметры EssBase.cfg :

;Sets the maximum amount of time a query can use to retrieve and deliver information before the query is terminated.
QRYGOVEXECTIME 30

;When set to true, prevents the server from going beyond 31 formula execution levels.
CALCLIMITFORMULARECURSION TRUE

Essbase Block Size new feature

Конечно, все Вы знаете о рекомендациях по размеру блока – не более 150K. И я тоже свято в это верю. Но эксперементы на промышленном окружении показали, скрипт отрабатывает одинаково, как при блоке 40К  так и при размере блока 2000К.

Лучший результат по времени расчета (40%)  был при размере блока -> 500К. и типе сжатия Bitmap.
платформа SPARC – версия essbase 11.1.1.3

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

Essbase Restructure

Oracle Essbase Фрагметация файла данных при конкурентных расчетах

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

В процессе расчета, Essbase, резервирует исходное место для записи измененных блоков, если это возможно иначе блоки записываются в другую свободную область или в конец файла. В данном случае Essbase хранит копии измененных блоков, в целях восстановляемости после сбоев. Блоки удаляются из файла данных только в конце расчета, и место занятое ими помечается как «свободное». Все это приводит к «фрагментации» файла данных, т.е. к такому состоянию – когда блоки больше не лежат отсортировано согласно записям индексного файла. В так «разобранном» состоянии происходит рост времени расчета БД.

Процесс фрагментации можно контролировать показателем «Average Clustering Ratio», который должен стремится к 1, в случае существенного его изменения (ниже 0,74 ) нужно запускать  процесс «дефрагментации» – либо Restructure, либо Export/Reset DB/Import/.

Более подробно о фрагментации можно прочитать в официальной документации и вот здесь