Приветствую!
Интересует такой вопрос: есть ли выгода в производительности при партицировании куба по дням?
p/s/ Куб планируется объемный - около 1,5млн записей в день.

Мне кажется партицирование нужно для быстрого доступа к данным. Если читать потом по месячно, то смысла делать партицирование по дням думаю нет

Просьба ответить тем, кто реально использовал партицирование по дням, получился ли выигрыш в производительности на практике?
Помогает ли такое партицирование при выборочном удалении или наоборот - замедляет его?
p.s.: теорию я знаю, не надо в этой теме строить предположения, интересуют только факты.

Ну чтож Вы, так бы сразу и написали,- "в этой теме предположения не строить"

а когда стало можно партицировать физически по дням?

Ну это если на каждый день куб создавать....

Так то да год/месяц + насколько я помню не больше 12 партиций

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

это логическое партицирование, про которое и так понятно что оно возможно, только смысла по дням не вижу никакого

А вообще выгода от партицирования ? Если можно создавать не более 12 партиций + общее ??? Это значит должно быть не меньше одного куба на год, так как я понимаю передвинуть партиции на актуальный период (допустим сдвинуть на квартал ) возможности нет ?

Откуда такая информация?

Ну вообще давно консультанты сказали...
Они были не правы ?

se14, они были не правы

можно спросить, а вы в какой версии BW хотите партицирование делать?

в семерке и во всем более раннем можно партицировать только по 0CALMONTH и по 0FISCPER.
никаких дней там нет... увы.

se14 и ручные партиции хоть по числу записей или на уровне оракла.

Идея с партиционированиеминтересная в плане производительности. Возникает проблема объединения данных в одну партицию за более старые периоды и постоянное пересоздание новых партиций для будущих дат. Если решить эти технологические трудности, то однозачно будет ускорение записи/чтения.
Но если что-то упустить и не предусмотреть, то при вставке записи по которой не создан период будет отказ БД.
Такое разделение работает только как дополнительный физический индекс.
Сейчас на серверах стоят преимущественно RAID устройства, поэтому 2 логических диска могут физически находиться на одном блине.
Хотя можно и исхитриться, поставив для хранения текущих отчетных дней более быстрые и дорогие диски с большим кешем, на отдельный канал ввода-вывода, а по мере устаревания - переносить информацию на общее RAID пространство.
Но эти проблемы на стыке хранилища и базиса.