Разгоняем БД Essbase
маленькая пошаговая инструкция – без объяснения причин
– цель – уменьшение размера БД на диске ( OTL – BSO Planning)
1) Кварталы и Весь год DCALC
2) Периоды идут первыми
3) Тип сжатия RLE
4) Для принятия настроек – выгрузить базу в текст- очистить MOLAP – остановить куб – загрузить данные.
Если Вы последовали данной рекомендации – напишите в коментах насколько у вас уменьшилась БД 
Комментарии (5) »
Оставить комментарий
О проекте
Целью данного блога является популяризация и раскрытия секретов работы OLAP сервера EssBase .Так как, зачастую, люди впервые сталкивающиеся с данной технологией склонны списывать свои неудачи и ошибки проектирования на софт – хотя Hyperion просто нужно уметь готовить )) .
Здесь будут публиковаться, как заметки из личного опыта, цитаты, так и отредактированные материалы (презентации, переводная документация и т.д. и т.п.).
Вы можете обращаться ко мне по след. вопросам – я всегда готов помочь советом :
- настройка производительности (performance) essbase кубов и приложений Hyperion Planning
- Разработка технической архитектуры (сайзинг) для приложений Oracle-Hyperion Essbase, Bi Plus, Planning
- Разделение приложения Planning на множество и их интеграция
- Разделение направлений, перенос данных (исправление ошибок проектирования)
- Разработка внешних функций (UDF/CDF) для сложных расчетов в Calc Script’ах
- Разработка отчетных кубов
- Обучение и разработка Бизнес правил на языке Calc Script
- Обучение Hyperion Financial Managment
- Обучение созданию OLAP кубов из реляционных таблиц
- Любые другие ИТ консультации по использованию продуктов Hyperion EssBase & Planning
- UpGrade с ранних версий Hyperion Planning (3.x,4.x) до System 9
- Миграция с многовалютного приложения на одновалютное и обратно
- Перенос репозитория метаданных Hyperion Planning c Oracle на Microsoft SQL и обратно
- Подготовка к сдаче сертификационных экзаменов Oracle Hyperion Essbase Developer и Planning Consultant
обращайтесь:
essbase.ru@gmail.com
skype: essbase.ru
cel: +7 916 164 3525
Авторы
-
Архивы
- Ноябрь 2009 (1)
- Сентябрь 2009 (2)
- Август 2009 (3)
- Июль 2009 (10)
- Июнь 2009 (7)
- Май 2009 (8)
- Апрель 2009 (10)
- Март 2009 (8)
- Февраль 2009 (31)
- Январь 2009 (20)
- Декабрь 2008 (5)
- Сентябрь 2008 (3)
-
Рубрики
-
RSS
RSS записей
RSS комментариев
3) Тип сжатия RLE – может ли это негативно повлиять на производительность системы?
Комментарий от Михаил | Май 12, 2009 |
Утверждать что нет , я не буду так как в отличие от BitMap – RLE действительно сжимает – соответсвенно для Essbase появляется дополнительная задача по сжатию.
Поэтому все изменения нужно замерять, что было до и что после.
IMHO RLE, хорошее решение для «разряженных» блоков, т.е. свобоных на 70%.
К несчастью более качественных метрик я Вам дать не могу – поэтому пробуйте.
Комментарий от essbase.ru | Май 12, 2009 |
1) Кварталы и Весь год DCALC
это означает большое неудобство для пользователей!
Комментарий от jill | Сентябрь 18, 2009 |
неудобство в чем ?
если что то вводится на год то – bb
недостаток в том что нельзя вводить квартальные цифры
но преимущество
– блок меньше на 5 порядков
– не надо рассчитывать период в скрипте
– если что-то нужно вводить на квартал – можно это делать на месяцах, а потом либо аллоцировать по flow счетам , либо сразу вводить остатки
Комментарий от Анонимно | Сентябрь 18, 2009 |
Маленькие замечание
1) при смене типа сжатия , что бы изменения применились, нужно очистить куб от данных и загрузить их снова из предварительного выгруженного текстового файла.
2) RLE vs BitMap – это неоднозначно и производительность очень сильно зависит от типа приложения и от аппаратной среды
3) все эти рекомендации очень сильно влияют на корректность расчетов, так что прежде чем применять их на продакшн – тестируйтесь
Комментарий от Анонимно | Октябрь 2, 2009 |