После изменения параметра DELTALIMIT = 20 ченджран ускоряется, а роллап наоборот выполняется намного медленнее. Пробовал различные значения DELTALIMIT. С чем это может быть связано и как исправить?

Change-Run может приводить к превышению объема изменений выше дельталимита, в этом случае агрегат полностью пересобирается -> долго. Если Change-Run не дает превышения лимита, то пересбора нет. Соответственно если изменение атрибутов небольшое, то delta limit = 20, 30, 50 и 70 должны давать одинаковый результат.

При роллапе АФАИК дополнение происходит в обе части (основную и доп) и перестроение обоих индексов. Возможно из-за большой допчасти и просходит увеличение времени.

Категорически не согласен. Хотя бы по двум причинам.
1. По умолчанию дельталимит = 0, это означает полный пересбор(в мониторенге при ченджране это прекрасно видно).
И САП рекомендует изменять его начиная с 20.
2. При перестройке агрегатов, а точнее перезаливке F/E табличек + перестройка индексов при нулевом лимите агрегат тем более должен перестраиваться по полной программе.
ЗЫ В РСАДМИНЕ установлен параметр невэ-эвер-дроп индексы, так что у агрегатов они не удаляются - иначе и за 2-е суток не перестроит(роллап будет нереально долгим).

И где противоречие? Я примерно о том же говорю.

Что то масло маслянное получается.
При перестройке делается полный дроп (или транк, гуру поправят) (думаю и индексов тоже) и потом заливается одна табличка. И соответственно собирается один набор индексов. Ни адаптация, а именно сбор. Линейный.

Думаю при дропе все-таки индексы проще тоже дропнуть. Так что невэ-эвер-дроп-индекс все-таки касается исключительно догрузки данных.

Это сколько ж данных надо иметь в агрегате(!), чтобы сбор индексов занял двое суток?:shock: И как же тогда вообще такая система может работать

PS: может я и не прав насчет причины в вашем случае, но логика есть.

Коллеги, не забудьте, что bw не только на оракле работает а в других СУБД все может быть и не так и вполне возможно вы имеете ввиду разные платформы

Сорри!
BW3.5 о которой идет речь, работает на Oracle 9.2.0.7 + вчерась прикрутил OPatch, теперь база настроена нормально, но именно на столько на сколько это позволяют ресурсы железяки и поганое 32-х разрядное Виндоуззз.
База большая, практически террабайт.
Базу переделал сам, после того, как ее удачно так, почти угробили супер-бупер-"специалисты" из Западной консалтинговой фирмы, которая активно обсуждается в соседней ветке.
Видимо людей туда явно набирают "не по объявлению". Мой АНреспек им, но не всем конечно, а только тем "кто так строит"... (это к слову). Путь теперь уродуют базы в другом месте...

Вопрос на "засыпку". А потянет MS SQL или MAX DB террабайт?
Пожалуй кроме Oracle и возможно DB/2(но она дорогая и спецов по ней мало) - остальное баловство, точнее породии на СУБД. Знаем, проходили...
Хотя если будет работать - пожалуйста, никто ж не против! Как говориться, клавиатуру в руки и барабан на шею...

Теперь по поводу RollUp-а. Я не BW консультант, пока...
Механизм влияния дельталимита на RollUp мне до конца не понятен, поэтому спорить не буду, т.к. это было бы не корректно с моей стороны. Руководствовался нотой 903886.

Вопрос. Можно ли как то посмотреть нотку или доку по данному вопросу? Где подробно описан механизм влияния дельталимита именно на RollUp.
Не сбор индексов, а RollUp, точнее компрессия. Система будет работать, т.к. F-таблички заполнены, а вот компрессия (E-таблички) может занять достаточно много времени. На самом, деле сейчас практически выяснил, что если индексы агрегатов в нормальном состоянии, то RollUp проходит достаточно быстро. Но для этого пришлось прогнать SAP_INFOCUBE_INDEXES_REPAIR, хотя в RSA1->куб->"администрироване" руками регулярно проверял(ю) состояние индексов самых больших кубов и индексов их агрегатов.