Файл: BC430_EN_Col62_FV_Part_A4_-_ABAP_Dictionary.pdf

Unit 3: Performance During Table Access

BC430

Figure 41: Buffer Synchronization 5

•

Timepoint 9:

The moment of synchronization has arrived. Both servers

look in the synchronization table to see if another server has modified one
of the tables in its local buffer in the meantime.

•

Timepoint 10:

Server 2 finds that the SCARR table has been modified by

Server 1 in the meantime. Server 2 therefore invalidates the table in its local
buffer. The next access from Server 2 to data of the SCARR table therefore
uses the database. Server 1 must not invalidate the table in its buffer, as it is
the only changer of the SCARR table itself. Server 1 therefore uses its local
buffer again the next time to access records of SCARR table.

88

© 2007 SAP AG. All rights reserved.

2006/Q2

BC430

Lesson: Performance During Table Access

Figure 42: Buffer Synchronization 6

•

Timepoint 11:

Server 2 again accesses records of SCARR table. Since

SCARR is invalidated in the local buffer of Server 2, the access uses the
database.

•

Timepoint 12:

The table is reloaded into the local buffer of Server 2. The

information via the SCARR table is now inconsistent again on the servers
and the database.

Advantages and disadvantages of this method of buffer synchronization:

•

Advantage: The load on the network is kept to a minimum. If the buffers
were to be synchronized immediately after each modification, each server
would have to inform all other servers about each modification to a buffered
table via the network. This would have a negative effect on the performance.

•

Disadvantage: The local buffers of the application servers can contain

obsolete data between the moments of synchronization.

This means that:

•

Only those tables that are written very infrequently (read mostly) or for
which such temporary inconsistencies are of no importance may be buffered.

•

Tables whose entries change frequently should not be buffered. Otherwise
there would be a constant invalidation and reload, which would have a
negative effect on the performance.

2006/Q2

© 2007 SAP AG. All rights reserved.

89

Unit 3: Performance During Table Access

BC430

An index helps you to speed up read accesses to a table. An index can be
considered a sorted copy of the table that is reduced to the index fields.

The table buffers reside locally on the application servers.

Buffering can substantially increase the performance when the records of the table
are accessed. Choosing the correct buffering type is important.

The table buffers are adjusted to changes to the table entries at fixed intervals.

The more frequently a table is read and the less frequently the table contents are
changed, the better it is to buffer the table.

Figure 43: Decision Tree for Buffering

The decision-making tree for buffering tables should be used for support on
your development system. The information mentioned above is shown here as a
diagram.

90

© 2007 SAP AG. All rights reserved.

2006/Q2

BC430

Lesson: Performance During Table Access

Exercise 6: Performance Aspects with

Table Access

Exercise Objectives

After completing this exercise, you will be able to:
•

Create indexes

•

Maintain the buffering attributes of a table

Business Example

In their daily work, airline employees need fast access to the data in the employee
administration tables. In this exercise, access to the data in these tables should be
speeded up.

The combination of first and last names is often used to access an employee's HR
data. The last name is more often declared (specified in the access) than the first
name. An index must be created for this.

To set up a flight crew, you have to assign employees (pilots and stewards) to
flights. You need to create a table in which the employees involved and their
functions can be entered for each flight.

Task 1:

Create an index that supports access to the combination of first names and
surnames. Make sure that the index is created on the database.

The HR data of the employees is managed in Table ZEMPLOY##. You therefore
need to create an index for this table.

1.

Create an index for the ZEMPLOY## table. It has to contain the fields

Client

,

Last name

and

First name

. Arrange these fields in this order.

Note:

The index is certainly not a unique index since there can

be employees with the same first and last names. There is also no
reason to create the index only on certain database systems.

Task 2:

Copy the table SFLCREW on to the table ZFLCREW##. Then activate the table
ZFLCREW##.

1.

Copy the table SFLCREW on to the table ZFLCREW##. Replace the
existing data element for the employee number with your own data element.

Continued on next page

2006/Q2

© 2007 SAP AG. All rights reserved.

91

Unit 3: Performance During Table Access

BC430

Task 3:

Maintain the settings for buffering the ZDEPMENT## and ZFLCREW## tables.

Reconsider these settings you made for buffering tables ZDEPMENT## and
ZFLCREW##. Keep the following information for using these tables in mind.

The airlines have between 10 and 30 departments. Only a few airlines (maximum
3) are managed together in the tables. The data about the crews of completed
flights is stored in an archive file every three months. Table ZFLCREW##
therefore has relatively few entries (at most 5,000 per airline).

Tables ZDEPMENT## and ZFLCREW## are accessed very frequently. Data
records are read repeatedly from these tables.

One application server is used exclusively by the employees of an airline who
work in administration. The flight crew data is only of internal interest within the
airline. Since the airlines share some services, administrative employees of an
airline often have to access departmental data of other airlines.

1.

Maintain the settings for buffering the ZDEPMENT## tables in the

Technical

Settings

.

Note:

Since the contents of table ZDEPMENT## are rarely changed

but frequently read, it is advisable to buffer the table.

2.

Maintain the settings for buffering the ZFLCREW## tables in the

Technical

Settings

.

Note:

The data in table ZFLCREW## is often read repeatedly. By

contrast, access to change the content occurs infrequently. You
should therefore buffer the table.

Usually, only the data for one airline is needed on an application server. You
should therefore buffer the table generically with the generic key

Client

and

Airline

.

3.

Execute the program BC430_CHECK in transaction SE38.

BC430_CHECK checks whether your solutions are correct and fills the new
table ZFLCREW## with the sample data needed for later exercises.

Caution:

If you do the supplementary exercise, start this program

only once you have completed the supplementary exercise.

Continued on next page

92

© 2007 SAP AG. All rights reserved.

2006/Q2