buffring techniques

[Former Member]

what about the buffring types and what is that functionalty and when we use those three types

[Former Member]

Hi Venu,

Refer to the below related thread

Regards,

Santosh

[Former Member]

Hi

Buffering a table improves the performance when accessing the data records contained in the table.

The table buffers reside locally on each application server in the system. The data of buffered tables can thus be accessed directly from the buffer of the application server. This avoids the time-consuming process of accessing the database.

for more info

http://help.sap.com/saphelp_nw04/helpdata/en/cf/21f244446011d189700000e8322d00/frameset.htm

Regards

shiva

[Former Member]

Hai Veenu ,

Buffering Database Tables

Buffering a table improves the performance when accessing the data records contained in the table.

The table buffers reside locally on each application server in the system. The data of buffered tables can thus be accessed directly from the buffer of the application server. This avoids the time-consuming process of accessing the database.

Buffering is particularly important in client/server environments, as it takes considerably longer to access a table with the network than it does to access a table that is buffered locally. Depending on the network load, this factor can lie between 10 and 100.

The difference in performance is somewhat less marked in central systems (systems with only one application server) than in local ones (systems with several application servers). However, even in central systems, a reduction in process changes and increased sophistication of the buffering over that provided by the database system have a noticeable effect on performance.

How are the Buffers Filled?

If a program accesses the data of a buffered table, the database interface determines whether this data is 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 from the database and loaded into the buffer. The next access to this data can then use the buffer.

The buffering type determines which records are loaded into the buffer during an access.

How are the Local Buffers Synchronized?

A buffered table is generally read on all application servers and held in the buffer there. If a program changes the data contained in the table on an application server, this is noted in the log table by the database interface. The buffers still have the old status on all the other application servers, so that the programs might read obsolete data.

A synchronization mechanism runs at a fixed time interval, usually every 1-2 minutes. The log table is read and the buffer contents that were changed by other servers are invalidated. In the next access, the data of invalidated tables is read directly from the database and updated in the buffer.

Displacement

If more space is required in the buffer due to new data, the data that has not been accessed for the longest time is displaced. The data is displaced asynchronously at certain times that are defined dynamically by the buffer accesses. The data is only displaced if at this time the free space in the buffer is less than a given value or if the access quality is not good enough.

Resetting the Table Buffers

You can reset the table buffers on the corresponding application servers by entering $TAB in the command field. All the data in the buffer is invalidated.

Only use this command if inconsistencies occurred in the buffer! It can take several hours to fill the buffers in large systems. Performance is considerably reduced during this time.

Single-Record Table Buffers

Individual records of tables with single-record buffering are managed in the single-record table buffer TABLP.

Technical Implementation and Buffer Access

The single-record table buffer contains a central administrative structure, a table directory and the data area. The data area is organized in frames of a fixed size (default value 4 KB).

The table names are sorted alphabetically in the directory. The table entries are also stored sorted in the corresponding frames of the data area.

In a buffer access, a binary search is first used to find the entry in the table directory, followed by the corresponding frame and then the record searched for within the frame.

Frames can overflow in the data area if new data is inserted while adhering to the sort sequence. Such overflow frames have to be divided up and their administrative structure must be updated. This explains why the single-record table buffer is somewhat less efficient than the generic/full table buffer. In the single-record table buffer, the data records must be added one after the other while reorganizing the frame structure. In the generic/full buffer, however, all the data of a table is transferred in one step, already sorted by the database.

Managing Non-Existent Records

The single-record buffer also stores information about non-existent records of a table. If you attempt to access the table with a key that is not in the database, this information is stored in the buffer.

This is done with a flag that is added to every record stored in the buffer. The flag shows whether or not this record exists in the table. If you attempt to access a record that does not exist, an empty record is stored in the buffer with the corresponding key, and the flag is set to the value for a non-existent record. If you try to access this record again, the system sees in the buffer that this record does not exist in the database.

