buffer

[former_member197425]

HI,

Anyone please tell me what is Buffering of tables what is the use of buffering?

[Former Member]

Hi

Hope it will help you,.

Reward if help.

We have 3 types of buffering

There are the following types of buffering:

o single-record buffering

o generic area buffering

o full buffering

Single-record buffering should be selected when :

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.

And also check this matter.

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.

Check this link :

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

[Former Member]

Hi,

Definition

The name table (nametab) contains the table and field definitions that are activated in the SAP System. An entry is made in the Repository buffer when a mass activator or a user (using the ABAP Dictionary, Transaction SE11) requests to activate a table. The corresponding name table is then generated from the information that is managed in the Repository.

The Repository buffer is mainly known as the nametab buffer (NTAB), but it is also known as the ABAP Dictionary buffer

The description of a table in the Repository is distributed among several tables (for field definition, data element definition and domain definition). This information is summarized in the name table. The name table is saved in the following database tables:

• DDNTT (table definitions)

• DDNTF (field descriptions)

The Repository buffer consists of four buffers in shared memory, one for each of the following:

Table definitions TTAB buffer Table DDNTT

Field descriptions FTAB buffer Table DDNTF

Initial record layouts IREC buffer Contains the record layout initialized depending on the field type

THERE R 3 TYPES OF BUFFERING FOR A TABLE:-

1. Full table buffering :- here entire database table buffered to application server.

So further access to same table can be access from application server so, which interm reduces database traffic.

Fullbuffering can only applies to tables which have less data and rarely changed.

Ex-tcodes, company master data like T100, etc

2. single record buffering:- here only one record can buffered to application server by select single…………… with where all key fields can be specified .

Here if no record exists then also no record information stored to application.

Here it applies to database table which is larger in size and modified frequently.

3. Generic buffering:- here few database table records which matches can buffered to application server depends on generic keyfields(key fields specified while setting buffer settings).

So further access to same table can be access from application server so, which inters reduces database traffic.

Full buffering can only applies to tables which have less data and rarely changed.

Ex-tcodes, company master data like T100, etc

process at application server:-

4. if same table can access on multiple application servers then

All of them try to modify that table then it can be noted in DDLOG table with entry.

And their application servers can invoke when they are modifying that table can read the entry in DDLOG table and if found then they refresh that table and reload again.

NOTE:-here select with key fields can be mentioned else buffered tables can re read by next select can not read from buffer area

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.

Could you please have a look at below link which will give details about buffering concept?

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

Reward Points if found helpfull..

Cheers,

Chandra Sekhar.

[Former Member]

We have 3 types of buffering

There are the following types of buffering:

single-record buffering

generic area buffering

full buffering

single-record buffering

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.

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.

generic buffering

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.

he 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.

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 good use of generic buffering (with the language key field as generic key area).

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.

Reward points if useful

[Former Member]

Definition

The name table (nametab) contains the table and field definitions that are activated in the SAP System. An entry is made in the Repository buffer when a mass activator or a user (using the ABAP Dictionary, Transaction SE11) requests to activate a table. The corresponding name table is then generated from the information that is managed in the Repository.

The Repository buffer is mainly known as the nametab buffer (NTAB), but it is also known as the ABAP Dictionary buffer

The description of a table in the Repository is distributed among several tables (for field definition, data element definition and domain definition). This information is summarized in the name table. The name table is saved in the following database tables:

• DDNTT (table definitions)

• DDNTF (field descriptions)

The Repository buffer consists of four buffers in shared memory, one for each of the following:

Table definitions TTAB buffer Table DDNTT

Field descriptions FTAB buffer Table DDNTF

Initial record layouts IREC buffer Contains the record layout initialized depending on the field type

There are two kinds of table buffers:

• Partial table buffers

• Generic table buffers

Check this link for more details.

http://www.abapprogramming.blogspot.com/2007/11/buffering-in-sap-abap.html

Reward if useful.

[Former Member]

Hi,

Use of the buffer has the following benefits:

· Accessing the main memory is a thousand times quicker than accessing the database. Speed is particularly important for applications that assign numbers frequently.

· Database accesses are always subject to the database transaction mechanism. Once an application has assigned a number for one user, a second user cannot assign a number until the first user has executed a commit operation on the database. The application blocks further assignment, and the second user has to wait, until the commit has been executed.

· The number range buffer can also prevent deadlock situations, which may arise from assigning different numbers in a different order.

We have 3 types of buffering

There are the following types of buffering:

single-record buffering

generic area buffering

full buffering

single-record buffering

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.

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.

generic buffering

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.

he 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.

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 good use of generic buffering (with the language key field as generic key area).

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

regards,

vasavi.

kindly reward if helpful.

[Former Member]

Definition

Buffering status

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.

Buffering type

The buffering type defines whether and how the table should be buffered.

There are the following types of buffering:

single-record buffering

generic area buffering

Full buffering

In generic area buffering, a number of key fields between 1 and no. of key fields-1 must be specified.

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 using 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 using SELECT SINGLE, a renewed database access can be avoided.

When should single-record buffering be selected?

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.

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.

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. The client field is included here.

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 that are fully buffered. Refer also to the text on complete 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 for each 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 good use of generic buffering (with the language key field as generic key area).

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.

Regards,

Mayank

[Former Member]

hi,

hope this info will help u,

We have 3 types of buffering

There are the following types of buffering:

o single-record buffering

o generic area buffering

o full buffering

Single-record buffering should be selected when :

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.

And also check this matter.

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.

Check this link :

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

plz reward points if this helped u,

thanx,

nithin