Добрый день!
Проблема в том, что при выполнении мероприятия консолидации (сторнирование документов) вылетает дамп "MEMORY_NO_MORE_PAGING", SAP paging overflow when storing data in the ABAP/4 memory.

Подскажите, плиз, куда смотреть, где что крутить.

P.S. Вообще речь про SEM-BCS, но думаю, что ошибка общая, не специфична для этого подмодуля.

Сколько данных сторнируете, какая версия BW, BCS, сколько памяти на сервере и т.п. ?
Чем подробнее вопрос, тем быстрее и качественней ответ

Сейчас нет доступа к маркетплейс (из дома). Но что говорят ноты?

Версии:
Компонент ПО - Версия - Краткое описание компонента ПО
SAP_BASIS - 620 - SAP - базисная система
SAP_ABA - 620 - Компоненты, общие для всех приложений
SAP_BW - 310 - Business Information Warehouse
PI_BASIS - 2003_1_620 - PI_BASIS 2003_1_620 : Add-On Delta Upgra
WP-PI - 600_620 - WP-PI 600_620 : Add-On Installation
FINBASIS - 200 - FINBASIS 200: Add-on installation reques
BI_CONT - 330 - Бизнес-информация и аналитика: содержимое
SEM-BW - 350 - SEM-BW 3.2 : Installation.

Параметры в RZ11:
rdisp/PG_SHM - 16384
rdisp/PG_MAXFS - 32768
rdisp/ROLL_MAXFS - 32768
rdisp/ROLL_SHM - 32768

Есть такая нота 133909. Она позволяет увеличить paging area (не знаю, как это по-русски) более чем 2 Гб на 32-битной платформе. В принципе 2 Гб - это 250000 8Кб блоков, то есть параметр rdisp/PG_MAXFS может быть больше 250000. А если он сейчас 32768, то видимо до пользы от этой ноты еще далеко и разумнее просто увеличить параметр rdisp/PG_MAXFS хотя бы до 128000, т.е. до 1 Гб...

Как думаете, поможет?
А я пока пойду попробую )))

Думаю, что должно помочь, но нужно попробовать. Попытка - не пытка. BW вообще такое дело

Вобщем, все изменил, но протестировать не удалось. Пользователи раньше нашли решение и провели сторнирование частями...

Тестировать теперь будем только в следующем году, т.к. подобного наплыва документов в ближайшее время не планируется. Но, думаю, все будет работать