The BASIS of SAP

I had one of those ‘doh’ moments during a recent SAP performance performance tuning workshop. The instructor, Tim Bohlsen, pointed out a remarkably easy way to discover how large a table buffer that a running ABAP WAS system instance requires to reduce buffer swaps to zero.

This is important because the easiest way to reduce your database I/O in ANY application, SAP or not, is to reduce the need to go to disk. Keeping data in the Application buffer improves response time by reducing the time (both the CPU time and the I/O time) requiried by the DBMS to continually retrieve that data.

In the case of an ABAP engine, you use transaction ST02 to determine if there is any swapping going on in the first place. In the case shown below, both table buffers have some swapping - it is a relatively well tuned HR/PY system, so there isn’t much table buffer swapping despite the sytem being up for two months. Oh, and there isn’t much point in doing this on any other system except the one you wish to tune as it will be extremely difficult to replicate the load of the target system.

Select the images to open larger versions in another window or tab

In this case, we will look at the Generic Key Buffer, since it is the the worst of the two Table Buffers. Selecting the buffer in question, by double cliking on the line, results in a screen showing a little bit more detail. This has some usefull navigation features. As shown below, we are looking at the current status of the buffer, but we have the option to look at the history of the buffer. This can give us an idea of when the swaps occurred, which we can then track back to certain workloads. Moe importantly, we can look at the current status of the individual objects in the buffer.

Now we have the statistics for individual tables (or parts thereof ) that are currently loaded into this Buffer. This data is usefull in and of itself, which I will touch on in a later post, but first, select the Next View button.

The value highlighted below is the total value for Size maximum [bytes]. This is the sum of the highwater mark for each table that has been loaded into the buffer so far. In other words, the amount of storage required to accept all data requests that should be buffered, without swapping, since the instance was started.

Now, you could put this value straight in to the appropriate profile parameter and restart your system, but there are a couple of caveats.

1. If a table is marked to be buffered, but has not been read yet, it will not be included in the buffer or, therefore, the buffer size yet,
2. You need to examine the detail of both the snapshot and the history to determine if the correct tables are buffered or if they are correctly buffered (the Invalidations total suggests that there is some work to do in this area), and, most importantly,
3. This does not tell you if you have sufficient storage available to fulfill any increase in the buffer size without causing problems elsewhere

So, make sure your system has been through a pay run, or a month-end (or whatever the appropriate business cycle is) before you use this method to measure the requirement,
use sappfpar to validate the storage requirements of your new profile parameters, and
be aware that this is only the first step towards efficient use of all of the available resources.

This won’t fix all your performance problems. However, it is an important first step. Your database vendor may make the most efficient database engine there is, but calling any DBMS to get data will always be slower than getting that data from memory.