SAP Memory Management

Functions of the SAP Memory Management System

An application runs in an SAP work process where an ABAP program is normally executed.
The process requires memory to do this, which are allocated to it by the memory management
system. The order in which the work process is assigned the memory type depends on the
work process type, either dialog or non-dialog see SAP !emory Types", and the underlying
operating system. This is described in more detail in the documentation on the operating
system.
The area o# a user context that is directly accessible is now extended as needed, i# the user
context has expanded. $or dialog work processes, the data o# the user context, including
internal tables is located in this expanded area. %ou can there#ore access all the data in the
user context. &nly data o# the types 'extract' and 'export to memory' stay in SAP Paging.
The SAP (oll Area is used #or the initial memory assigned to a user context, and i# a)ailable"
#or additional memory i# the expanded memory is #ull.
The #ollowing diagram displays the memory types that can be assigned to work processes on
the SAP and operating system le)el. *ere are the most important system pro#ile parameters
that control the a)ailability o# the memory types.
+
SAP Roll Area
The roll area is a memory area with a set con#igurable" si,e that belongs to a work process. -t
is located in the heap o# the )irtual address space o# the work process. .hen the context o# a
work process changes, the data is copied #rom the roll area to a common resource called the
roll #ile. To pre)ent repeated copying, another roll bu##er is located in between that is part o#
the shared memory. The roll area consists o# / segments. The #irst segment, which can be set
with the parameter ,tta0roll1#irst, is assigned to the work process #irst as memory. -# this is
used up, the work process has more memory assigned to it. The amount o# memory is
determined by the di##erence between the parameters ,tta0roll1area and ,tta0roll1#irst.
SAP Extended Memory
SAP extended memory is the core o# the SAP memory management system. 2ach SAP work
process has a part reser)ed in its )irtual address space #or extended memory see 3irtual
Address Space in a .ork Process". %ou can set the si,e o# extended memory using the pro#ile
parameter em0initial1si,e1!B4 2xtended !emory Pool Si,e. 5nder .indows 6T, #urther
memory is assigned dynamically as needed, and you can also set this amount. %ou can map
the extended memory #rom the common resource onto any work process, and a#ter onto
another process see graphic" on the same address in the )irtual address space. This is
important i# you work with pointers in the ABAP program. 7epending on the operating
system, how you implement the extended memory is di##erent. The SAP system builds a layer
on to the operating system #unctions #or the page management o# this memory. This extended
memory is implemented as an unnamed mapped #ile. This means the address space uses the
paging #ile or uses the swap space o# the operating system as background memory.
Private Memory
&ther processes cannot use pri)ate heap" memory. A#ter releasing the assigned memory, the
operating system still considers the )irtual" memory as being occupied by the allocating
process. These characteristics o# heap memory require that4
+. The work process can be run in P(-3 mode pri)ate" when the local memory is
assigned. This means that the work process is reser)ed #or processing the current user
context until the context releases the work process again when the request has ended.
/. The work process, i# it has used a lot o# pri)ate memory, is restarted when the user
context is terminated and the local memory is returned. The restart makes the local
memory a)ailable again #or other processes. A restart occurs i# a work process uses
/
more local memory than is de#ined in the parameter abap0heaplimit. The mechanism is
displayed again there.
-# a dialog work process has used up the roll area assigned to it and the extended memory,
pri)ate memory is assigned to the work process. The work process goes into P(-3 mode
pri)ate". -n the parameter settings, ensure that not too many dialog work processes are
simultaneously in the P(-3 mode, since this lowers system per#ormance. The other .ork
Process types background, update, enqueue and spool work processes" are assigned heap
memory a#ter the roll area is used up. Allocating 2xtended !emory is not use#ul since no
context change occurs #or these processes.

8
source4 http400help.sap.com
9
B.3 Memory Management
Memory management determines for a particular system activity when, and what
type and size of memory is allocated. Figure B.4 shows the components involved in
SAP memory management.
Figure B.4. SAP MEMR! MA"A#EME"$
n the figure, Shared Memory represents memory space accessi!le !y all wor"
processes. #oll Buffer memory is used to $ueue user dialog re$uests. %hen the #oll
Buffer !ecomes full, user dialog re$uests are swapped to the #oll File. &'tended
Memory stores user conte't (i.e., user data), such as the authorization and session
conte't for each SAP session. Page Buffer memory holds large lists and long internal
ta!les. %hen the Page Buffer !ecomes full, data are swapped to the Page File.
Shared Buffer memory stores !usiness o!*ects and data. A dialog wor" process
chec"s the Shared Buffer first for re$uired !usiness o!*ects and data !efore
searching the B% data!ase. %e will discuss the Shared Buffer later.
%hen a dialog wor" process !ecomes availa!le to process the first user dialog
re$uest in #oll Buffer, it allocates memory in the following order+
,. -he user dialog re$uest, including the initial user conte't, is moved from the
#oll Buffer into #oll Area ,. -here the dialog wor" process can access the
re$uired data directly.
:
.. f #oll Area , is insufficient, more memory is allocated from the &'tended
Memory.
/. f the &'tended Memory is also insufficient, more memory is allocated from
#oll Area ..
4. f #oll Area . is still insufficient, more memory is allocated from the Private
Memory. 0nce this allocation ta"es place, the current dialog wor" process will
no longer !e availa!le to process other user dialog re$uests.
-o ma"e Private Memory availa!le again to process other user dialog
re$uests, the operating system must restart the dialog wor" process.
1. f the Private Memory is still insufficient, the dialog wor" process is restarted,
and the user dialog re$uest is terminated.
After the user dialog re$uest has !een processed, the user conte't rolls into the
&'tended Memory and is ready for use !y the ne't dialog re$uest. n addition, the
#oll Area and Private Memory allocated for the current dialog wor" process are
released.
-his procedure is repeated for each user dialog re$uest in an SAP transaction. At the
end of the SAP transaction, the last dialog wor" process copies the modified user
dialog re$uest !ac" to the #oll Area, and eventually !ac" to the end user.
B.3.% SAP Buffer
-he SAP Buffer stores fre$uently used !usiness o!*ects and data. %ith the SAP
Buffer, wor" processes don2t need to access the data!ase if the !uffer already
contains the re$uired information. -his strategy helps to reduce data!ase access, the
load on the data!ase server, and networ" traffic, there!y improving overall system
performance. f the re$uired information is not availa!le in the !uffer, it must !e
paged into the !uffer !efore it can !e used, resulting in slower performance.
f the SAP Buffer is too small, it cannot hold all of the re$uired information. -his
shortage of space results in the information !eing swapped out of the !uffers.
f the SAP Buffer is too large, the native operating system will start paging !ecause
too much memory is ta"en away and given to SAP, data!ase, or other applications.
-en types of !uffers e'ist+
;
-he #epository Buffer, also called the nameta! (3-AB) !uffer, contains the
ta!le and field definitions
-he Program Buffer contains the compiled e'ecuta!le versions of ABAP
programs
-he 45A Buffer contains the 65 o!*ects, such as menus and push !uttons
-he Screen Buffer contains the generated ABAP screens
-he 4alendar Buffer contains all defined factory and pu!lic holiday calendars
-he 6eneric 7ey -a!le Buffer contains a range of ta!le entries8 it can also
hold all the entries in a ta!le
-he Single #ecord -a!le Buffer contains the single ta!le entries.
-he mport9&'port Buffers contain data that must !e availa!le to several wor"
processes.
-he #oll and Paging Buffers were discussed earlier in this section.
-he 4ursor 4ache contains parsed S:; statements.
For Further &nformation
< Boo"+ SAP #9/ Administrator2s =and!oo", !y >ose Antonio =ernandez (ed.). Mc6raw?=ill
Professional Pu!lishing, ,@@@. SB3+ AAB,/14,/,.
< Boo"+ SAP #9/ System+ A 4lient9Server -echnology, !y #udiger Buc"?&mden, >urgen 6alimow,
SAP A6. Addison?%esley, ,@@C. SB3+ A.A,4A/1A,.
< 0SS 3ote AA/@4,., D How Many Work Processes to Configure.D
< 0SS 3ote AA.,C/C, D RAM Extension: Which Changes to Profile?D
< 0SS 3ote AA,C../, D Probles with Roll Meory.D
<
'irtual Address S(ace of a )or* Process
%ith /.?!it systems, 4 6B of memory can theoretically !e addressed8 depending on the operating
system, there are appro'imately . 6B of virtual address space availa!le to a process.
-his consists of a te't and a data segment, a dynamically e'tendi!le heap and a dynamically
e'tendi!le stac". -he heap increases in size from the !ottom and the stac" increases from the top8
this ena!les the entire virtual address space to !e used.
%ith an SAP wor" process, there are special areas reserved on the heap. -he size of these special
areas can !e set using a profile parameter. -hese areas are+
#oll area
SAP paging area
Private memory
-he largest reserved area is located !etween the heap and stac" of the SAP e'tended memory.

=
&ntegration
The graphic below shows the relationship with the parameters abap0heap1area1dia,
abap0heap1area1nondia, and ,tta0roll1extension.
>