В правилах обновления в случае расчета показателя ABAP-программой и выбранной опции возврата таблицы значений, существуют ли ограничения на объем этой самой таблицы.
Например, по логики задачи одна запись из коммуникационной структуры должна быть 1000-10000 кратно продублирована (с генерацией уникальных признаков). То есть на входе одна запись, а в цель данных идет >> 1. Если учесть, что в пакете 50000-100000 записей, то на выходе будет... очень много. Есть ли где описания (в нотах или еще где) на этот случай. На вскидку поискал в разных источниках, но чего-то нигде не наткнулся. И как дополнение, если в стартовой программе добавляются записи в пакет данных, какие там есть ограничения. Но все-таки больше волнует первый вопрос.

Ну давайте по - расуждаем.

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

Поэтому ограничение тут только одно - хватит ли вам памяти при обработке пакета в 100 000 записей, при условии что идет размножение одной записи на 10 000 ? Думаю что сервер выплюнет ваш процесс...

Допустим вы увеличили память до немерянных размеров и она неограничена Тогда возниакет вопрос такого плана - а сможет ли сервер баз данных переварить одномоментную вставку 1 000 000 000 записей? Думаю что нет. Потому как вставить сразу миллиард записей - никаких мощностей не хватит. Свавлиться либо по таймауту или по нехватке tablespace или по переполнению метса для логов.

Допустим вышеописанные проблемы вы решили. А теперь прикиньте, сколько времени будет вставляться этот объем данных...

Резюме - может лучше не надо таких насилий над системой?

Все конечно так, но а если уменьшить количество строк в пакете.

То есть размер пакета... ну скажем 1000 записей на пакет. Таким образом 1000 * 10000 (10000 - это потолок, если брать средние, то все будет скромнее - ну где-то 2000-3000), то получим 1000 * 3000 = 3 000 000. Если и это много, то еще можно урезать размер пакета.
То есть если изначально данные передаются в количестве 100 000, то
будет сформировано 100 паетов по 1000 записей в каждом. Каждый пакет в итоге будет вставлять по 3 000 000 записей. Насколько я понимаю, фиксация транзакции происходит после обработки каждого пакета. В таком случае 100 commit-ов по 3 000 000 на приличном сервере должно работать. Что скажете?

Если разрезать по пакетам, то возможно работать и будет, однако нельзя забывать что сервер БД (если ф-я не отключена) ведет еще и статистику для возможного отката, + пользователи, которые могут работать в это время, плюс другие загрузки, которые не могут ждать.
Одним словом очень ненадежный механизм получается.
Сюда еще нужно добавить время на перегенерацию индексов после загрузки, чистку psa, прогон изменений инфообъектов...
ИМХО нужно пересмативать бизнес-сценарий, что-то у вас уж больно все громоздко получается...

PSA практически не используется



Если речь о CHANGE LOG-ах и переходе их при переполнени в ARCHIVE LOG-и, то это вопрос админов. Данных-то много в любом случае.

Вообще-то весь этот огород возник по следующей причине. С R3 поступают новые данные документов, не корректирующие дельты, а именно новые. Теперь представим ситуацию - в куб загружены данные. Надо эти старые данные обновить. Для этого предполагаю выполнить сторнирование - считать данные из куба и записать их снова в этот же куб. Один документ содержит максимум до 10000 записей. Я предполагал через правила обновления поставлять идентификаторы документов, которые должны быть сторнированы, читать для каждого документа данные из куба, генерировать сторнирующие записи (возвращая таблицу) и сохранять все это снова в куб. После сторнирования заливать новые данные документов.
Может есть способ сторнирования стандартный, но я просмотрев документацию такового не нашел.

Может что-то не понял, но разве через ODS такое н е сделать?

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

ну наверное не все данные а только часть ) все - это радикально )

в общем вам наверное надо либо перепроектировать поток и пускать данные через ODS - он автоматом решит ваши проблемы либо орагнизовывать псевдодельту - загружаем данные в три пакета :

за текущей месяц
за предыдущий месяц
за текущий месяц - 2

с удалением перекрывающихся запросов. то есть у вас постоянно будет обновлятья данные за 3 последних месяца. Если данные могут быть исправлены за 6 месяецев назад - значит ваш период псевды - 6 месяцев

2 BW-ник

Не годится. Пользователь может исправить документ за период 3-х летней давности, и он должен попасть в BW.

2 BKMZ и BW-ник

Предположим пользователи поправили 1000 документов за разные периоды, например с 01.01.2000 по 2006. Мне надо загрузить только измененные документы в BW.

Делать сторнирование через ODS... мне не очень это нравится. Насколько я понимаю ODS содержит данные всех документов, которые должны быть в кубе, плюс повторяет структуру куба (ключевые поля). Записи документов, подлежащих удалению из ODS помечаются и ODS обновляется сам в себя, а дельты идут в куб. Все бы хорошо, но есть два не очень приятных "НО"

- в ODS здорово пухнет журнал обновления
- если ключевых полей >> 16 приходится их склеивать (можно конечно, но не очень)

Журнал обновления чистить страшнова-то. У меня как-то потом все валиться начинается при загрузке.

Чтобы потом выборочно удалить данные из куба придется выборочно удалять данные и из ODS, иначе при следующей загрузке и сторнировании данные в кубе поплывут (но это нюансы).

ОСНОВНОЙ МИНУС - избыточность хранения (данные в ODS практически повторяют данные в кубе, да еще и журналы, блин). Вот поэтому и колдую, а объемы данных не маленькие прямо скажем.

Упоминалось число 1 000 000 000 записей (макс).
А куб не лопнет от такого количества данных???
Если одна запись размером хотя бы в 100 байт, то это ж 100 гиг в одночасье толкаются в куб!!! Такие объемы Вас не пугают?
Если нет, расскажите базисникам - пусть им на выходных спистся плохо

Упоминалось 100 commit-ов по 3 000 000 = 300 000 000 Причем пиковая нагрузка, так сказать худший вариант

Хрен редьки не слаще.

У нас 40 млн записей каждую ночь перевставлялось, занимало около 8 часов.

Решили не издеваться над системой.

добрый день.
скажите пожалуйста, как реализовать дублирование строк экстрактора со вставкой уникальных показателей?

вставляю строку 100 (COST) и 150 (NETVAL_INV)

и в кубе хочу получить 2 строки:
1 row - 0001 (ZSTAT) 100 (ZSUM)
2 row - 0002 (ZSTAT) 150 (ZSUM)

спасибо.

Если экстрактор самописный(или на фм), то тут проблем быть не должно. Пробегаетесь loop'ом по табличке, которая идет в e_t_data и дублируете данные как вам нужно...

Если не самописный, то может можно сначала залить все это дело в одс, а потом сделать экстрактор, которые будет читать из ОДС и дублировать строки?

в пакетах можно добавлять новые колонки?