Single-record buffering is also recommended if you repeatedly try to access non-existent records of a table.

Displacement

If records of a table with single-record buffering are to be read and stored in the buffer, it might be necessary to remove other records from the buffer for space reasons. In this case, the records of the table that were least recently accessed are removed from the buffer.

Global Synchronization

The modifications made in the local buffers must be synchronized in distributed systems in order to keep the buffered data consistent. The general procedure for synchronization is described in Synchronization of Local Buffers.

The effect of different ABAP commands on the local and global synchronization of the single-record buffer is described below.

If changes are made with WHERE conditions (UPDATE dbtab WHERE ..., DELETE FROM dbtab WHERE ...), the entire table is invalidated in the buffer of the local server (server on which the command was submitted) and on all other servers at the time of the synchronization.

Changes without WHERE conditions (UPDATE dbtab, INSERT dbtab, DELETE dbtab) modify the corresponding records in the buffer of the local server and delete them in the buffers of all the other servers at the time of synchronization.

Modifications with a WHERE condition therefore place a much greater load on buffer management than those without a WHERE condition.

Generic and Full Table Buffers

Generic table areas or full tables are managed in the generic/full table buffer TABL. The individual generic areas are managed in the buffer like autonomous, fully buffered tables.

Technical Implementation and Buffer Access

Like the single-record buffer, the generic/full table buffer has a central administration structure, a table directory and the data area.

The main difference between the generic/full buffer and the single-record buffer lies in the data area administration. The generic/full buffer divides its storage into areas (extents) of variable length. The length of an extent is a multiple of a fixed block size (256 bytes). The buffer management tries to place the contents of a generic table area or a whole table in an extent. This reduces the storage requirements for buffered data in comparison to single-record buffering.

The table names are sorted alphabetically in the table directory. The data records are transferred to the corresponding extent in one step, already sorted by the database. In a buffer access, there is first a binary search for the corresponding table name in the table directory. Then there is a binary search for the corresponding data record in the extent.

Displacement

Unlike with single-record buffering, the displacement for generic/full buffering is carried out asynchronously at certain fixed times. These times are defined dynamically depending on the number of accesses to the buffer. The time between two displacements therefore depends on the buffer utilization factor.

Data is only displaced if the free space in the buffer falls below a defined value or the access quality (that is, the number of accesses that can be satisfied directly from the buffer) is not good enough at the time of access. An attempt is made to free a certain area of the buffer. A larger number of tables is therefore displaced at certain times.

The tables accessed least frequently are displaced. The table accesses are weighted differently, depending on the time of the access. Accesses lying further in the past are weighted less than those that occurred shortly before the displacement.

This method ensures that tables which are accessed frequently at a certain time and then not used again can be displaced from the buffer after a defined time.

The individual generic areas if the buffer of generically buffered tables are treated as independent tables. Some generic areas of a table can therefore be displaced while other generic areas of the table are kept in the buffer.

The buffer is reorganized at certain intervals once the tables have been displaced, thus reducing buffer fragmentation.

Global Synchronization

The modifications made in the local buffers must be synchronized in distributed systems in order to keep the buffered data consistent. The general procedure for synchronization is described in Synchronization of Local Buffers.

The effect of various ABAP commands on the local and global synchronization of the generic/full buffer is described below.

If changes are made with WHERE conditions (UPDATE dbtab WHERE ..., DELETE FROM dbtab WHERE ...), the entire generic area or the entire table is invalidated in the buffer of the local server (server at which the command was submitted) and on all other servers at the time of synchronization.

Changes without WHERE conditions (UPDATE dbtab, INSERT dbtab, DELETE dbtab) change the corresponding records in the buffer of the local server at the time of synchronization. The entire generic area or the entire table is invalidated in the buffers of all the other servers.

Modifications with a WHERE condition therefore place a much greater load on buffer management than those without a WHERE condition.

Regards.

Eshwar.