Коллеги.
Необходимо делать достаточно большой расчет в ФМ экстракции. То, что на тестировании работало хорошо, на продуктиве стало валиться в дамп из-за нехватки памяти из-за большого объема "боевых" данных.
Сделал код который бьет исходный пул данных на относительно небольшие части. Соответственно меняю инфопакет (BAPI_IPAK_CHANGE) и пытаюсь его запустить через BAPI_IPAK_START. Анализирую таблицу возврата с ошибками. Если есть ошибки - попытка повторного запуска с теми же параметрами.
Проблема в том, что не смотря на такую обработку таблицы возврата функции, получается ситуация, что некоторые инфопакеты стартуют несколько раз с одними и теми же параметрами. Возвращаемые ошибки при запуске: "Инфо-пакет Zххх запланирован или уже выполняется; дальнейш. запуск невозм." и "Задание BI_ххх (еще) не запущено". Если же повторный запуск не проводить, то большинство пакетов не стартует и данные загружаются не все.
Как по-другому запускать инфопакет и обрабатывать возврат? Может пытаться запустить всё, а потом мониторить, что по факту запустилось? Число запускаемых процессов гораздо больше, чем диалоговых процессов на сервере приложений.

В общем убрал распараллеливание. Запускаю инфопакет и жду пока статус станет не-желтым (модуль BAPI_ISREQUEST_GETSTATUS). Итого экстракция занимает всего один фоновый процесс и ведет на системе себя очень корректно.
Подглядел здесь http://www.sapnet.ru/viewtopic.php?t=1952

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

Прикинул по последней проблеме. Начальная загрузка - до сотни пакетов. В один поток работают нормально, но, в общем получается ну очень медленно.
Сейчас в голове идея сделать константу на системе - число фоновых процессов, которые допустимо занимать и запускать именно столько. И мониторить последовательно их статусы, заменяя в списке позеленевший пакет новым.
Возможно проблемы бы не было, если б из исходной системы данные приходили в нужных разрезах. Но здесь достаточно сложный расчет на основании разрозненных данных из исходной системы в попытке получить нормальную картину истории и всё это делается в момент экстракции.
Ладно. Сорри за разглагольствывания

Я чего-то не понял.
Экстрактор как сделан ? Данные разбиваются на пакеты или приходят одним большим "куском" ?

Иными словами в экстракторе есть что-то наподобие

а почему не выполнить этот сложный расчет в исходной системе и не вернуть результат своим экстрактором. Или система неSAP?

Попробуй результаты расчета сохранять в промежуточных таблицах с timestampом и затем грузить в BW. Если грамотно сделать даже дельта получиться.

Исходная система - как раз САП.
В результате анализа исходных требований изменил порядок расчета аналитики, убрав лишние итерации, сделал кеширование перед большими расчетами (чтобы не выбирать аналитику дважды). Итого по скорости разогналось в 20 раз и теперь отрабатывает полностью за ночь. В общем, то, что доктор прописал.
В общем ещё раз убедился, что хотелки клиента, которые транслированы в некое подобие ТЗ надо творчески переосмысливать. Иначе система не сдвинется с места.

2 VitalkaFS варианты с дельтой по времени используются где только можно. Но когда на выходе экстракции бывает пару миллионов записей, то хочется избежать лишней операции обращения БД (записи в таблицу и извлечения данных, удаления результата предыдущего запроса) и сразу отдать данные в BW. Итого получается быстрее, но если всё корректно работает.

Так что проблема закрыта. Спасибо всем, кто принял участие в топике!