SAP Library - Find your answers

Keyword: BASIS
Title : SAP on DB2 for Linux, UNIX and Windows: Important SAP Notes

The “ntscmgr.exe” program located in the Exe -> Run directory can be used to reinstall the SAPOSCOL as a service.

Execute the following command:

ntscmgr.exe install SAPOsCol -b saposcol.exe –p

Prerequisites

If the operating system is not occupied with other functions, all the pages in the working memory that are not in the address area of an active work process are swapped out (lazy page out) of the operating system as a preventive measure. If space is then required, the pages already swapped out only have to be deleted.

In a performing system, Transaction ST06 thereby displays a high Pages out value and a small Pages in value in relation. This indicates that many of the swapped out pages were not overwritten and could not be included again through a work process without a page file access. Therefore, only the Pages in value is very important when assessing system performance.

See: Special Features under Windows NT

Procedure

Using the paging mechanism lazy page out (removing the pages that are not in the address area of an active process), Windows NT creates permanently free working memory (see Special Features under Windows NT). Therefore, Transaction ST06 displays a very high value for Physical mem free in comparison to Physical mem avail (see the following graphic). Due to a faulty interpretation, the number of work processes is often increased ("There is still unused working memory available").

The basis for the Zero Administration Memory Management under Windows NT is the dynamic Extended Memory. This technique provides you with a nearly unlimited memory resource. Initially, the extended memory is set to the size of the profile parameter phys_memsize ([PM]). If the user requires more memory, Extended Memory extends itself in steps from "[PM] / 2" up to the set limits in the profile parameter em/max_size_MB , or until the address space in the NT page file is used up. By setting the default value for em/max_size_MB to 2000 MB, the size of the NT page file represents the actual limit for extending the Extended Memory. The profile parameter phys_memsize determines how much of the total main memory is used by R/3. The parameter is entered according to the input at installation. The default value for phys_memsize is the size of the main memory [MM].

The memory allocation strategy for a non-dialog work process was changed as of Release 4.0B. Through the previous allocation sequence, the extended memory was protected to the benefit of the heap memory. This is no longer necessary when using the dynamic Extended Memory, and the allocation sequence of the batch work processes is identical to the sequence of the dialog work processes (see Allocating Memory for User Contexts). Another beneficial side effect is that you can avoid the PRIV mode (see Private Memory) for background work processes and thereby the expensive restarting of work processes.

Sequence of allocating memory for non-dialog work processes:

1. Roll memory until the limit
ztta/roll_first
2. Extended memory until the limit
min {em/address_space_MB, ztta/roll_extension}
3. Roll memory until the limit
ztta/roll_area
4. Heap memory until the limit
abap/heap_area_nondia

The basis for zero administration memory management is a sufficiently large NT page file. The previous recommendation

NT page file = 3 to 4 times the main memory size

still remains.

All relevant memory management parameters are set with an optimal default value so that all manual configurations are unnecessary.

See also: Memory Management under Windows NT

Applying SP4 to Windows 2000 Server

You need to download a newer SAP kernel. You will need an OSS ID and password to access http://service.sap.com/patches. And you will need to know what R/3 version, database, and OS you currently use.

Once you are at the patches website, you will need to click in the navigation tree:
R/3 -> R/3 + ?Release number? -> Binary patches ->
SAP Kernel + ?Release number? + 32-Bit -> NT/I386.

Download everything from the database section and everything from the database independent section.

One of the files you downloaded should start with SAPCAR and end with a *.exe.
Rename this file to SAPCAR.EXE and place it in the c:\winnt\system32 directory.
Go to \usr\sap\\SYS\exe\run and backup the entire directory to some other directory -
I usually create a \usr\sap\\SYS\exe\backup_run directory. Make sure SAP is down, the database is down, the TNS listener is down, and the SAPOSCOL is down before you do this.

Uncompress all the files you downloaded by opening a DOS box and typing:

SAPCAR -xvf .CAR

All files ending with .SAR or .CAR must be uncompressed. All the extracted files need to be moved to the \usr\sap\\SYS\exe\run AFTER that directory has been completely backed up.

Once everything has been downloaded, uncompressed, and moved into the exe\run directory, you can start the SAPOSCOL, the listener and the database services again. And then you should be able to start SAP. If there are any application servers for this database instance, the SAP software will update those kernels on startup.

If the SAP instance STILL does not come back up, you can take down everything again and restore the exe\run directory with your backup copy. Nothing will have been damaged.

You need to download a newer SAP kernel. You will need an OSS ID and password to access http://service.sap.com/patches. And you will need to know what R/3 version, database, and OS you currently use.

Once you are at the patches website, you will need to click in the navigation tree:
R/3 -> R/3 + ?Release number? -> Binary patches ->
SAP Kernel + ?Release number? + 32-Bit -> NT/I386.

Download everything from the database section and everything from the database independent section.

