Привет. Столкнулся тут с такой проблемой.

В куб нужно закачать 530 миллионов записей из ODS. С понедельника по вторник прокачалось 130 миллионов записей. Первое предположение состояло в том, что на это дело потребуется неделя.

Ага, сейчас. Уже конец воскресенья, а записей дошло в куб только 260 миллионов.

Судя по всему, перед тем как добавить запись, он должен проверить, нет ли там такой другой такой же. На это у него уходит время, пропорциональное количеству записей, которые уже добавил. Нет, индексы пока там не работают. Выходит, временная оценка O(n^2), от количества записей. То есть, для загрузки в два раза большего числа записей нужно в четыре раза большее время.

Скажите, а как вообще можно прогрузить тогда большое количество данных?

1) Индексов точно нет?
2) Во сколько потоков идет загрузка?
3) Сколько записей в пакете?
4) Некумулятивные показатели?
5) Большие измерения?
6) Мониторинг запросов к БД?
У меня загружалось 60 млн. записей из PSA в куб за 30 минут.
В пакете по 100000 записей.
При использовании значения по умолчанию (5000 записей) грузилось очень долго, есть подозрение что у SAP неэффективно реализована административная часть (запись сообщений в монитор, обработка пакетов).

Индексов "точно нет", и больше того. Если индексы есть, то объёмы больше какого-то у нас вообще не проходят, слетая с абап дампом.

Сколько потоков? В SM50 крутились три бэкграунд процесса. Кстати, а где настраивается количество потоков?

Записей в пакете 50 тысяч.

Показатели все кумулятивные.

Измерения - как минимум, одно измерение порядка 500 тысяч, и его не сделаешь меньше (0MATERIAL, товар).

...

Есть еще один вопрос. Куб перегружается долго, но "и чорт бы с этим". Но есть одна штука очень печальная, куб загружается из ODS, из которого должны грузится другие данные, парралельно. А при работающей загрузке данные нельзя активировать. Выходит, всё стоит...

Поищите артикл =
Performance Tuning Massive SAP BW Systems - Tips & Tricks BY Jay Narayanan

https://forums.sdn.sap.com/thread.jspa?threadID=534837

А 0MATERIAL - line item dimension или он генерит для каждого 0material новый ключ измерения?
И 3 потока, как мне кажется очень мало для таких объемов данных. Я бы начал с увеличения количества параллельных процессов (это можно сделать на лету - DTP, настройки менеджера партий) и размера пакета.
Оценить возможности железа (кол-во процессоров, память), - сколько параллельных процессов могут грузить данные в куб, не конкурируя за оперативную память.
Кстати, какая используется СУБД?

Это край как мало! Если на железке стоит десяток физических процов, то логично забить их все, собственно для загрузки рекомендую в настройках системы увеличить число фоновых процессов до максимума (базис должен уметь это делать, есть ноты) и в настройках ППД поставить число параллельных обработок = число фоновых - 2. (ППД -> Перейти к -> Настройка менеджера партий...), размер пакета установить побольше (500 000). Кроме того, подумайте про изменение механизм загрузки в куб - сделать через буферный DSO с оптимизацией записи, т.е. такая связка: Исходный DSO с журналами -> DSO с оптимизацией -> Куб, дельту при этом можно сделать на фильтрах в ППД, а буферный DSO вычищать...

С системе парралельно работают люди, так что выделять все ресурсы только под эту задачу - нельзя. Там всего шесть фоновых процессов, из низ занимать все шесть означает вообще остановить работу с BW, никакие данные не прогрузятся.

Есть куб. Сейчас выяснилось, что в куб нужно добавить еще один признак, и заполнить его. В кубе примерно 500 миллионов записей.

Для этого создаётся дублирующий куб. Все записи грузятся в него. После этого в мультипровайдерах просто подменяется старый куб на новый. Всё, ура.

Трудность не в том, что загрузка идёт медленно. А в том, что она идёт медленнее и медленнее с каждой записью, за первый день прошли 130 000 000 где-то, для взятия вторых 130 000 000 потребовалось еще пять дней. На лицо зависимость, близка к квадратичной.

Итого. Вопросы, собственно, такие. Можно ли перегрузить из dtp не все данные, а кусками? Как правильно настроить, чтобы шла дельта?

В DTP можно сделать динамический фильтр - подпрограмма с вашей логикой.

А как потом настроить, чтобы дельта пошла хорошая? То есть, поясню.

Есть dtp ZDTPA. В нёго грузятся данные, по 250 тысяч записей за сутки. Уже там 500 млн записей.
Есть куб ZCUBB. В него из dtp грузятся данные.
Есть куб ZCUBC, в него нужно перегрузить данные, но так, чтобы уже после этого они шли дельта-загрузкой.

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