коллеги предлагаю обсудить настройки BD Oracle для HFM
- надеюсь что в итоге обсуждения мы сможем прийти к тем настройкам которые "разгонят" HFM на Oracle

aq_tm_processes 1
audit_sys_operations FALSE
audit_trail NONE
cluster_database FALSE
compatible 10.2.0.3.0
cursor_sharing EXACT
db_block_size 8192 == размеру блока на starage лучшим значением будет 16384
db_domain
db_file_multiblock_read_count 32
db_writer_processes 4
dml_locks 500
fast_start_mttr_target 300
-- hash_area_size 67108864
job_queue_processes 10
-- log_buffer 134217728
nls_language AMERICAN
nls_length_semantics CHAR
nls_territory AMERICA
open_cursors 300
parallel_adaptive_multi_user TRUE
parallel_execution_message_size 17184

parallel_max_servers CPU*4

-- pga_aggregate_target 808MB

processes 1000
remote_login_passwordfile EXCLUSIVE
sessions 1500

-- sga_target 1536MB

skip_unusable_indexes TRUE

-- sort_area_size 134217728

sql_version NATIVE
star_transformation_enabled TRUE
timed_statistics FALSE
trace_enabled FALSE
undo_management AUTO
workarea_size_policy AUTO

за основу этих настроек взялись предположения
1) что база данных будет экслюзивно работать для целей HFM (dwh)
2) что будет отключен режим ARCHIVE LOG
3) что система будет поддерживать не более 5 приложений HFM до 100 пользователей
4) что все таблицы и табличные пространства будут созданы с опцией NOLOGING
5) что таблицы с аудитом будут вынесены в отдельное табличное пространство, а лучше на другой сторадж

з.ы. естественно UTF8

Сообщение отредактировал essbase.ru - 22.4.2009, 9:32

Мне кажется, что безотносительно железячной конфигурации, и не имея возможности потрогать тормозные места - обсуждать эти настройки абсурдно.\

И вообще непонятно, например, зачем надо было лезть в настройки AQ при том что

Почему вдруг размер блока лучше 16384?

абсурдно обсуждать тюнинг памяти - с этим я согласен
все остальное очень даже интересно ) )


чем больше размер блока тем за меньшее IO будет считана порция информации с диска

спасибо за AQ_TM_PROCESSES
- я этого не знал

кстати, с какой версии AQ_TM_PROCESSES стал автонастраивыемым ?

Да, извиняюсь, не заметил. что там десятка. Это в 11 он стал таким.

Кстати, если уж избавляемся от хлама, то его можно выключить нафг, если не используются фичи, на AQ завязанные.

Oracle подтвердил что в данных настройках криминала нет
я себе уже поставил - будут изменения запощу здесь.

А что говорят Hyperion'овские тюнинг гайды по HFM? Или у тебя их не сохранилось?

Противоречивые цели. Во время внедрения HFM в ВБД (1-го внедрения ) консолидация HFM парализовывала работу не только хранилища, но даже Planning'овских приложений. Реально дальшей логона всё зависало.

Поэтому, первая рекомендация по тюнингу - разнести dwh и HFM по разным экземплярам.

- все верно - не нужно держать все яйца в одной корзине если руки кривые - спроси у Гоши какая сейчас архитектура в BБД.

- hfm - имеет ER модель реляционного хранилища = поэтому эти рекомендации IMHO должны быть хороши как и для HFM так и для DWH

Ну да, HFM хранит данные в звездообразном виде. Но на этом сходство заканчивается. В конце концов, запорожец тоже имеет модель машины, как и танк... Вот вот, реализуемые бизнес-процессы и способы обработки данных разные

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

В правильности рук, которые делают нынешнее приложение я далеко не уверен. И я не понял, зачем мне спрашивать про архитектуру у Гоши?

каждый имеет право на свое IMHO

Глубокомысленно У тебя противоположное моему IMHO и ты считаешь внедренцев однозначно компетентными? Ну-ну... IMHO опасная точка зрения

Коллеги. не ругайтесь!!
Давайте не переходить на личности

А кто ругается?