One of the files you downloaded should start with SAPCAR and end with a *.exe.
Rename this file to SAPCAR.EXE and place it in the c:\winnt\system32 directory.
Go to \usr\sap\\SYS\exe\run and backup the entire directory to some other directory -
I usually create a \usr\sap\\SYS\exe\backup_run directory. Make sure SAP is down, the database is down, the TNS listener is down, and the SAPOSCOL is down before you do this.

Uncompress all the files you downloaded by opening a DOS box and typing:

SAPCAR -xvf .CAR

All files ending with .SAR or .CAR must be uncompressed. All the extracted files need to be moved to the \usr\sap\\SYS\exe\run AFTER that directory has been completely backed up.

Once everything has been downloaded, uncompressed, and moved into the exe\run directory, you can start the SAPOSCOL, the listener and the database services again. And then you should be able to start SAP. If there are any application servers for this database instance, the SAP software will update those kernels on startup.

If the SAP instance STILL does not come back up, you can take down everything again and restore the exe\run directory with your backup copy. Nothing will have been damaged.

Follow the steps while applying service packs:

1. Stop SAP
2. Backup the Database
3. Backup the :\usr\sap*
4. Apply the Support Package and any updates
5. Reboot the Server
6. Start SAP
7. Check that the SAP system is working correctly

All relevant memory management parameters are set with an optimal default value so that all manual configurations are unnecessary.

The following table gives you an overview of these values.

The Windows NT file cache directly competes with R/3 programs for working memory. It pushes other programs out of the memory. Therefore, you should minimize the file cache with the following configuration.

There is only one way to minimize the file cache under Windows NT. To do this, call the network setting (icon: Network) in the Control Panel.

The following are rules for memory management under Windows NT:

Minimizing the Windows NT File Cache

Maximum Use of Extended Memory

Setting Dimensions for Sufficient Extended Memory

Determining the Number of Work Processes, compared to reducing UNIX

Parameter Overview for Windows NT

• The Windows NT file cache directly competes with R/3 programs and pushes these programs out of the working memory. Unlike UNIX, the file cache is only indirectly influenced by a switch in the network setting.
• Writing and reading R/3 roll and paging blocks in the relevant storage files extends the Windows NT file cache and pushes out the R/3 programs from the working memory.
• Copying roll and paging blocks when changing contexts is more time-consuming than including memory blocks when using Extended Memory. Extended Memory also has the advantage that it is subject to the performance-oriented Windows NT paging mechanism.
• Windows NT does not offer you code sharing (exception: DLLs). This means that all work processes fill the complete memory area in the memory. This leads to a greater memory requirement for the work processes compared to UNIX.
• Pages in the Extended Memory that are not in the address area of an active process are transferred automatically in the page file by the operating system. The pages remain duplicated in the physical memory until the memory area is required by another process. They are marked as transferred. The transfer has a low priority and is described as a lazy page out. If a work process now accesses a lazy page out, the memory area is included again without the page file access. If there is enough working memory, the result is a large [page out] and a small [page in] value. When a lazy page out action occurs, Windows NT creates permanently free available working memory. Therefore, even a page-in with a page file access is faster than on UNIX systems, since it is not necessary to transfer another page beforehand (no direct page-out before a page-in).

The previous valid recommendations for setting the memory management cannot be completely used for Windows NT. The operating system can use other memory administration mechanisms than the various UNIX derivatives. You must evaluate the performance statistics displayed by transactions ST02 and ST06 (monitoring system performance) differently than with UNIX systems due to the above-mentioned reason.

This unit serves as a guide for setting the SAP R/3 Memory Management under Windows NT. By using this guide, the system administrator for a Windows NT application server should be better able to evaluate the performance of the system and to tune the system accordingly.

Implementing the memory management system under Windows NT is described in Implementation on Windows NT.

To find the guidelines to configure the memory management under Windows NT, refer to Rules for Memory Management under Windows NT, and for a quick overview of all important parameters, refer to Parameter Overview for Windows NT.

Prerequisites

Check if your host system fulfills the SAP recommendations regarding main memory and swap space.

Check the resources and system-specific requirements on all host systems on which an R/3 server is to be installed. For more information, see Checking the Hardware and Operating System of the Host System.

Procedure

Set the R/3 profile parameters that influence the memory management system.

Set these parameters in the instance profile that is used by the R/3 application servers in your system. For more information, see the CCMS Guide.

If you modify the profiles directly with a system editor, you must perform an error check. For more information, see Checking the Hardware and Operating System of the Host System.

The configuration of the memory management system depends largely on the number of users for each R/3 application server. Various configurations are described in the following units:

Application Server with Up to 15 Users

Application Server with Up to 50 Users

Application Server with Over 50 Users

You can find a general parameter overview for Windows NT under Parameter Overview for Windows NT.

Use

Unit: 1 MB

Default value: 512 MB

Recommended value: 512 MB

Value range: 128 - 1500 MB

Changes: Customers can change the parameter. Generally, the default value is the correct value.