topic Re: about table buffering in Application Development and Automation Discussions

about table buffering

Former Member — Mon, 13 Aug 2007 05:17:18 GMT

hi experts,

Explain me what is table buffering.why we have to use this concept ?and under which circumstances we need to use this concept.and if not what will be the consequences.

ragards,

mani

Re: about table buffering

seshatalpasai_madala — Mon, 13 Aug 2007 05:21:52 GMT

Hi,

Table buffering is a concept used to Buffer the Table entries on the application server.

So the Database queries can be addressed using the Table buffer instead from the Database.

That is we can avoid hitting the Database server.

<b>BUT We have to be very careful when we decide on which table to buffer and how we buffer it.</b>

We should not buffer any table which is modified very often. We can buffer something like Master tables which will not be modified often.

You maintain table buffering settings in SE11 under Technical Settings for the table.

<b>Here is the documentatio for buffering in SE11.</b>

The buffering status specifies whether or not a table may be buffered.

This depends on how the table is used, for example on the expected volume of data in the table or on the type of access to a table. (mainly read or mainly write access to the table. In the latter case, for example, one would not select buffering).

You should therefore select

- Buffering not allowed if a table may not be buffered.

- Buffering allowed but not activated if buffering is

principally allowed for a table, but at the moment no buffering

should be active. The

buffering type specified in this case is only

a suggestion.

- Buffering allowed if the table should be buffered. In this

case a buffering type

must be specified.

Regards,

Sesh

Re: about table buffering

Former Member — Mon, 13 Aug 2007 05:27:42 GMT

hi,

You get the same in SAP help, but i dont know the link..

SAP Buffering

The SAP database interface enables storage of database tables in local buffers, i.e. the buffers reside locally on each application server of the system. Buffering is especially important in a client/server environment because the access time using the network is much greater than the access time to a locally buffered table.

The flag Buffering allowed must be set in the ABAP/4 Dictionary in order that a table be buffered. The buffering type must also be maintained in the technical settings of the table. Setting the flag Buffering allowed alone does not cause the tables to be buffered!

Whether or not it makes sense to buffer a table depends on the type of access to the table.

The buffering type defines how the table should be buffered.

There are the following 3 buffering types:

X full buffering

P single record (partial) buffering

G generic buffering

no entry no buffering

A number of key fields between 1 and number of key fields -1 must be defined for generic buffering.

X full buffering

Full buffering

With full buffering, either the complete table or none of the table is in the buffer. If a read access is made to a record, all records of the table are transferred to the buffer.

When should you select full buffering?

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.

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.

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.

When considering whether a table should be fully buffered, you should take three aspects into account: the size of the table, the number of read accesses, and the number of write accesses. Tables best suited to full buffering are small, frequently read, and rarely updated.

P single record (partial) buffering

Single-record buffering

With this kind of buffering, only the records of a table which are actually accessed are loaded into the buffer.

This kind of buffering requires less storage space in the buffer than full buffering. However, greater organization is necessary and considerably more database accesses are necessary for loading.

If an as yet unbuffered record is accessed with SELECT SINGLE, a database access occurs to load the record. If the table does not contain a record for the specified key ('no record found'), this record is noted as nonexistent in the buffer. If a further attempt is made to access this record, a renewed database access can be avoided.

When should single-record buffering be selected?

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

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, whilst single-record buffering calls for a very large number of table accesses.

Generic buffering

In a read access to a record of a generically buffered table, all the records whose left-justified part of the key (generic area) corresponds are loaded into the buffer.

If this type of buffering is selected, the generic area must be defined by specifying a number n of key fields. The first n key fields of the table then define the generic key.

The number of key fields to be entered must lie between 1 and the number of key fields -1. For example, only values between 1 and 5 are permitted for a table with 6 key fields.

When should generic buffering be selected?

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 which are fully buffered. Please also read the text about full buffering.

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 per generic area, it is more efficient to use full buffering.

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.

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

Bypassing Buffer is related to the buffering settings in the technical

details of a database table. These table buffers are available on every

application server. SELECT statements on a buffered table use this table

buffer in stead of processing the SQL request on the database. As a

result, using table buffering leads to performance improvements, but

only if:

- the buffered table is small

- the contents of the table doesn't change often.

SAP uses table buffering for a lot of their customizing table.

Bypassing Buffer means: skip the table buffer on the application server

and process the sql-request on the database.

The table buffers are automatically synchronized with changes in the

database. However, it takes some time for the database updated to be

available in the table buffer. So if you want to be 100% sure that the

data you read is up to date, you must use the option BYPASSING BUFFER.

Please note that there are also SQL statements that implicitely perform

a BYPASSING BUFFER, for example when using a table in a JOIN statement.

regards,

Prabhu

reward if it is helpful.

Re: about table buffering

Former Member — Mon, 13 Aug 2007 05:39:19 GMT

Hi,

buffering concept is for speed up of your program's database request for retriving the data from the database for frequently read data. I mean if you frequently read a database table and that table has been optioned by the buffering concept (you can check it in the technical settings-> buffering concept-> buffering switched on) which will store all the data in the application server in RAM. next time if you program try to access the same data the database request wont go to the dabase level and will pick up the data from the buffer in the application server.

Note: the main advantage of buffering concept is for speed up of your application and reduce the network traffic in the server level.

there are 3 types of buffering concepts:

1. single record buffering: for frequently readed single records works with select single * only.

2. generic buffering: for frequently readed a group of fields in the table work with select/endselect.

like select field1 field2 .....endselect.

3. full buffering: for entire table and work with select/endselect.....

select * from ....endselect.

award points helpful

sekhar