what is buffer? how many types of buffers r there?

[Former Member]

how many types of joins r there?

thank u.

[Former Member]

Reducing the Database Load

Unlike application servers and presentation servers, there is only one database server in your system. You should therefore aim to reduce the database load as much as possible. You can use the following methods:

Buffer Tables on the Application Server

You can considerably reduce the time required to access data by buffering it in the application server table buffer. Reading a single entry from table T001 can take between 8 and 600 milliseconds, while reading it from the table buffer takes 0.2 - 1 milliseconds.

Whether a table can be buffered or not depends its technical attributes in the ABAP Dictionary. There are three buffering types:

· Resident buffering (100%): The first time the table is accessed, its entire contents are loaded into the table buffer.

· Generic buffering: In this case, you need to specify a generic key (some of the key fields) in the technical settings of the table in the ABAP Dictionary. The table contents are then divided into generic areas. When you access data with one of the generic keys, the whole generic area is loaded into the table buffer. Client-specific tables are often buffered generically by client.

· Partial buffering (single record): Only single entries are read from the database and stored in the table buffer.

When you read from buffered tables, the following happens:

...

1. An ABAP program requests data from a buffered table.

2. The ABAP processor interprets the Open SQL statement. If the table is defined as a buffered table in the ABAP Dictionary, the ABAP processor checks in the local buffer on the application server to see if the table (or part of it) has already been buffered.

3. If the table has not yet been buffered, the request is passed on to the database. If the data exists in the buffer, it is sent to the program.

4. The database server passes the data to the application server, which places it in the table buffer.

5. The data is passed to the program.

When you change a buffered table, the following happens:

...

1. The database table is changed and the buffer on the application server is updated. The database interface logs the update statement in the table DDLOG. If the system has more than one application server, the buffer on the other servers is not updated at once.

2. All application servers periodically read the contents of table DDLOG, and delete the corresponding contents from their buffers where necessary. The granularity depends on the buffering type. The table buffers in a distributed system are generally synchronized every 60 seconds (parameter: rsdisp/bufreftime).

3. Within this period, users on non-synchronized application servers will read old data. The data is not recognized as obsolete until the next buffer synchronization. The next time it is accessed, it is re-read from the database.

You should buffer the following types of tables:

· Tables that are read very frequently

· Tables that are rarely changed

· Relatively small tables (few lines, few columns, or short columns)

· Tables where it is acceptable for changes to the data to not be immediately visible on all application servers.

Once you have buffered a table, take care not to use any Open SQL statements that bypass the buffer.

The SELECT statements bypass the buffer:

· The BYPASSING BUFFER addition in the FROM clause

· The DISTINCTaddition in the SELECT clause

· Aggregate expressions in the SELECT clause

· Joins in the FROM clause

· The IS NULLcondition in the WHERE clause

· Subqueries in the WHERE clause

· The ORDER BY clause

· The GROUP BY clause

· The FOR UPDATEaddition

Furthermore, all Native SQL statements bypass the buffer.

Avoid Reading Data Repeatedly

If you avoid reading the same data repeatedly, you both reduce the number of database accesses and reduce the load on the database. Furthermore, a “dirty read” may occur with database tables other than Oracle. This means that the second time you read data from a database table, it may be different from the data read the first time. To ensure that the data in your program is consistent, you should read it once only and then store it in an internal table.

Sort Data in Your ABAP Program

The ORDER BY clause in the SELECTstatement is not necessarily optimized by the database system or executed with the correct index. This can result in increased runtime costs. You should only use ORDER BY if the database sort uses the same index with which the table is read. To find out which index the system uses, use SQL Trace in the ABAP Workbench Performance Trace. If the indexes are not the same, it is more efficient to read the data into an internal table or extract and sort it in the ABAP program using the SORTstatement.

Use Logical Databases

SAP supplies logical databases for all applications. A logical database is an ABAP program that decouples Open SQL statements from application programs. They are optimized for the best possible database performance. However, it is important that you use the right logical database. The hierarchy of the data you want to read must reflect the structure of the logical database. Otherwise, performance might be adversely affected. For example, if you want to read data from a table right at the bottom of the hierarchy of the logical database, it has to read at least the key fields of all tables above it in the hierarchy. In this case, it is more efficient to use a SELECT statement

