Solved: Buffering???

Former Member · ‎2007 Mar 14

Hi,

what is the purpose of buffering?

Bent.

Former Member · ‎2007 Mar 14

hi .....

If buffering is allowed for a table in the ABAP Dictionary, the SELECT statement always reads the data from the buffer in the database interface of the current application server. To read data directly from the database table instead of from the buffer, use the following:

SELECT ... FROM <tables> BYPASSING BUFFER ...

This addition guarantees that the data you read is the most up to date. However, as a rule, only data that does not change frequently should be buffered, and using the buffer where appropriate improves performance. You should therefore only use this option where really necessary.

with regards

vinayaka

Former Member · ‎2007 Mar 14

Hi,

Performance...you do not have to select anything from database (or any other sources), everything is in memory....

Former Member · ‎2007 Mar 14

We have 3 types of buffering

There are the following types of buffering:

o single-record buffering

o generic area buffering

o full buffering

When should single-record buffering be selected?

o For large tables where there are frequent single-record accesses

(using SELECT SINGLE ...). The size of the records being accessed

should be between 100-200 KB.

o For comparatively small tables for which the access range is large,

it is normally advisable to opt for full buffering. Only one

database access is required to load such a table for full buffering,

while single-record buffering calls for a very large number of table

accesses.

When should generic buffering be selected?

o A table should be buffered generically if usually only certain areas

of the table are required. The individual generic areas are treated

like independent tables that are fully buffered. Refer also to the

text on complete buffering.

o The generic key area should be selected so that the generic areas

are not too small to prevent too may generic areas being produced.

If there are only a few records for each generic area, it is more

efficient to use full buffering.

o Generic buffering only makes sense if the table is accessed by a

specified generic key. If, when an access takes place, a field of

the generic key is not supplied with a value, the buffer is ignored

and the records are read directly from the database.

o Language-specific tables are an example of good use of generic

buffering (with the language key field as generic key area).

When should you select full buffering?

o For tables up to 30 KB in size. If a table is accessed frequently,

but all accesses are read accesses, this value can be exceeded.

o For larger tables where large numbers of records are frequently

accessed. However, if the application program is able to formulate

an extremely selective WHERE condition using a database index, it

may be advisable to dispense with full buffering.

o For tables with frequent accesses to data not contained in the

table. Since all records are contained in the buffer, a quick

decision can be made as to whether or not the table contains a

record for a specific key.

Former Member · ‎2007 Mar 14

Hi,

The buffering type defines which table records are loaded into the buffer of the application server when a table record is accessed. There are the following buffering types:

Full buffering:All the records of the table are loaded into the buffer when one record of the table is accessed.

Full buffering is recommended in the following cases:

Tables up to 30 KB in size. If a table is accessed frequently, but all accesses are read accesses, this value can be exceeded. However, you should always pay attention to the buffer utilization.

Larger tables where large numbers of records are frequently accessed. If these mass accesses can be formulated with a very selective WHERE condition using a database index, it could be better to dispense with buffering.

Tables for which accesses to non-existent records are frequently submitted. Since all the table records reside in the buffer, the system can determine directly in the buffer whether or not a record exists.

Generic buffering: When a record of the table is accessed, all the records having this record in the generic key fields (part of the table key that is left-justified,

identified by specifying a number of key fields) are loaded into the buffer.

A table should be buffered generically if only certain generic areas of the table are normally needed for processing.

Client-specific, fully-buffered tables are automatically generically buffered since normally it is not possible to work in all clients at the same time on an application server. The client field is the generic key.

Language-specific tables are another example where generic buffering is recommended. In general, only records of one language will be needed on an application server. In this case, the generic key includes all the key fields up to and including the language field.

It only makes sense to generically buffer a table if the table is accessed with fully-specified generic key fields. If a field of the generic key is not assigned a value in a SELECT statement, it is read directly from the database, bypassing the buffer.

If you access a generic area that is not in the buffer with a fully-specified generic key, you will access the database to load the area. If the table does not contain any records in the specified area ("No record found"), this area in the buffer is marked as non-existent. It is not necessary to access the database if this area is needed again.

Single-record buffering: Only the records of a table that are really accessed are loaded into the buffer

Single-record buffering should be used particularly for large tables where only a few records are accessed with SELECT SINGLE. The size of the records being accessed should be between 100 and 200 KB.

