If you have landed to this page to know about buffers and you just have one minute, then just go through the first four headings (Types, Decide, When, Why). It should be sufficient to hint you what buffering is.
Types of buffering?
There are three types of buffering which is a function of “n” keys fields as:
1) Full buffering: n = 0 (Where clause independent)
2) Generic buffering: 0 < n < number of key fields (Where clause with few keys)
3) Single record buffering: n = number of key fields (Where clause with all primary keys)
The above diagram depicts that the time taken for DB access ~ 10 ms.
Time take for access from buffered application server ~ 0.1 ms
Performance of buffered application server ~ 100/0.1 ~ 100 times
a) The work processes on the application server encounters shorter wait times because of buffering, which means table buffering reduces the load on the entire SAP system.
b) Table buffering increases the performance when the records of the table are read. The records of a buffered table are read directly from the local buffer of the application server on which the accessing transaction is running when the table is accessed. This eliminates time-consuming database accesses. The access improves by a factor of 10 to 100. The increase in speed depends on the structure of the table and on the exact system configuration. Buffering, therefore, can greatly increase the system performance.
For those folks, who can spare some more time, please continue.
Records in the table buffer are saved sorted by the primary index.
We cannot use secondary indexes to access the buffered tables. Entering $TAB in the command field resets the table buffers on the corresponding application server. Only use this command if there are inconsistencies in the buffer. In large systems, it can take several hours to fill the buffers. The performance is considerably reduced during this time.
The buffer and database is synced at the pre-decided interval.The system parameter for the synchronization interval is rdisp/bufreftime, which specifies the length of the interval in seconds. This value must lie between 60 and 3600 (recommend setting: between 60 and 240). The buffering type determines which records of the table are loaded into the buffer of the application server when a record of the table is accessed.
1) Full buffering
The first time the table is accessed, the entire table is loaded into the table buffer (generic table buffer). All subsequent accesses of the table can be served from the table buffer.Full buffering is recommended for small tables, which are frequently read but rarely written in.
2) Generic buffering
If you want to buffer a table generically, you first have to define the generic area. The generic area is defined by the first “n” key fields of the table.If an SQL statement is executed for a generically buffered table, with a specific instantiation of the generic area (such as SELECT * FROM TAB1 WHERE KEY1 = ‘002’ or SELECT * FROM TAB2 WHERE KEY1 = ‘002’ AND KEY2 = ‘A’), the corresponding records are loaded into the table buffer. All subsequent accesses with the same instantiation can be served from the table buffer.
3) Single record buffering
Only single records are read from the database and loaded into the table buffer (single record buffer).Note that SELECT SINGLE has to be used, however; a SELECT loop would bypass the buffer.Each buffering type can be considered to be a variant of Generic buffering with “n” key fields:
Full buffering: n = 0
Generic buffering: 0 < n < number of key fields
Single record buffering: n = number of key fields
With full buffering, the table is either completely or not at all in the buffer. When a record of the table is accessed, all the records of the table are loaded into the buffer.
Only those records that are actually accessed are loaded into the buffer.
When you decide whether a table should be fully buffered, you must take the table size, the number of read accesses and the number of write accesses into consideration. The smaller the table is, the more frequently it is read and the less frequently it is written, the better it is to fully buffer the table.Full buffering is also advisable for tables that have frequent accesses to records that do not exist. Since all the records of the table reside in the buffer, it is already clear in the buffer whether or not a record exists.The data records are stored in the buffer sorted by table key. When you access the data with SELECT, only fields up to the last specified key field can be used for the access. The left-justified part of the key should therefore be as large as possible for such accesses. For example, if the first key field is not defined, the entire table is scanned in the buffer. Under these circumstances, a direct access to the database could be more efficient if there is a suitable secondary index there.Generic Buffering:
A table should be generically buffered if only certain generic areas of the table are usually needed for processing.Client-dependent, fully buffered tables are automatically generically buffered. The client field is the generic key. It is assumed that not all of the clients are being processed at the same time on one application server. Language-dependent tables are a further example of generic buffering. The generic key includes all the key fields up to and including the language field.
Single Record Buffering:
Single-record buffering saves storage space in the buffer compared to generic and full buffering. The overhead for buffer administration, however, is higher than for generic or full buffering. Considerably more database accesses are necessary to load the records than for the other buffering types.Single-record buffering is recommended particularly for large tables in which only a few records are accessed repeatedly with SELECT SINGLE. All the accesses to the table that do not use SELECT SINGLE bypass the buffer and directly access the database.If you access a record that was not yet buffered using SELECT SINGLE, there is a database access to load the record. If the table does not contain a record with the specified key, this record is recorded in the buffer as non-existent. This prevents a further database access if you make another access with the same key.You only need one database access to load a table with full buffering, but you need several database accesses with single-record buffering. Full buffering is therefore generally preferable for small tables that are frequently accessed.
The R/3 System manages and synchronizes the buffers on the individual application servers. If an application program accesses data of a table, the database interfaces determines whether this data lies in the buffer of the application server. If this is the case, the data is read directly from the buffer. If the data is not in the buffer of the application server, it is read directly from the database and loaded into the buffer. The buffer can therefore satisfy the next access to this data.Since the buffers reside locally on the application servers, they must be synchronized after data has been modified in a buffered table. Synchronization takes place at fixed time intervals that can be set in the system profile. The corresponding parameter is rdisp/bufreftime and defines the length of the interval in seconds.
The value must lie between 60 and 3600. Recommended value is between 60 and 240.
An example to show Buffer Synchronization.
Say a system with two application server is going to select data from T005.
Say a system with two application server is going to select data from T005.
Starting situation: Neither server has yet accessed records of the table T005 to be fully buffered. The table therefore does not yet reside in the local buffers of the two servers.
Timepoint 1: Server 1 reads records from table T005 on the database.
Timepoint 2: Table T005 is fully loaded into the local buffer of Server
The local buffer of this server is now used for access from Server 1 to the data of the T005 table.
Timepoint 3: A user on Server 2 accesses records of the same table. Since the table does not yet reside in the local buffer of Server 2, the records are read directly from the database.
Timepoint 4: The T005 table is loaded into the local buffer of Server 2. Server 2 therefore also uses its local buffer to access its data when it next reads the T005 table.
Timepoint 5: A user on Server 1 deletes records from the T005 table and updates the database.
Timepoint 6: Server 1 writes an entry in the synchronization table.
Timepoint 7: Server 1 updates its local buffer.
Timepoint 8: A user on Server 2 accesses the deleted records. Since the T005 table resides in its local buffer, the access uses this local buffer.
Server 2 therefore finds the records although they no longer exist in the database table.
If the same access were made from an application program to Server 1, this program would recognize that the records no longer exist. At this time the behavior of an application program depends on the server on which it is running.
Timepoint 9: The moment of synchronization has arrived. Both servers look in the synchronization table to see if another server has modified one of the tables in its local buffer in the meantime.
Timepoint 10: Server 2 finds that the T005 table has been modified by Server 1 in the meantime. Server 2 therefore invalidates the table in its local buffer. The next access from Server 2 to data of the T005 table therefore uses the database. Server 1 must not invalidate the table in its buffer, as it is the only changer of the T005 table itself. Server 1 therefore uses its local buffer again the next time to access records of T005 table.
Timepoint 11: Server 2 again accesses records of T005 table. Since T005 is invalidated in the local buffer of Server 2, the access uses the database.
Timepoint 12: The table is reloaded into the local buffer of Server 2. The information via the T005 table is now consistent again on the servers and the database.
Advantages and disadvantages of this method of buffer synchronization:
Advantage: The load on the network is kept to a minimum. If the buffers were to be synchronized immediately after each modification, each server would have to inform all other servers about each modification to a buffered table via the network. This would have a negative effect on the performance.
Disadvantage: The local buffers of the application servers can contain obsolete data between the moments of synchronization.
Only those tables that are written very infrequently (read mostly) or for which such temporary inconsistencies are of no importance may be buffered.
Tables whose entries change frequently should not be buffered. Otherwise there would be a constant invalidation and reload, which would have a negative effect on the performance.
*reference BC430, BC402
Image source : blogs.msdn.com