Show TOC

Function documentationSizing Lock Tables Locate this document in the navigation structure

 

For a real-time InfoCube, no access is allowed to the BW lock server during a lock operation. Space on the lock server is restricted. When implementing planning applications in a BW system, it is therefore necessary to choose a design that keeps the number and size of the selections as small as possible. The smaller the lock table, the better the response times of the lock server.

You can reduce the size of the lock table by removing characteristics from the list of lock-relevant characteristics in a real-time InfoCube if these characteristics do not serve to divide the selection. These include characteristics which are the same for all users or which have overlapping values. More information: Selecting Lock Characteristics.

The following sections contain information about sizing the lock table for BW Integrated Planning. These sections explain how to calculate the required memory and set the profile parameters accordingly.

Note Note

For more information about the various options for storing lock tables, see Storing Lock Tables.

For up-to-date sizing information, see SAP Note 928044, BW lock server.

End of the note.

Integration

In profile parameter maintenance (transaction RZ11), you can display the values that are set currently.

Features

Storing Lock Tables on the SAP Standard Lock Server

You use profile parameter enque/table_size to set the size of the lock table on the SAP standard lock server.

The enque/table_size = 25.000 setting should be sufficient for most systems where BW Integrated Planning is used.

You can get a more accurate idea of the number of lock records required as follows:

  • The number of InfoCubes being used actively is IC.

  • The average number of rows in the selection table is Rec. In lock setting maintenance for planning (transaction RSPLSE), you can calculate this number for a given user by viewing the locked selections on the Display of Active Locks tab page.

  • The number of lock requests per user is LReq. This number depends on how the planning application was designed - the number of input-ready queries, the number of related planning applications, and how often these components request data in change mode.

  • The number of active users is U.

  • The compression factor for a selection table is Compr. This factor is between 5 and 10.

The number of NLCK lock records is then:

NLCK = IC * U * LReq * Rec / Compr

In SAP lock management (transaction SM12), choose   Extras   Statistics   to ascertain the maximum number of lock records that can be stored in the lock table according to the current value of the enque/table_size profile parameter. You find the value in the Lock Entries Table, Size row.

Storing Lock Tables in the Shared Object Memory of an Application Server (Default System Setting)

You use the abap/shared_objects_size_MB profile parameter to set the size of the lock table in the shared object memory of an application server.

The abap/shared_objects_size_MB = 200 setting should be sufficient for most systems where BW Integrated Planning is used.

You can get a more accurate idea of the number of lock records required as follows:

  • The number of InfoCubes being used actively is IC.

  • The average number of rows in the selection table is Rec. The actual selections are in the shared object memory twice: once optimized for search access by characteristic and once optimized for access by locked selection (secondary index). The DDIC structure used has a width of 207 characters, or 207 bytes (414 bytes in Unicode systems). You can expect approximately one kilobyte per row in the selection table.

  • The number of lock requests per user is LReq. This number depends on how the planning application was designed - the number of input-ready queries, the number of related planning applications, and how often these components request data in change mode.

  • The number of active users is U.

The number of NLCK lock records is then:

NLCK = IC * U * LReq * Rec

The required memory space in KB is calculated by multiplying NLCK by 2. This is because, when a lock is requested, the system makes a copy of the locked selection and retains this for the duration of the collision check.

For information about the memory currently required for the BW lock server, see area maintenance for the shared object (transaction SHMA). Call this transaction on the server with the BW lock table and use CL_RSPLS_ENQ_AREA as the area.

Storing Lock Tables in SAP liveCache

If you want to use the SAP liveCache on the BW lock server, see SAP Note 816730 for the relevant sizing information.