Search on this Website

Thursday, August 30, 2007

SAP Memory Management and SAP Instance

Starting with release 3.0 of R/3, SAP introduced a new concept in its use of main memory to improve the overall performance of the system, in respect to previous R/3 releases (2.2 and earlier). The main change was to extensively make use of an extended memory management system to optimize the access to the user

SAP R/3 Communication Protocols and Interfaces contexts and thus avoid the overhead caused by heavy roll−in/roll−out tasks of previous releases. User context is defined as the user data which is kept by the system between dialog steps to continue the processing of the transaction. These data contain such things as authorizations, field information, internal tables, runtime environment management information, and so on. Roll−in is the process of making the data available to the work processes when they need it.

With the extended memory management functions, all user contexts of an application server are held in main memory and are shared by all work processes. In previous releases, the user contexts were in the roll files and had to be copied from one place to another when user sessions were handled by different work processes. With the new memory management, those previous copy functions (copying user contexts to roll areas) are handled by just reassigning pointers in main memory.

With this technique there is a significant improvement in performance, since context switching is a very frequent task when attending to interactive users. In order to observe the real improvements, the system needs more memory and swap space than previous versions.

With SAP releases prior to 3.0, the user context area used by the dialog processes was limited to the size of the roll area. The new memory management allows the size of this area to be extended as the size of user contexts increases. All the data in the user context is directly accessible .
Work processes memory allocation. SAP, and not the operating system, takes care of page management for the user contexts which are held in shared memory because SAP's strategy is for openness and thus it is platform−independent.

This shared memory is technically implemented using an unnamed mapped file. In UNIX systems, this means that the address space is mapped onto the operating swap space. For more information on memory mapping, refer to the operating system manuals or online help.

To tune and configure memory management, make sure that your system meets all requirements regarding memory and swap space. SAP automatically sets some default parameters depending on your particular configuration. There are some utilities available for monitoring the operation of the memory management to later fine−tune it.

The Concept of a SAP Instance

An instance is an administrative entity that groups together R/3 components which offer one or several services. These offered services are started or stopped together. All instance components are configured using a common instance profile. For more information on SAP profiles please refer to the section entitled .

A centralized SAP R/3 system would be made of a unique instance. Another feature which distinguishes the instances is that every SAP instance has its own buffer area, which means that it allocated its own main memory space.

SAP distinguishes between central instances and dialog instances. Every SAP system has just one central instance, which contains all basic services such as the message server, gateway, update, enqueue, dialog, spool, and background right from installation. Dialog instances, as defined, only contain a set of basic services such as dialog and background work processes from the time of installation.

Administrators can later customize all the services and their server locations by using SAP instance profiles. A central system can be further configured to a distributed system, creating additional instances offering additional services. The usual way of configuring the system right out of the box is to have just one instance per computer; however, providing your systems have enough main memory and processing power, you can install additional instances, which have some advantages.

Building the Client/Server SAP R/3 System

Once all the processes and components which make up the SAP system are known, we can see how all these pieces come together to form a whole client/server R/3 system.

The starting point is a server system (hardware point of view) with the required memory, disks, network controller cards, and operating system.

On this first server, add the relational database management system with its corresponding database processes. At this moment, you have the database server. The database is, of course,
installed on the disks connected to this computer server.

Now, add basic R/3 services (work processes). We have added a printer to this system to get a connection between the SAP spool work process and the host spool system.

No comments: