Ansicht
Dokumentation

ABENBUFFER_SYNCHRO - BUFFER SYNCHRO

PERFORM Short Reference   PERFORM Short Reference  
This documentation is copyright by SAP AG.

- Buffer Synchronization

Invalidating and Updating

A buffered table or view usually exists in the table buffers of every. If a program in one of the modifies data from a table using , the data is updated as follows:

• The data is modified in the database table on the database.

• The buffers of the current are invalidated immediately.

• In changes made using work areas, the affected row is invalidated in tables with single record buffering. In generically buffered tables, the affected generic area is invalidated and in fully buffered tables, the whole table is invalidated.

• In changes made using UPDATE ... SET ... WHERE ... or DELETE ... WHERE ..., the entire 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 DDIC database views or CDS views, the entire buffer is invalidated regardless of the buffering type. In client-dependent views, however, this only affects the content of the current client.

• The invalidated data is written to the log table DDLOG of the database interface.

• Provided that no database commits have been performed for a change to the buffered table, all database reads on the in which the change was performed access the database directly and bypass the buffer. After a database commit, the following applies to reads on this :

• In the case of single record buffering and a change, which only relates to a single record in this type of table, the buffer is updated immediately on read access.

• In the case of generic, completely buffered tables, the number of reads that access the database directly bypassing the buffer is 5 by default. The value is specified in the profile parameter zcsa/inval_reload_c. The buffer is updated afterwards during the read with the data from the database.

• On all other , the buffers are still in the old state. Reads are still performed via the buffer and can potentially access obsolete data. The buffers of this are synchronized using the following asynchronous method:

• A synchronization is performed on every in a specified time interval. The default interval is two minutes. The value is specified in the profile parameter rdisp/bufreftime. The database interface reads the log table DDLOG and invalidates the buffer content in the same way as on the where the original change was made.

• After synchronization, in the case of single record buffering and a change, which only relates to a single record, the buffer is updated via read access. In the case of generic, completely buffered tables, the number of reads that access the database is 5 by default. The buffer is only properly updated afterwards during the next read. The value is specified in the profile parameter zcsa/sync_reload_c.

Notes

• Asynchronous synchronization has the benefit of keeping the network load on the system low, particularly when compared with synchronous methods where each change made to the buffered data of an is broadcast immediately to all other . 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 affects the decision as to whether or not a DDIC database table can be buffered. Tables where many writes are performed are not suited to buffering, since the table 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 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 , 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.

Displacement

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

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

Data is displaced 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 weighted less than those that take place shortly before the displacement. This makes it possible to displace 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 displaced while other generic areas of the same table are kept in the buffer.

Resetting the Buffer

The table buffer of the current 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 table buffer should only be reset if inconsistencies have arisen in the buffer. It can take a long time to fill the table buffer in large systems and this can seriously affect performance.

General Material Data   Vendor Master (General Section)  
This documentation is copyright by SAP AG.

Length: 8088 Date: 20240426 Time: 223659     sap01-206 ( 143 ms )