Просто я решил немного поглумиться над выбранным подходом к тюнингу HFM.

Женя за деревьями (настройка тонких параметров СУБД) не хочет видеть леса (общего подхода к выбору архитектуры). Нужно понимать собственную архитектуру HFM - ни один пользовательский процесс (запрос пользователя на просмотр или ввод данных или выполнение скрипта) напрямую ни когда не пишет в базу и не читает из нее. Пользовательские процессы обращаются к виртуальному OLAP-кубу (который реализуется в памяти сервером HFM), который в свою очередь переадресует запросы к транспортному слою, который уже обращается к базе. Транспортный слой постоянно держит открытыми н-ное количествоо соединений с базой, через которые читает и обновляет данные.

Опять же нужно понимать, что:
а) чтение и запись происходит хаотично с точки зрения реляционной структуры данных (поэтому, бесполезно специально тюнить размер блока)
б) наибольшую нагрузку составляют запросы на хаотичное обновление данных; это дает хорошую нагрузку на диск - тут я с автором согласен, что нужен отдельный шустрый сторадж, но только не для таблиц аудита, они тупо монотонно увеличиваются и данные в них практически не меняются, а для таблиц с данными (и всё-таки, какая нафиг аналогия с хранилищем?)

Поэтому, так как HFM работает с базой довольно хаотично, то очень сложно сопоставить параметры приложения и реальные требования к тонким настройкам СУБД. При этом обычно (в соответствии с моим знанием истории внедрений HFM и собственным скромным опытом) достаточно бывает поставить нормальную железку (см. рекомендации вендора по сайзингу), выделять под HFM отдельный экземпляр, дать максимальное количество памяти экземпляру и задать разрешение на большое количество процессов (я всячески одобряю настройку в 1000 процессов у автора). И всё. Всё остальное можно оставить по-умолчанию. Ни какие другие настройки (если не впадать в крайности) не дадут ощутимого результата.

Если действительно есть желание выжать из HFM максимум, то смотреть стоит не на базу данных, а на кластеризацию серверов HFM, т.к. наибольшую нагрузку несут именно они. Слышал, но не пробовал сам, что хороший эффект дает разнесение различных процессов по серверам - на одном выполняется консолидация, а на другом пользователи строят отчеты. Кроме того, с 11-й версии HFM стал 64-битным. Я его уже попробовал, правда адекватно не оценил - масштаб приложения не тот был. Так что, пространство для оптимизации HFM есть, даже без пристального вглядывания в настройки базы данных

Сообщение отредактировал romKa - 28.4.2009, 0:08

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


Сообщение отредактировал essbase.ru - 30.4.2009, 13:47

Роман, как всегда Oracle за нас подумал и все уже сказал

пользуйтесь и наслаждайтесь
http://download.oracle.com/docs/cd/E12825_...111/fdm_dba.pdf

Под HA (типа Hybrid Analysis, как в Essbase) ты имел ввиду EA (Extended Analytics)? Если да, то я не знаю, можно ли экспорт в схему EA делать через любой сервер после однократной настройки для кластера или EA имеет смысл только для конкретных серверов.
А вот расчет и ввод данных точно хорошо кластеризуются. При выполнении этих операций данные (вроде бы сабкубы - данные на срезе по Сценарию, Году, Entity и Value, а-ля блок в Essbase) блокируются, но сами процессы могут выполняться одновременно, если они работают с различными данными. Например, можно одновременно выполнять консолидацию для различных Entity.


Это же тюнинг-гайд для FDM, а не для HFM. А FDM, кстати, вполне походит на хранилище - грузит данные пакетно, запросы выполняет к звездообразной структуре таблиц

в целом он соответсвует HFM

различия
HFM FDM

timed_statistics FALSE TRUE
star_transformation_enabled TRUE FALSE
aq_tm_processes 1 1
parallel_max_servers 4xCPU 20xCPU

как Вы видите принципиальные, и опция parallel_max_servers 20xCPU явно не подходит для DWH (ETL)

по остальным пунктам 100% совпадения.

так что с учетом замечений - можно использовать