[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

Regards,

[Former Member]

Whenever an Open SQL statement is used to read a record,

the data buffer is checked first to see whether it is there. If not, the data is read from the database.

If the table's attributes indicate that the data should be buffered,

the record is saved in RAM on the application server in data buffers.

Later, if that record is read again, it is read from the buffer instead of the database.

By buffering data, you increase performance in two important ways:

The programs using the buffered data run faster because they don't have to wait for it to come from the database. This reduces delays waiting for the database and the network that connects it.

The other programs that need to access the database run faster because there is less load on the database and less traffic on the network.

Three types of buffering are possible:

Full buffering

Generic buffering

Single-record buffering

Although you use a check box to indicate the buffering type, only one type can be selected at a time. If you choose more than one, an error message will be displayed.

There are two data buffers on each application server, and the buffering type chosen determines which buffer is used. On an application sever there are:

The generic record buffer

The single-record buffer

The generic record buffer is called TABL (short for "table"). The single-record buffer is TABLP ("P"' stands for "partial").

Full Buffering:

To activate the full buffering type, tickmark the Full check box.

When an attempt is made to read data from a fully buffered table,

the system looks in the TABL buffer for it.

If it is not found there, all rows are loaded from the database into TABL .

This happens whenever a select statement for it is executed, no matter how many records match the where clause.

Even if no records match, all are loaded into the buffer if the table is not already there or

if it has been invalidated due to buffer synchronization.

Loading of TABL does not occur with select single statements; only select/ endselect does this.

If the table is fully buffered and a select single statement is executed, no records are loaded into TABL.

However, if the table is already loaded into TABL, select single will read records from it.

During buffer synchronization, the entire table is invalidated if any record within it changes. The next time data is read the entire table is reloaded.

Full buffering is appropriate for small tables that seldom change.

Generic Buffering:

With generic buffering, a group of records is loaded into TABL instead of the entire table.

To activate this type of buffering, tickmark the Generic check box

and put a number n in the No. of Key Fields so that the n left-most fields of the primary key will group records.

When a record is read and n is 1, all records having the same value

in the first field of the primary key are loaded into the buffer.

When a record is read and n is 2, all records having the same value in the first two fields of the primary key are loaded

into the buffer.

Generic buffering is suitable for tables in which records are usually accessed in sets or groups.

Single Record Buffering:

With this type of buffering, select single picks one record into the single record buffer TABLP.

With this buffering type, records are only buffered when the select single statement is executed.

Select/endselect does not load or read TABLP.

Single-record buffering is appropriate for very large tables in which a small percentage of the records are read often.

For single-record buffering to work, records must be read using the select single statement.

There are two buffers: TABL (the generic record buffer) and TABLP (the single record buffer).

There are also two varieties of the select statement: select and select single. The select statement loads TABL and the select single statement loads TABLP.

When reading, select only reads TABL; it ignores TABLP. select single reads both buffers. This behavior is summarized in Figure 5.20. Remember that a record can only be in one buffer at a time because a table can only have one buffering type.

Regards,

[Former Member]

Whenever an Open SQL statement is used to read a record,

the data buffer is checked first to see whether it is there. If not, the data is read from the database.

If the table's attributes indicate that the data should be buffered,

the record is saved in RAM on the application server in data buffers.

Later, if that record is read again, it is read from the buffer instead of the database.

By buffering data, you increase performance in two important ways:

The programs using the buffered data run faster because they don't have to wait for it to come from the database. This reduces delays waiting for the database and the network that connects it.

The other programs that need to access the database run faster because there is less load on the database and less traffic on the network.

Three types of buffering are possible:

Full buffering

Generic buffering

Single-record buffering

Although you use a check box to indicate the buffering type, only one type can be selected at a time. If you choose more than one, an error message will be displayed.

There are two data buffers on each application server, and the buffering type chosen determines which buffer is used. On an application sever there are:

The generic record buffer

The single-record buffer

The generic record buffer is called TABL (short for "table"). The single-record buffer is TABLP ("P"' stands for "partial").

Full Buffering:

To activate the full buffering type, tickmark the Full check box.

When an attempt is made to read data from a fully buffered table,

the system looks in the TABL buffer for it.

If it is not found there, all rows are loaded from the database into TABL .

This happens whenever a select statement for it is executed, no matter how many records match the where clause.

Even if no records match, all are loaded into the buffer if the table is not already there or

if it has been invalidated due to buffer synchronization.

Loading of TABL does not occur with select single statements; only select/ endselect does this.

If the table is fully buffered and a select single statement is executed, no records are loaded into TABL.

However, if the table is already loaded into TABL, select single will read records from it.

During buffer synchronization, the entire table is invalidated if any record within it changes. The next time data is read the entire table is reloaded.

Full buffering is appropriate for small tables that seldom change.

Generic Buffering:

With generic buffering, a group of records is loaded into TABL instead of the entire table.

To activate this type of buffering, tickmark the Generic check box

and put a number n in the No. of Key Fields so that the n left-most fields of the primary key will group records.

When a record is read and n is 1, all records having the same value

in the first field of the primary key are loaded into the buffer.

When a record is read and n is 2, all records having the same value in the first two fields of the primary key are loaded

into the buffer.

Generic buffering is suitable for tables in which records are usually accessed in sets or groups.

Single Record Buffering:

With this type of buffering, select single picks one record into the single record buffer TABLP.

With this buffering type, records are only buffered when the select single statement is executed.

Select/endselect does not load or read TABLP.

Single-record buffering is appropriate for very large tables in which a small percentage of the records are read often.

For single-record buffering to work, records must be read using the select single statement.

There are two buffers: TABL (the generic record buffer) and TABLP (the single record buffer).

There are also two varieties of the select statement: select and select single. The select statement loads TABL and the select single statement loads TABLP.

When reading, select only reads TABL; it ignores TABLP. select single reads both buffers. This behavior is summarized in Figure 5.20. Remember that a record can only be in one buffer at a time because a table can only have one buffering type.

[Former Member]

Whenever an Open SQL statement is used to read a record,

the data buffer is checked first to see whether it is there. If not, the data is read from the database.

If the table's attributes indicate that the data should be buffered,

the record is saved in RAM on the application server in data buffers.

Later, if that record is read again, it is read from the buffer instead of the database.

By buffering data, you increase performance in two important ways:

The programs using the buffered data run faster because they don't have to wait for it to come from the database. This reduces delays waiting for the database and the network that connects it.

The other programs that need to access the database run faster because there is less load on the database and less traffic on the network.

Three types of buffering are possible:

Full Buffering

With full buffering, either the entire table is in the buffer or the table is not in the buffer at all. All

the records of the table are loaded into the buffer when one record of the table is read.

In this example, a program reads the record highlighted in red from table

SCOUNTER. If the table is fully buffered, all the records of the table are loaded into

the buffer.

Application server

The buffered data records are sorted in the buffer by table key. Accesses to the

buffered data can therefore only analyze field contents up to the last specified key

field for restricting the dataset to be searched.

The left-justified part of the key should therefore be as large as possible in such

accesses. For example, if you do not define the first key field, the system has to scan

the full table. In this case direct access to the database can be more efficient if the

database has suitable secondary indexes [Page 61].

When Should you Use Full Buffering?

When deciding whether a table should be fully buffered, you should take 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, read frequently, and rarely written.

Full buffering is recommended in the following cases:

BC - ABAP Dictionary SAP AG

Full Buffering

36 December 1999

• 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 [Page 61], 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.

SAP AG BC - ABAP Dictionary

Generic Buffering

With generic buffering, all the records in the buffer whose generic key fields match this record are

loaded when one record of the table is accessed. The generic key is a part of the primary key of

the table that is left-justified.

In this example, the record highlighted in red is read by a program from table

SCOUNTER. If the table is generically buffered, all the records read whose generic

key fields (MANDT and CARRID) agree are loaded into the buffer.

Application server

When Should you Use Full Buffering?

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.

How Should you Define the Generic Key?

In generic buffering, it is crucial to define a suitable generic key.

BC - ABAP Dictionary SAP AG

Generic Buffering

If the generic key is too small, the buffer will contain a few very large areas. During access, too

much data might be loaded in the buffer.

If the generic key is too large, the buffer might contain too many small generic areas. These can

reduce buffer performance since there is an administrative entry for every buffered generic area.

It is also possible that too many accesses will bypass the buffer and go directly to the database,

since they do not fully define the generic key of the table. If there are only a few records in each

generic area, it is usually better to fully buffer the table.

Only 64 bytes of the generic key are used. You can specify a longer generic key, but the part of

the key exceeding 64 bytes is not used to create the generic areas.

Access to Buffered Data

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.

SAP AG BC - ABAP Dictionary

Single-Record Buffering

With single-record buffering, only the records that are actually read are loaded into the buffer.

Single-record buffering therefore requires less storage space in the buffer than generic and full

buffering. The administrative costs in the buffer, however, are greater than for generic or full

buffering. Considerably more database accesses are necessary to load the records than for the

other buffering types.

In this example, the record highlighted in red is read by a program from table

SCOUNTER. If single-record buffering is selected for the table, only the record that

was read is loaded into the buffer.

When Should you Use Single-Record Buffering?

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.

Access to Buffered Data

All accesses that are not submitted with SELECT SINGLE go directly to the database, bypassing

the buffer. This applies even if the complete key is specified in the SELECT statement.

BC - ABAP Dictionary SAP AG

Single-Record Buffering

40 December 1999

If you access a record which is not yet buffered with SELECT SINGLE, there is a database

access to load the record. This record is marked in the buffer as non-existent if the table does not

contain a record with the specified key.

[prasanth_kasturi]

Buffer is a temporary storage area in the RAM r application server where we can place the information required . its used to reduce network traffic and faster acces of data

Whenever an Open SQL statement is used to read a record, the data buffer is checked first to see whether it is there. If not, the data is read from the database. If the table's attributes indicate that the data should be buffered, the record is saved in RAM on the application server in data buffers. Later, if that record is read again, it is read from the buffer instead of the database

three types of buffering are possible:

Full buffering

Generic buffering

Single-record buffering