Обычно такой дамп возникает не один, а генерируется массово. Причём одновременно у нескольких пользователей одной SAP инстанции (рис. 1 и 2).  

Рис. 1. Пример генерации системных дампов типа MEMORY_NO_MORE_PAGING.

Рис. 2. Пример системного дампа MEMORY_NO_MORE_PAGING.

Данный сбой происходит тогда, когда рабочий процесс инстанции SAP системы, выполняющий ABAP-код, не может получить очередную порцию памяти из Paging Area (или SAP paging memory). В данной области хранятся временные ABAP объекты (Data clusters и параметры для вызывающих программ и транзакций), создаваемые во время выполнения операндов вида IMPORT/EXPORT FROM/TO MEMORY, SUBMIT REPORT, CALL TRANSACTION, CALL DIALOG и так далее (рис. 3). Про эту область я уже упоминал в нескольких своих постах (ссылка 1, ссылка 2).

Рис. 3. Примеры операндов, использующих Paging Area.

Анализ текущего размера и использования Paging Area осуществляется в транзакции ST02 (рис. 4).  

Рис. 4. Мониторинг использования Paging Area.

Возможен так же просмотр не только текущего и максимально использованного размера области, но и исторических данных. Для этого необходимо дважды щелкнуть мышью на имя области "Paging area". По информации на открывшемся экране можно проанализировать, например, в какой день использование данной области достигло своего максимума (рис. 5).

Рис. 5. История использования Roll и Page областей инстанции.

Как вы можете заметить, данные в историю попадают каждый день в 22:28. А это явно не пиковое рабочее время системы. Поэтому большого смысла анализировать значения в поле "Used" на этом экране нет.

Paging Area состоит из двух частей: область в памяти - SAP paging buffer и файл на уровне сервера приложений - SAP paging file. В данном случае (рис. 4) можно заметить, что область заполнена почти на 94%. И если рабочие процессы текущей инстанции будут запрашивать место в Paging Area и дальше (но при этом не освобождать его), то область переполнится. И, как результат, в системе начнут генерироваться системные дампы типа MEMORY_NO_MORE_PAGING (рис. 1 и 2). 

Настройка размера области производится с помощью двух параметров инстанции: rdisp/PG_SHM и rdisp/PG_MAXFS. Единица измерения - блоки по 8 Кб. Первый параметр задаёт размер области Paging Area в оперативной памяти, а второй - общий размер, равный сумме Paging buffer и Paging file. При этом местоположение файла задаётся через параметр DIR_REORG. По умолчанию это /usr/sap/<SID>/<Instance>/data, а имя файла - PAGFIL<Instance_number>.

Чем больше будет часть Paging Area находящаяся в оперативной памяти, тем выше будет производительность операций при работе с ней. В идеале, можно выставить rdisp/PG_SHM = rdisp/PG_MAXFS. Как вы понимаете, в этом случае вся область будет располагаться в оперативной памяти. 

Таким образом, для решения обозначенной в начале поста проблемы, когда в системе генерируются дампы типа MEMORY_NO_MORE_PAGING, достаточно увеличить размер Paging Area. 

Но здесь кроется одна проблема. На системах, основанных на SAP NetWeaver версии 7.0 и ниже, максимальное значение параметра rdisp/PG_MAXFS указано равным 262 144 (рис. 6). Это соответствует размеру области равному 262 144 * 8 Кб = 2 Гб.