MEMORY_NO_MORE_PAGING — MEMORY_NO_MORE_PAGING Runtime Error
MEMORY_NO_MORE_PAGING is raised when a work process cannot get more space in the instance's shared paging area, a memory pool used for internal tables and other work data before extended memory is engaged. Unlike per-user memory dumps, this pool is shared across all processes on the instance, so exhaustion is usually a sign that one program or a cluster of concurrent jobs has consumed the whole shared area, not just its own allowance.
Covers the MEMORY_NO_MORE_PAGING runtime error on ABAP application servers, distinguishing it from the more common per-user memory dumps by its shared, instance-wide nature. Focuses on identifying whether the trigger is a single runaway program or genuine undersizing of the paging file parameters, and on the diagnostic order in ST22, ST02 and SM50/SM66 needed to tell the two apart.
Published 16 Sept 2026· 1,210 words
What the dump means
The ABAP memory model moves data through several tiers as a program's working set grows: roll area, paging area, extended memory, then heap memory. The paging area is a shared file-backed buffer sized at the instance level by profile parameters controlling the paging file size and the shared memory paging buffer. MEMORY_NO_MORE_PAGING fires when a work process asks for a paging block and the instance has none left to give, because the shared pool is already full. This is different from TSV_TNEW_PAGE_ALLOC_FAILED or SYSTEM_NO_ROLL, which are limits hit by a single user context. A paging exhaustion dump can appear on a program that itself is doing nothing unusual, simply because another process on the same instance has already consumed the shared area. The dump therefore says less about the dumping program than about total instance memory pressure at that moment.
Root causes that actually produce it
- Undersized paging file parameters: the instance's paging file size and shared paging buffer were set for a workload the system has since outgrown. Common after a Unicode conversion, an add-on install, or simple data volume growth, where average internal table sizes increased but the paging parameters were never revisited.
- A single runaway program: a report or batch job builds an internal table far larger than intended, often from a missing WHERE restriction, a Cartesian join in a SELECT, or an unbounded loop that appends rather than processes in packages. This one session can consume most of the shared paging pool and starve every other process on the instance simultaneously.
- Concurrent load spike: several dialog or background processes each hold a moderate, individually reasonable paging allocation, but the sum exceeds the shared pool at a busy period such as month-end close or a mass data load window that was not capacity planned.
- Memory not released across a long-running session: custom code holds large internal tables alive for the life of a session instead of freeing them after use, so paging consumption accumulates over the day rather than being returned quickly.
- Genuine data volume growth outpacing hardware: the business has scaled up (more line items, more customers, larger extracts) and the instance's physical memory and paging file were never resized to match, so what used to be comfortable headroom is now routinely exhausted.
What to inspect in ST22
- Runtime error name and category at the top of the ST22 entry, confirming this is a memory shortage and not a related but distinct roll or extended memory dump.
- The program and include named as the trigger location: this is the process that happened to ask for paging memory when the pool ran dry, which may or may not be the actual consumer.
- The memory or storage summary further down the dump, showing the paging area size configured and how much was requested versus available at the moment of failure.
- Timestamp of the dump, used to cross-check against SM50 or SM66 across the whole instance for that exact minute, looking for a process with an abnormally large private or paging memory figure.
- ST02 buffer and memory statistics around the same timestamp, to see whether paging usage was climbing steadily (points to a leak or slow accumulation) or spiked suddenly (points to one runaway job).
- AL08 or SM04 for the number of active users and jobs at the time, to judge whether this was a concurrency spike rather than a single bad program.
Resolution path
If ST02 shows the paging area was already running close to full before the dump and the trigger program looks unremarkable, the fix is capacity: increase the paging file size and shared paging buffer parameters and restart the instance to apply them. This is a Basis change and needs a change request since it alters instance profile parameters and requires a restart window. If SM50 or SM66 shows one process with a disproportionately large memory footprint at the time of the dump, the fix is in the code: add package processing (FETCH into smaller chunks, or SELECT with an explicit package size), tighten the WHERE clause, or insert FREE statements to release internal tables once they are no longer needed. This is an ABAP change and goes through the normal transport process, ideally with a test against production-sized data volumes before release. If the cause is a genuine concurrency spike during a known peak window, the interim fix is scheduling batch jobs to avoid overlap, and the durable fix is the same parameter increase as the undersizing case, sized against the peak rather than the average load.
The fix people try first (and why it fails)
The first reflex is to restart the application server instance and consider the incident closed once users can log back in. This clears the shared paging pool immediately and the dump stops recurring for a while, which makes the restart feel like a fix. It is not: nothing about the undersized parameter or the runaway program has changed, so the pool fills up again on the next equivalent load, often at the next month-end or the next run of the same job. Increasing ztta/roll_area is also a common wrong move, since that parameter governs roll area per user context, not the shared paging area, and has no effect on this dump.
Prevention
Track paging area utilization in ST02 as a routine health check, not just after an incident, and set an internal threshold for investigating sustained high usage before it becomes a dump. Review any custom report that builds large internal tables for package processing and explicit FREE statements once the data is consumed. Include paging file sizing in the standard capacity review whenever a data volume increase is planned, rather than waiting for the dump to force the conversation.
Whose problem this is
Basis owns the instance parameter side: paging file size, shared paging buffer, and the restart to apply changes. ABAP development owns any code identified as the actual consumer. The handover note should carry the dump timestamp, the triggering program and include, the ST02 paging figures around that time, and the concurrent user or job count, so the receiving team does not have to reopen the investigation from scratch.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-abap-dumps/memory-no-more-pagingERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.