This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
The concept buffering a table in SAP is to improve the performance of the table when accessing data records contained in that table. The table buffers reside locally on each application server in the system. The data of the buffered table can be directly used from the buffer of the application server. Thus the to and fro access to the database is avoided and in turn consuming less time and increasing the speed of execution and thus increasing performance.
Buffering is particularly important in client/server environments, since it takes more time to access the table on a network as compared to a local machine. Hence if we buffer our table the database access to the server to retrieve the information again and again can be saved and can improve the performance tremendously.
If the program accesses the data of the buffered table, the database interface will determine whether the data is in the buffer of the application server or not. If the data is not in the buffer then it will fetch the data from the database the first time and then will load into the buffer for the next access. The next time when the same data is requested then instead of fetching it from the database the interface will determine that the data is available on the application server and fetch from the application server, which will save time.
Options for Selecting Buffering
There are 3 options for selecting buffering
Buffering not allowed
Buffering is not allowed on the table
Buffering allowed but not activated
Here Buffering is allowed but is temporarily deactivated, so at that point of time no buffering will happen.
Buffering allowed if the table should be buffered
Table will be buffered if proper buffering type is produced.
The buffering types define which table records are loaded into the buffer of the application server when a table record is accessed. There are 3 types of buffering.
Single record Buffering
Individual records of tables with single record buffering are managed in the single record table buffer TABLP.
Single record buffering requires less storage space in the buffer than generic and full buffering.
The administrative cost in single record buffering is higher than generic and full buffering.
Single record buffering should ideally be used for large table with very few records to be selected (Using SELECT SINGLE). The size of the records to be accessed should be between 100 KB to 200 KB.
All access that are not submitted with SELECT SINGLE go directly to the database, bypassing the buffer irrespective of the complete key passed in the where clause of the select statement.
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.
In the example, the record marked in red is read from the table SCOUNTER and all the records whose generic key fields agree are loaded into the buffer if the table is generic buffered.
In Generic buffering it is important to define a suitable generic key.
If the generic key is too small, then the buffer will contain a few very large areas. During access, too much data might be loaded into the buffer.
If the generic key is too large, then the buffer might contain too many small generic areas. This 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.
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.
With full buffering the entire table is buffered or the table is not in the buffer at all. All the records are loaded into the buffer when one record of the table is read.
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 the first key field is not defined, 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.
When deciding whether a table should be fully buffered, the size of the table, the number of read accesses, and the number of write accesses should be taken into account. Tables best suited to full buffering are small, read frequently, and rarely written.
Full buffering is recommended for 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, user 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.
Which Table is the right candidate to be buffered?
Only Transparent and pooled tables can be buffered, cluster tables cannot be buffered.
Character data types must be assigned to all the key fields of the buffered tables.
ABAP data types C, N, D, or T are allowed.
There is no point buffering a table which is modified frequently. In this the cost of synchronization would be greater than gain in performance.
The table which is read more than modified is the right candidate for buffering.
Example. An exchange rate table would be updated once a day, but would be read more than once, hence buffering this table would yield high performance.
Generally all customized and system tables would be buffered as they would not be frequently modified.
Master data to a certain extent can also be buffered as they would not be modified on a regular basis.
Transaction data would not be recommended for buffering as it would be changed frequently.
You can also bypass the buffered table using a select query such as â€œSELECT SINGLEâ€¦BYPASSING BUFFERâ€Â. However if you are bypassing the buffered table frequently using this statement than you must really consider the necessity of buffering the table.
How are Buffers locally 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.
If more space is required in the buffer due to new data, then the data than has not be used the longest gets displaced. The data is only displaced if there is less space in the buffer to incorporate new data.
Resetting the table Buffers
You can reset the buffers using $TAB in the command field. All the data in the buffer is invalidated.
Use this only when there are inconsistencies, because it may take up to several hours to fill the buffer again and the performance would be impacted during that time.
You must include at least 3 references to SDN documents or web pages.