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

Question

how many types of joins r there?
thank u.

Answer 1

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.