Full buffering is usually more suitable for smaller tables that are accessed frequently. This is because only one database access is necessary to load such a table with full buffering, whereas several database accesses are necessary for single-record buffering.

I think this will be helpful for u.

Regards,

Ravi Kumar

Former Member · ‎2007 Mar 14

hi

good

go through this link

http://help.sap.com/saphelp_nw04/helpdata/en/f7/e4c5a8a84a11d194eb00a0c929b3c3/content.htm

thanks

mrutyun^

amol_chaudhari5 · ‎2007 Mar 14

Hello Kishor,

The basic purpose of buffer is to store data which might be needed in currently

executing program.

Buffer are maintained at each table level.

When you fetch some data from any table all that data that you are requiring plus all records (based on how buffer is maintained ) from that table are fetched in to the buffer. So when next time you try to query on same table then system first checks in Buffer for same.

So to reduce direct database transaction buffers are introduced.

Regards

Amol C.

*--- If this solves your purpose then don't forget to add points.

Former Member · ‎2007 Mar 14

hi,

the purpose of buffering is to increase the performance when the records of the table are read.

It is nothing but ,like a cache in a computer ..when ever we need to fetch a records of a table number of imes we need not go for data base instead it can be fetched from buffer itself..

The more frequently a table is read and te less ferquently the table contents are changed ,the better it is to buffer the table..

Former Member · ‎2007 Mar 14

use buffering to improve system performance.

Local buffering of data in the shared memory of the application server reduces the number of database reads required. This reduces access times for application programs considerably. For optimal use of the buffer, you can concentrate individual applications (financial accounting, logistics, human resources) into separate application server groups.

When buffering the database, you must remember that data in the buffer is

not always up to date. For this reason, you should only use the buffer for data which does not

often change.

with regards

vinayaka

Former Member · ‎2007 Mar 14

hi .....

If buffering is allowed for a table in the ABAP Dictionary, the SELECT statement always reads the data from the buffer in the database interface of the current application server. To read data directly from the database table instead of from the buffer, use the following:

SELECT ... FROM <tables> BYPASSING BUFFER ...

This addition guarantees that the data you read is the most up to date. However, as a rule, only data that does not change frequently should be buffered, and using the buffer where appropriate improves performance. You should therefore only use this option where really necessary.

with regards

vinayaka

Former Member · ‎2007 Mar 16

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.

See also:

Example for Buffer Synchronization

The following example shows how the local buffers of the system are synchronized. We have a system with two application servers, called Server1 and Server2.

Initial situation: Neither server has yet accessed records of the fully buffered table TAB. The local buffers of both servers do not yet contain the records of the table.

Event 1: Server 1 reads records from table TAB in the database.

Event 2: Table TAB is completely loaded into the local buffer of Server 1. Accesses by Server 1 to the data of table TAB now use the local buffer of this server.

Event 3: Server 2 accesses records of the table. Since the table is not yet in the local buffer of Server 2, the records are read directly from the database.

Event 4: Table TAB is completely loaded into the local buffer of Server 2. Server 2 then also accesses the data in TAB using its local buffer the next time it reads.

Event 5: Server 1 deletes records from table TAB and updates the database.

Event 6: Server 1 writes an entry in the synchronization table.

Event 7: Server 1 updates its local buffer.

Event 8: Server 2 accesses the deleted data records. Since table TAB is in its local buffer, access uses this local buffer.

Server 2 therefore finds the records, although they are no longer in the database table!

If the same access were executed from an application program on Server 1, this program would see that the records no longer exist. The behavior of an application program at this time therefore depends on the server on which it is executing!

Event 9: It is now time for synchronization. Both servers check the synchronization table to find out whether one of the tables in its local buffer has been changed in the meantime.

Event 10: Server 2 finds that table TAB was modified by Server 1 in the meantime. Server 2 therefore invalidates the table in its local buffer. The next time Server 2 accesses the data in table TAB, it therefore uses the database. Server 1 does not have to invalidate the table in its buffer because it alone changed table TAB. Server 1 therefore uses its local buffer the next time it accesses records of table TAB.

Event 11: Server 2 again accesses records of table TAB. Because TAB was invalidated in the local buffer of Server 2, access uses the database.

Event 12: The table is again loaded into the local buffer of Server 2. The information about table TAB is now consistent for both servers and the database.

Which Tables should be Buffered?

Only transparent tables and pooled tables can be buffered. Cluster tables cannot be buffered.

