Skip to content

ABAP Keyword Documentation →  ABAP - Reference →  Processing External Data →  ABAP Database Accesses →  Open SQL →  Open SQL - Overview →  Open SQL - SAP Buffering 

SAP Buffer - Buffer Synchronization

Other versions: 7.31 | 7.40 | 7.54

Update

One buffered table or database view usually exists in the SAP buffers of every application server. If a program modifies data from a table on one of the application servers using Open SQL, the servers are updated as follows:

  • The data is modified in the database table on the database.
  • The buffers of the current application server are invalidated directly.
  • In changes made using work areas, the row in question is invalidated in tables with single record buffering. In generically buffered tables, the generic area in question is invalidated and in fully buffered tables, the whole table is invalidated.
  • In changes made using UPDATE ... SET ... WHERE ... or DELETE ... WHERE ..., the whole table is invalidated in tables with single record buffering and full buffering. In generically buffered tables, all generic areas are invalidated that are affected by a left-aligned generic subkey.
  • In buffered database views or CDS views, the entire buffer is invalidated regardless of the buffering type. In client-specific views, however, this only affects the content of the current client.
  • The change is written to the log table DDLOG of the database interface.
  • On all other application servers, the buffers are still in the old state and the Open SQL statements here potentially access obsolete data. The buffers of these application servers are synchronized using the following asynchronous method.
  • In intervals specified using the profile parameter rdisp/bufreftime (the default interval is two minutes), a synchronization is performed on every application server. The database interface reads the log table DDLOG and invalidates the buffer content in the same way as on the application server where the original change was made.
  • The next time the data is accessed, the data of invalidated tables is read directly from the database and updated in the buffer. .


Notes

  • Asynchronous synchronization has the benefit of reducing the network load on the system, particularly when compared with synchronous methods where each change made to the buffered data of an application server is broadcast immediately to all other application servers. The drawback of asynchronous synchronization is that, unlike synchronous methods, the data is not up-to-date in the time between two synchronizations.

  • The asynchronous method of buffer synchronization is a factor in the decision of whether to buffer a database table. Tables where many writes are performed are not suited to buffering, since the SAP buffers would then often be inconsistent and the system would constantly be invalidating and loading the buffers.

  • Changes made using a WHERE condition place a far greater load on buffer management on the current application server than changes made to single rows.

  • In fully buffered client-specified tables or views, it should be noted that generic buffering is performed internally with the client column as a generic key. This means that an invalidation of the entire buffer only affects the content of the current client.

  • In systems with only one application server, it is not necessary to fill the log table DDLOG with the modifications of the buffered tables and this can be switched off by setting the profile parameter rdisp/bufrefmode to sendoff, exeauto.

Eviction

If the free memory in the buffer falls below a predefined value or the quality of access is poor, data is evicted from the buffer. The quality of access depends on the number of accesses that can be met directly from the buffer.

The need for evictions is checked asynchronously at specific points in time (themselves determined using the accesses to the buffer), which means that the length of time between two evictions depends on the buffer load.

Data is evicted from those tables that are accessed least often. Here, accesses to a table are weighted differently depending on the time they take place. Older accesses, for example, are less significant than those that take place shortly before the eviction. This makes it possible to evict those tables from the buffer that are accessed a lot at one particular point in time but then no longer used.


Note

The individual generic areas of generically buffered tables are handled like standalone tables, which means that certain generic areas of a table can be evicted while other generic areas of the same table are kept in the buffer.

Resetting the Buffer

The SAP buffer of the current application server can be reset by invalidating all its data. This is done by entering /$TAB in the command field in the standard toolbar in SAP GUI.


Note

The SAP buffer should only be reset if inconsistencies have arisen in the buffer. It can take a long time to fill the SAP buffer in large systems and this can seriously affect performance.