Full Buffering (SAP Library - BC

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.

Example

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.

This graphic is explained in the accompanying text

Note

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.

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:

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