Не могу побороть MEMORY_NO_MORE_PAGING

Salmaner

Всем доброго времени суток!

Как только я не пытался побороть вываливание в дамп с ошибкой MEMORY_NO_MORE_PAGING.
Вываливаюсь на строке лив программ.

Code:

EXPORT g_t_item to MEMORY ID 'RSV_G_T_ITEM'.
g_aplstat = '0'.    "success
perform CLOSE_SCHEDMAN.
===> LEAVE PROGRAM.

При вызове отчета вторым пользователем, т.е. один раз отчет отрабатывает и пока он висит, второй раз отчет нельзя запусить ...валимся в дамп и все тут.

Сначало посмотрел объем таблицы, которую я отправлял в абап память, это было 20 метров (57 тыщ строк 50 полей).
уменьшил количество записей до 6 тыщ.
Сделал фри абап памяти, добавил рефрешки после использования таблицы.
ни чего не помогло ...
Потом давай подробно изучать вызываемый (submit) мною отчет из моей программы (копия стандартного отчета документов иерархии RFFMEP4BX).
Обратил внимание что после отработки отчета вызывается подпрограмма

Цитата:

perform CLOSE_SCHEDMAN.

посмотрел ее, добавил себе тоже. не помогло.
Потом обратил внимание что в вызываемом отчете устанавливается константа

Code:

CONSTANTS: con_repid like SY-CPROG VALUE 'RFFMEP4BX'.

вай вай, поменял на

Code:

CONSTANTS: con_repid like SY-CPROG VALUE 'ZRFFMEP4BX'.

не помогло.
Я читал сообщения дампа долго и упорно, ругается на переполнение памяти и на сабмиты, колтранзакции.

Цитата:

(1) Data clusters (EXPORT ... TO MEMORY ...)
(2) Parameters for calling programs (SUBMIT REPORT ...),
Dialog modules (CALL DIALOG ...) and transactions
(CALL TRANSACTION USING ...)
(3) Internally defined program macros (DEFINE ...)

Еще обратил внимание на строчки

Цитата:

Accordingly, you should check the relevant statements in a program
that results in an overflow of the SAP paging area.

It is critical when many internal tables, possibly with
different IDs, are written to memory (EXPORT).

Вроде айди внутренних таблиц напутанны ..., проверял в отладчике айди експортируемой таблицы все с ней хорошо, появлятся. после импорта исчезает.
Что не так? я не первый раз использую копии стандартных отчетов для получения готовой таблицы с данными и не разу еще не натыкался та такие грабли.

Ваши коменты друзья!

Monarch

Обратитесь к базисникам, чтобы они соотв. параметры памяти в настройках системы увеличили.
Если не поможет - надо делать по-другому, не через EXPORT TO MEMORY ID.
Вообще, экспортировать большой объем данных через память не есть гут.

Salmaner

Базисник дажене не стал слушать про изменение параметров памяти.
И "запретил" вообще пользоваться EXPORT TO MEMORY ID.

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

sibrin

Ну, 20 Мб не так уж и много, чтобы вообще EXPORT запрещать.

Есть предположение, что ограничения по памяти для каждого id. Попробуй в id добавить имя пользователя.

dump

а если использовать EXPORT TO DATABASE

Дима

может попробовать для каждого пользователя использовать свою область для хранения, что-то типа:

Code:

concatenate sy-uname progdata into memoryid
EXPORT g_t_item to MEMORY ID MEMORYID.

ну или через field-symbols не проверял правда, прокатит ли такой вариант

упс, а sibrin, оказывается уже об этом писал

Salmaner

Ну на конецто вы пришли ...

думал все, отпуска лето и т.д.

Я тоже так думаю что, 20 метров это еще не повод, но не могу найти подтверждение, какой рекомендуемый объем данных в память пожно пихать.

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

Кстати платформа стоит на винде + ее сиквел.
Пока шерстил инет, наткнулся на несколько ссылок нот по поводу настроек параметров памяти под винду, но сам не базисник ...

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

vga

Вы не пробовали искать по коду программы, где еще используется
EXPORT to MEMORY ID ?

20Мб вряд ли является проблемой, вероятно существуют более жирные таблицы, которые хранятся в abap памяти.

Попробуйте закомментировать
EXPORT g_t_item to MEMORY ID 'RSV_G_T_ITEM'.
будет падать?

Salmaner

vga

Да я уже так пробовал, забыл написать, тогда нету дампа, прога просто отрабатывает и уходит в лив.
по поводу 20 мб, тоже забыл сказать, замерял через одно место, т.е. в отладчике перед экспортом сохранил таблицу в файл, т.е. это размер таблицы в сохраненном файле, не знаю на сколько это будет адекватно сравнивать с объемем в памяти

Еще, вызываемая программа исользует лбд FMF бюджета. Сама выборка этой лбд тяжеловата, я поэтому и не стал сам писать выборку из лбд а решил взять готовую из отчета.
Поискать еще експорт в память, да нету вроде, только вот я думаю поиск не полезет в программы лбд искать, только по инклудам, а там нет.
На данный момент, получилось сделать експорт в кластер INDX, дампа пропал, вроде работает, что покажет активное использование отчета юзерами, время покажет.

Всем башое пасиба!

marina_utkina

Добрый день!
А вот при использовании export to database - Вы как делали ID - статический или динамический? мне тут указали, что раз он у меня прописан статический, то несколько пользователей не смогут работать.. и велели исправить.. да вроде с ноября месяца работают в трех разныз системах, и никто не жаловался.....
заранее благодарна...
в примерах из хэлпа - пишут ID "в лоб"......

Правила форума

Не могу побороть MEMORY_NO_MORE_PAGING

Кто сейчас на конференции