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

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

Взяли кубик (32.000.000) сделали копию, партицировали копию, закачали данные, сжали, построили индексы, собрали статистику.
Написали 2 совершенно одинаковых простых запроса... запускали через RSRT, итог мягко говоря был не очень...

При выборе данных
за месяц, 2 сек (непартиц) и 6 (партиц)
за 4 месяца, 7 vs 58
за 9, 17 vs 164

максимум когда партицирование дало эффект, когда был запрос выбирающий каждый 5 день месяца в течении года... - 32 vs 27
Но для моих пользователей, такие запросы исключение, чем правило... 99% выбирают последовально с и до по.

В общем, стало как то грусно, поиск нот (мож, чего где прописать надо) ни к чему не привел...
Интересно было бы услышать какие у Вас были цифры по применению физического партицирования... удачно или неудачно

Доп.данные: BI 7.0 SP 20, ORACLE 10.2.0.2.0
TLK

Вопрос: а эти партиции у вас на одном и том же дисковом накопителе лежат? Попробуйте на разные разнести.

Oracle или SQL?

Советую для проверки отчетов отключить кеширование.

Лучше проверять скорость загрузки данных, как минимум можно на 25% сократить длительность.

для объективной оценки вашего результата надо видеть ваш bex-запрос.
если в rsrt запрос не читает ненужных кубов, а только те, которые попадают в диапазон, то
уже хорошо.

а вот для этого надо либо самому сделать пеерменную - выбор кубов по введенным параметрам, либо использовать ноту 911939

так же помошут оттюнинговать вам работу квери на мультике ноты
895530
607164 ( она правда для 3 была - надо посмотреть для 7-ки рабоатет или нет)

жизнь показывает, что эффективнее нарезки по 0calmonth на физические кубы с накрытием сверху мультом ничего не будет. имеется ввиду объем 10-30 мил.записей/месяц. да, можно пытаться качать это в один куб, но никакое партицирование не поможет, когда надо перегрузить один месяц.

Читал в паре топиков об этом, ходил к базису... но они сказали, что дюже умный у нас массив, и со стороны ОС и БД - это одно большое пространство... в общем не могут помочь
Но за совет, спасибо.

ORACLE 10.2.0.2.0, есть какие мысли?

кеширование - так и делал
Загрузка - эт хорошо... но т.к. загрузка проходит ночью, то интересовала больше отчетность...

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

Наверно, нечетно описал... но для теста партицирования использовался простой куб, и отчет на нем...
никаких мультиков...

Да в общем так и делали... правда резали годами, самые большие кубы... но сейчас пришли к тому что в некоторых мультах до 15 кубов висит... (уникальных 8, остальные лог.партицирование) почитав разные топы - встретил рекомендательные цифры от 5 до 20 кубов в мульте.
Сообственно, из за этого возник вопрос - проверить физическое партицирование...

А какой максимум был у Ваc использования кубов в мульте?

Когда работал на MS SQL тестировал 100 мил. зап. с партициями - не так как на ORACLE скорость росла 10-15% на загрузке, на ORACLE получше.

Думаю если партиции не помогают значит отчет с большим количеством join к разным таблицам, возможно full scan.
Я бы посоветовал Агрегаты(но тогда в отчете при запуске не должно быть детальной информации, тогда все возьмется из агрегатов)

по поводу числа кубов в мульте - у нас сильно больше 15, это точно.
если у вас тех.имена кубов вменяемые, допустим ZCUBE1001... ZCUBE1012, то несложно (кроме того, что предлагает SAP) в запросе вычислять user-exit переменную "ограничения по именам кубов" из ограничения по периоду времени. физическое партицирование это наверное хорошо, средняя температура по палате будет лучше, но не так ощутимо.
вот когда вам надо перезалить месяц или сделать легкий реинжиниринг - вот тут наступает момент истины...