Character data types must be assigned to all key fields of buffered tables, that is the data type of the field must be mapped to one of the ABAP types C, N, D or T (see Mapping to ABAP Data Types).

The following two points speak against table buffering:

The data read by the application must always be up-to-date. Delays caused by the synchronization mechanism (see Synchronization of Local Buffers) cannot be accepted.

The table data is frequently modified. In this case the cost of synchronization could be greater than the gain in performance resulting from buffering. Roughly speaking, it does not make sense to buffer a table if more than one percent of the accesses to the table are modifying accesses.

The table containing currency exchange rates is updated only once a day, but it is read frequently. Buffering is recommended in this case.

Typical candidates for buffering include customizing and system tables. In certain cases master data with customizing character can also be buffered.

The contents of buffered tables are not always up-to-date in a distributed system. You can bypass the buffer and read the data directly from the database table with the ABAP command "SELECT SINGLE ... BYPASSING BUFFER". If a buffered table is accessed frequently with this command, you should consider whether it is really necessary for the table to be buffered or whether it is essential to have the current state of the database.

You must define whether and how a table is buffered in its technical settings (see Technical Settings

Which Accesses Proceed Directly to the Database?

When programming accesses to buffered tables it is important to know which accesses read from the buffer and which accesses go directly to the database.

The following accesses always bypass the buffer and proceed directly to the database:

SELECT... BYPASSING BUFFER

SELECT FOR UPDATE

SELECT with aggregate function, for example COUNT, MIN, MAX, SUM, AVG

SELECT DISTINCT

SELECT... WHERE… IS NULL

ORDER BY (with the exception of PRIMARY KEY)

With generic buffering, all SELECT statements that do not fully specify the generic key also proceed directly to the database. Therefore, with generic buffering the buffer can only be used for accesses that specify the complete generic key.

With single-record buffering, each SELECT statement without the suffix SINGLE also proceeds directly to the database. This applies even if the complete key is specified in the SELECT statement. In single-record buffering, therefore, the buffer can be used only for accesses with SELECT SINGLE.

Of course, all accesses with Native SQL (EXEC SQL) also bypass the buffer and proceed directly to the database. Such accesses should be avoided at all costs with buffered tables. First of all, read accesses always bypass the table buffers. Secondly, the R/3 System does not notice modifying accesses since no entries are made in the synchronization table here (see Synchronization of Local Buffers). This can lead to inconsistencies between the data in the buffers of the application server and the database.

How are Table Buffers Implemented Technically?

The table buffers lie in shared memory. There is a single-record table buffer TABLP and a generic/full table buffer TABL. The two table buffers differ primarily in how they manage free storage areas and in their displacement mechanisms.

Detailed information on the technical buffer structure, especially on the structure, access mechanism, displacement behavior, and global synchronization in distributed systems can be found in:

Single-Record Table Buffers

Generic and Full Table Buffers

Message was edited by:

sunil kumar

Former Member · ‎2007 Mar 16

Hi Kishor,

Check this documentation.

We have 3 types of buffering

There are the following types of buffering:

o single-record buffering

o generic area buffering

o full buffering

When should single-record buffering be selected?

o For large tables where there are frequent single-record accesses (using SELECT SINGLE ...). The size of the records being accessed should be between 100-200 KB.

o For comparatively small tables for which the access range is large, it is normally advisable to opt for full buffering. Only one database access is required to load such a table for full buffering,

while single-record buffering calls for a very large number of table accesses.

When should generic buffering be selected?

o A table should be buffered generically if usually only certain areas of the table are required. The individual generic areas are treated like independent tables that are fully buffered. Refer also to the text on complete buffering.

o The generic key area should be selected so that the generic areas are not too small to prevent too may generic areas being produced. If there are only a few records for each generic area, it is more efficient to use full buffering.

o Generic buffering only makes sense if the table is accessed by a specified generic key. If, when an access takes place, a field of the generic key is not supplied with a value, the buffer is ignored

and the records are read directly from the database.

o Language-specific tables are an example of good use of generic buffering (with the language key field as generic key area).

When should you select full buffering?

o For tables up to 30 KB in size. If a table is accessed frequently, but all accesses are read accesses, this value can be exceeded.

o For larger tables where large numbers of records are frequently accessed. However, if the application program is able to formulate an extremely selective WHERE condition using a database index, it may be advisable to dispense with full buffering.

o For tables with frequent accesses to data not contained in the table. Since all records are contained in the buffer, a quick decision can be made as to whether or not the table contains a