Buffer Synchronization in SAP Systems

The motivation behind writing this post is that I ve noticed several people(technical SAP consultants too) wonder about how multiple SAP instances are able to maintain buffer consistency. I am going to try  to clarify this. I ll talk about how buffering works and then move on to how it maintains its consistency across multiple instances.

In any multi-tier system, avoiding sending requests to the database is of utmost importance to the response time. To achieve this, NetWeaver(or more accurately the SAP_BASIS component) gives the developer control over which database tables to buffer at the application server level itself. Depending on the requirement, different kinds of buffering options are provided, but that wont be our focus here. The advantage is twofold – the user running your application sees improved response times and you dont load the database with your request, freeing it up for other possibly more important requests.

This is perfectly fine when the data buffered is only being read ie. SELECTed. What about when the buffered data is changed? NetWeaver handles it in a straightforward manner. Each time a user issues a UPDATE or MODIFY on some data records which have been buffered, the system simply invalidates the buffered records. The next time another user reads the same records, the buffer is bypassed and the database is accessed. These new records that are picked from the database are then loaded to the buffer so that they are available to other users until the next change. All of this works with the help of timestamps that are recorded each time data is loaded into the buffer and each time the data is changed in the database.

Clearly, this single instance scenario doesn’t cause any data inconsistency. But this is not guaranteed in systems where you have multiple instances.

Consider the case of of a single system, with two instances to each of which one user has currently logged on. Suppose that, there is a table at the database level which is buffered to the application server. Now, User1 reads a record. Assuming Generic Buffering for the table, all the records of the selected table are put into the buffer of instance1. Similarly, when User2 reads data from the same table, instance2’s buffers contain the table in its entirety. At this point, both buffers are consistent.

Next let us suppose that User1 modifies a few records. This immediately invalidates the buffers in instance1. The next time another user on instance1 tries to read data from this table, his request will be met from the database directly and the buffers will be refreshed. But what about a similar read from a user logged to instance2? This instance is not aware of the invalidated buffers. So the request from a user here will be responded to with ‘old’ data which is not anymore valid. This could have dangerous consequences right from a transactional failure to having inconsistent business data in the database.

To counter this very real possibility, SAP has a buffer synchronization mechanism and a set of guidelines to follow on what to buffer. To enable the synchronization mechanism, set the instance parameter rdisp/bufrefmode to the value sendon, exeauto. Now, when a user invalidates buffers on instance1, sendon instructs the instance to log the buffer invalidation in table DDLOG. The value exeauto of the parameter on the other instances tells them to periodically check the validity of their buffers against DDLOG. If invalid, then the next access to the data on the instance happens from the database. The periodicity of these checks is decided by another system parameter rdisp/bufreftime in seconds. Usually it is set to between 60-120 seconds.

Now, this periodicity may seem too high as on almost any sufficiently large system several users are concurrently reading and changing data. This where we come to the second part of the protection against buffer inconsistency – buffering guidelines.

As rule of thumb, never buffer tables which contain transactional data. Why is this? Because transactional data changes too often. A 60s time frame is too long to guarantee buffer consistency for. Reducing the periodicity will help in maintaining consistency but will introduce additional system overhead with frequent buffer checks.

An interesting exception to the above guideline is the table NRIV which holds number range objects. I would urge you to read on it as the working of number ranges is quite interesting but falls beyond the scope of this post.

Comments

One comment on “Buffer Synchronization in SAP Systems”
  1. Pokker says:

    Good blog but I would like to “read on” but cannot see the link to do so sorry.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s