High collision rate on <name> region 

High collision rate on <name> region: <percentage>%, <number of> accesses (of a total of <number>), <number of> collisions

Explanation

The collision rate is very high when accessing protected areas of the database kernel memory. Access to critical areas in the database kernel memory used by multiple tasks is protected using regions. A database task is assigned exclusive access to a region to prevent multiple database processes / threads from simultaneously manipulating a global memory area. If only one processor is used (XPARAM parameter MAXCPU=1), there can almost never be collisions on this region due to internal tasking (exception: parallel data backup, CONNECTS, and SAVEPOINT). If multiple CPUs are used and there are a high number of collisions on this region, the entire database operation may be sequentialized for accessing this region. In this case, the use of additional CPUs can actually reduce performance due to this additional synchronization administration requirement.

User action

You need to take action if the collision rate is higher than 10%. The higher the number of processes (XPARAM parameter MAXCPU) the more likely there will be collisions. You should therefore check multiprocessor systems to determine whether the database might still be able to adequately handle the application requirements with fewer CPUs. In the R/3 environment the ratio of CPU usage between the database and R/3 is approximately 1:4; this means that on an eight-CPU machine, two CPUs will do. These calculations can also be made for client/server architectures.

If there are high region collision rates on centralized multiple-processor systems (database and application on the same server), check whether the machine is CPU-bound, where the database processes are blocked by the application. If this is the case, those database processes that contain user tasks should receive REAL TIME PRIORITY from the operating system. Make sure, however, that MAXCPU is at least one less than the actual number of CPUs.

Additional measures:

You can use the XPARAM parameters _DATA_CACHE_RGNS and _TREE_RGNS to increase the segmentation of the data cache, thus reducing the likelihood of collisions. At the same time, you should slightly increase the data cache (DATA_CACHE) so that the subcaches are not too small. Problems can arise if there is a high collision rate on only one of the subregions of the DATA, SPLIT or TREE structures. This means that multiple applications are obviously simultaneously processing the same page or at least frequently processing the same table (rootpage). Only a change to the application logic can improve the situation in this case.

Vtrace should be activated only temporarily to find a database problem.