Файл: BC430_EN_Col62_FV_Part_A4_-_ABAP_Dictionary.pdf

Unit 3: Performance During Table Access

BC430

You must distinguish between the primary index and secondary indexes of a table.
The

primary index

contains the key fields of the table. The primary index is

automatically created in the database when the table is activated. If a large table
is frequently accessed such that it is not possible to apply primary index sorting,
you should create

secondary indexes

for the table.

Indexes of a table have a three-place index ID.

0

is reserved for the primary index.

Customers can create their own indexes on SAP tables; their IDs must begin
with Y or Z.

If the index fields have key function, for example, they already uniquely identify
each record of the table, an index can be called a unique index. This ensures that
there are no duplicate index fields in the database.

When you define a secondary index in the ABAP Dictionary, you can specify
whether it should be created on the database when it is activated. Some indexes
only result in a gain in performance for certain database systems. You can
therefore specify a list of database systems when you define an index. The index
is then only created on the specified database systems when activated.

Improving the Performance through Table Buffering

Figure 32: Data Access using the Buffer

Table buffering increases the performance when the records of the table are read.

78

© 2007 SAP AG. All rights reserved.

2006/Q2

BC430

Lesson: Performance During Table Access

The records of a buffered table are read directly from the local buffer of the
application server on which the accessing transaction is running when the table
is accessed. This eliminates time-consuming database accesses. The access
improves by a factor of 10 to 100. The increase in speed depends on the structure
of the table and on the exact system configuration. Buffering, therefore, can
greatly increase the system performance.

If the storage requirements in the buffer increase due to further data, the data that
has not been accessed for the longest time is displaced. This displacement takes
place asynchronously at certain times which are defined dynamically based on the
buffer accesses. Data is only displaced if the free space in the buffer is less than a
predefined value or the quality of the access is not satisfactory at this time.

When you enter /$TAB in the command field the system resets the table buffers
on the corresponding application server. Only use this command if there are
inconsistencies in the buffer. In large systems, it can take several hours to fill the
buffers. The performance is considerably reduced during this time.

The buffering type determines which records of the table are loaded into the
buffer of the application server when a record of the table is accessed. There are
the following buffering types:

•

Full buffering:

When a record of the table is accessed, all the records of

the table are loaded into the buffer.

•

Generic buffering:

When a record of the table is accessed, all the records

whose left-justified part of the key is the same are loaded into the buffer.

•

Single-record buffering:

Only the record that was accessed is loaded

into the buffer.

2006/Q2

© 2007 SAP AG. All rights reserved.

79

Unit 3: Performance During Table Access

BC430

Figure 33: Full Buffering

With full buffering, the table is either completely or not at all in the buffer. When a
record of the table is accessed, all the records of the table are loaded into the buffer.

When you decide whether a table should be fully buffered, you must take the
table size, the number of read accesses and the number of write accesses into
consideration. The smaller the table is, the more frequently it is read and the less
frequently it is written, the better it is to fully buffer the table.

Full buffering is also advisable for tables that have frequent accesses to records
that do not exist. Since all the records of the table reside in the buffer, it is already
clear in the buffer whether or not a record exists.

The data records are stored in the buffer sorted by table key. When you access the
data with SELECT, only fields up to the last specified key field can be used for the
access. The left-justified part of the key should therefore be as large as possible
for such accesses. For example, if the first key field is not defined, the entire table
is scanned in the buffer. Under these circumstances, a direct access to the database
could be more efficient if there is a suitable secondary index there.

80

© 2007 SAP AG. All rights reserved.

2006/Q2

BC430

Lesson: Performance During Table Access

Figure 34: Generic Buffering

With generic buffering, all the records whose generic key fields agree with this
record are loaded into the buffer when one record of the table is accessed. The

generic key

is a left-justified part of the primary key of the table that must be

defined when the buffering type is selected. The generic key should be selected so
that the generic areas are not too small, which would result in too many generic
areas. If there are only a few records for each generic area, full buffering is
usually preferable for the table. If you choose too large a generic key, too much
data will be invalidated if there are changes to table entries, which would have
a negative effect on the performance.

A table should be generically buffered if only certain generic areas of the table are
usually needed for processing.

Client-dependent, fully buffered tables are automatically generically buffered. The
client field is the generic key. It is assumed that not all of the clients are being
processed at the same time on one application server. Language-dependent tables
are a further example of generic buffering. The generic key includes all the key
fields up to and including the language field.

The generic areas are managed in the buffer as independent objects. The generic
areas are managed analogously to fully buffered tables. You should therefore also
read the information about full buffering.

2006/Q2

© 2007 SAP AG. All rights reserved.

81

Unit 3: Performance During Table Access

BC430

Figure 35: Single-Record Buffering

Only those records that are actually accessed are loaded into the buffer.
Single-record buffering saves storage space in the buffer compared to generic and
full buffering. The overhead for buffer administration, however, is higher than for
generic or full buffering. Considerably more database accesses are necessary to
load the records than for the other buffering types.

Single-record buffering is recommended particularly for large tables in which only
a few records are accessed repeatedly with SELECT SINGLE. All the accesses to
the table that do not use SELECT SINGLE bypass the buffer and directly access
the database.

If you access a record that was not yet buffered using SELECT SINGLE, there is a
database access to load the record. If the table does not contain a record with the
specified key, this record is recorded in the buffer as non-existent. This prevents a
further database access if you make another access with the same key.

You only need one database access to load a table with full buffering, but you need
several database accesses with single-record buffering. Full buffering is therefore
generally preferable for small tables that are frequently accessed.

82

© 2007 SAP AG. All rights reserved.

2006/Q2