Итак, спустя некоторое время пишу отчет о результатах изменений, описанных в предыдущем посте.
Примененные параметры из предложенных документов по тюнингу приложений для сервисов продуктов EPM под Windows привели к нестабильной работе компонентов системы, после чего я принял решение «побаловаться» на тестовом сервере. Я следовал этому - одному из базовых правил разработчика)
На тестовом сервере я развернул релиз 11.1.1.3 на BEA WebLogic 9.2 MP3. При этом я все-таки применял рекомендованные в предложенных консультантами Oracle документах по тюнингу. Забегая вперед, скажу, что релиз работал стабильно (тьфу-тьфу) и достаточно быстро, даже несмотря на то, что тестовый сервер по своим характеристикам значительно слабее.
Характеристики Промышленного сервера:
Аппаратная часть: Процессор Intel Xeon X5450 (3.0GHz) (8 CPUs), Оперативная память 16GB. ПО: Операционная система Win2003R2, EPM система Hyperion 9.3.1 (с обновл.), Реляционная СУБД на внешнем сервере.
Характеристики Тестового сервера:
Аппаратная часть: Процессор Intel Xeon X5550 (2.67GHz) (2 CPUs), Оперативная память 4,5GB. ПО: Операционная система Win2003R2, EPM система Oracle Hyperion 11.1.1.3, Реляционная СУБД на внешнем сервере, BEA WebLogic 9.2 MP3.
Переходя ближе моей цели — оптимизации скорости работы расчетов в существующем приложении Planning версии EPMA, опишу те процедуры, которые я провел для получения результата:
1. Портировать приложение в EPM 11.1.1.3 с версии 9.3.1. Отмечу, что мне необходимо было использовать Business Rules, а не CalcManager. Поэтому нужно было одновременно перенести приложение в Classic версию. Для этого нужно создать пустое Classic приложение в Planning. Затем остановить сервисы Planning (9.3.1 и 11.1.1.3) и стандартными инструментами СУБД (у меня это Oracle) скопировать, сохранив сиквенсы(!), всю БД приложения из 9.3.1 в 11.1.1.3. Затем запустить сервис, войти в Planning под тем пользователем, под которым создавали пустое приложение. При это Planning сам предложит вам мигрировать приложение в версию 11.1.1.3. Затем заходим через административное меню в свойств приложения (Manage Properties) и устанавливаем разрешение на изменение измерений (EDIT_DIM_ENABLED = true). После этого выходим и перезагружаем сервис Planning. На вопрос о том, что если нужна EPMA версия, могу ответить, что мигрировать Classic версию в EPMA версию можно стандартными средствами Planning.
2. Портировать Business Rules через EAS из 9.3.1 в 11.1.1.3. Большое НО: Вы не сможете выбрать Outline для Planning приложения. Это бага известная, но не исправленная. Для этого нужно в CSS создать пользователя с правами на работу в EAS и Essbase и доступ к приложению Planning. После этого возможно войти в EAS и работать обычным образом.
3. Оптимальнее настроить Dense/Sparse измерения в приложении и их порядок, используя рекомендации, хорошо собранные в единую презентацию Федором Зевако. При этом желательно отказаться от мультивалютных измерений (валюта и курс) в тех кубах, где не нужны несколько валют.
4. Для функций передачи данных между кубами (у меня это XREF с использованием атрибутов для здоровенного - порядка 10000 элементов в измерении) в тех случаях, когда атрибут должен динамически собирать значение арифметической операции (например, суммы), стоит использовать альтернативные иерархии с хранимыми узловыми элементами. Перед использованием правил, в которых работают функции передачи данных между кубами стоит проагрегировать значения в нужных аналитиках. В купе, эти два правила отработают быстрее, чем то, которое будет для каждого показателя каждый раз динамически собирать по атрибутам.
Ниже я приведу основные временные характеристики, которые показывают эффективность проведенных мер. Данные приведены для одного (самого долгого по времени и важного по значению!) расчета показателей главного отчета с тем, чтобы полученные результаты были сравнимы.
Правило «как есть» на промышленном сервере было посчитано за 27 ч 13 мин 10 сек.
Оптимизированное правило с изменением модели на тестовом сервере — за 8 ч 09 мин 38 сек.
Хочу отметить, что были произведены только самые эффективные доработки правил, модели и настройки самой платформы Hyperion. В ходе работы были замечены еще некоторые недостатки в настройке правил, которые можно исправить позднее и получить дополнительный положительный эффект. Потому что Essbase – это искусство))) Да и Planning тоже!
