sap monitoring

Thomas Schneider

SAP Performance Optimization

SAP Table Buffering 281

9 SAP Table Buffering

Every SAP instance has various buffers, in which data to be accessed byusers is stored. When the data is in the buffer, the database does not haveto be accessed, because buffers enable direct reads from the mainmemory of the application server. There are two advantages to this:

� Accesses to SAP buffers are normally 10 to 100 times faster thanaccesses to the database.

� Database load is reduced. This is increasingly important as your systemgrows in size

For each table defined in the ABAP dictionary you can decide if and how thetable should be buffered. To enable the buffering of tables, each SAPinstance has two table buffers, the single record table buffer (also known aspartial table buffer, TABLP) and the generic table buffer (TABL). The SAPbuffers are illustrated in Figure 9.1. When an SAP system is delivered thereare default settings on whether a table should be buffered. However, tooptimize runtime, it may be necessary to change these settings. Forcustomer-developed tables these settings must, in any case, be establishedby the developer.

This chapter deals with table buffering on the SAP application level. Tablebuffering on database level is dealt with in Chapter 11.

Figure 9.1 SAP buffering

SAP instance A

Database interface

TableBuffer

Database

SAP instance B

Database interface

TableBuffer

Database instanceDatabase Buffer


When should you read this chapter?

You should read this chapter to help you:

� Get detailed information on the possibilities of SAP buffering

� Monitor and optimize the efficiency of the buffering of SAP tables atregular intervals

� Decide whether customer-created database tables should be buffered

� Decide whether to buffer the condition tables created duringcustomizing for central SAP functions such as price determination oroutput determination

To better understand this chapter you should have some familiarity withABAP programming and SQL programming.

Preliminary Remarks for Chapters 9, 10 and 11

The following remarks concern the tuning measures dealt with inchapters 9 to 11: setting buffering for tables and number ranges and thecreation, changing or deletion of database indices. These measures –when correctly implemented – are important techniques for optimizingperformance. However, if they are not implemented correctly they canlead to massive performance problems and in some cases to datainconsistencies. Changing the buffer mode for tables and number rangesor creating, changing or deleting database indices, involve changes to theSAP system and should only be carried out by experienced developers orconsultants.

Technical analysis– logical analysis

The main aim of the following chapters is to help you to identifyperformance problems in these areas, that is, to find the program or tablecausing the problem, in order to be able to then deal with it. However,before making any concrete changes to solve the problem, you shouldperform a technical analysis and also a logical analysis. The procedure fortechnical analysis is explained in this book. This type of analysis can becarried out by a system or database administrator, for example. Thelogical analysis can only be executed by the developer responsible. Youshould bear the following recommendations in mind:

� For customer developed objects (program, table, index, number rangeand so on):

Changes to the buffering status or to database indices should beperformed only after careful consultation between the developer andthe system or database administrator.

Fundamentals of Table Buffering 283

� If the objects identified are from SAP standard:

The buffering status and database indices of SAP tables are already pre-set when the SAP system is delivered. In some cases it may benecessary to change these standard settings. Before you perform achange, you should look in the SAP Service Marketplace for notes onthe program name, table or number name which will confirm whetheror not you can change the object in question. These notes correspondto the SAP developer's input for the logical analysis. Changesperformed without the proper expertise can lead to unexpectedperformance problems and to data inconsistencies. Take note of thewarnings and recommendations provided in the respective sections ofthis book.

An important part of performance optimization is to verify the success ofchanges that have been carried out and then to document the analysis,the changes made and their verification.

Fundamentals of Table Buffering

The following sections deal with the fundamentals of table buffering. Thisincludes types of buffering, how to access buffers, synchronization ofbuffers and activating buffers. Finally, we will deal with the question ofwhich tables should be buffered.

Buffering types

We differentiate between three different types of table buffering: singlerecord buffering, generic buffering and full buffering.

Single record buffering

Single record buffering is suitable for accesses that are executed using alltable keys – in other words, all fields of the primary index. With singlerecord buffering, each record (a row in a table) that is read from thedatabase for the first time is archived in the buffer. Then, whenever therecord needs to be read again, it can be read directly from the buffer.

Let us take an example of a table <tab_sngl>, with the key fields <key1>,<key2> and <key3>. A record is read from the table with the followingSQL statement:

SELECT SINGLE * FROM <tab_sngl> WHERE <key1> = a1 AND

<key2> = a2 AND <key3> = a3.


Assuming that single record buffering is activated for table <tab_sngl>,then the single record buffer will be accessed for this SQL statement andnot the database.

In order for the buffer to be accessed, the ABAP key word SINGLE mustbe contained in the SQL statement. SQL statements in which not all keyfields are specified in the WHERE clause cannot be processed from singlerecord buffers; instead, the database will be accessed.

On the first attempt to access a table for which single record buffering isactivated, if the required record is not in the database, information isstored in the buffer to indicate that the record does not exist. In otherwords, negative information is also buffered. On a second attempt toaccess this record, the buffer search recognizes that the record does notexist and thus makes no attempt to access the database. As a result, thenumber of entries for a specific table in the single record buffer may belarger than the number of actual records in that table in the database.

Full buffering Full buffering is another way of buffering tables. With fully bufferedtables, on the first reading of a table record, the entire table is loaded intothe buffer. This type of buffering is mainly used for small tables.

Figure 9.2 compares the different types of buffering. The buffered recordsof a table are shown in dark gray. A fully buffered table is shown on theleft. Because the table is either completely contained in the buffer or notat all, either all entries will be dark gray or none at all. The right-hand tablein Figure 9.2 shows a single-record buffered table. Some individualrecords are buffered, others are not.

Generic buffering The third form of buffering is generic buffering with <n> key fields. On firstread access of a record in a generically <n> buffered table, all records withthe same <n> key field values as the targeted record are loaded into thebuffer. In Figure 9.2 the table second from the left is a table for whichgeneric buffering is activated and n = 1. For this table all records with thefirst key value = "002" are stored in the buffer. These records make upwhat is referred to as a generic region. Similarly, in the third column fromthe left, under "generic buffering, two key fields", the buffer containsgeneric regions with the first two key fields the same.


For table <tab_gen2> generic 2 buffering has been set. The first twoprimary key fields are the client (MANDT) and the company code(BUKRS). The table also contains the primary key fields <key3> and<key4>. Let us also assume that the table contains data on the companycodes "Poland", "Czech Republic" and "Slovakia". The table is nowaccessed with the following SQL statement:

SELECT * FROM <tab_gen2> WHERE mandt = '100' AND bukrs = 'Poland’ AND

<key3> = a3.

This statement causes the buffering of all records of table <tab_gen2>that correspond to client 100 and company code "Poland". If your SAPsystem has the users corresponding to the different company codesworking on different application servers, only the data that is relevant tothe company code used on a particular application is loaded in thebuffers of that server.

Buffer management is carried out by the database interface in the SAPwork process. Single record buffered tables are stored in the SAP singlerecord buffer (TABLP), generic and fully buffered tables are stored in thegeneric SAP table buffer (TABL). The tables in the buffer are sortedaccording to the primary key.

Buffer accessing

Even after a table is stored in the buffer, the database interface does notautomatically access the table buffers. As we have explained above, toaccess a single-record buffered table, all fields of the primary key of the

Figure 9.2 Generic regions of a table

key1 key2 key3 data

key1 key2 key3 data

key1 key2 key3 data

key1 key2 key3 data

Full buffering Generic bufferingusing one key field

Single record buffering

001001001001002002002002002002003003003003003003003003

001001001001002002002002002002002002003003003003003003003003003003003

001001001001001002002002002002002002002002002003003003003003003003003003003003003003

AA

BB

AABBBC

DC

AAABBCCCDDD

AA

BB

BAAAABBBC

DC

AAABBCCCCDDDD

42

31

513681230

53

2362423581234

Generic bufferingusing two key fields


table must be specified in the WHERE clause of the SQL statement withan EQUALS condition. Similarly, for a generic-n buffered table, the first"n" primary key fields in the WHERE clause must be specified with anEQUALS condition. Examine the following examples:

For table <tab_gen3> generic 3 buffering has been set. The fields <key1>,<key2>, <key3> and <key4> are the key fields of the table.

The following SQL statements access the SAP buffer:

� SELECT * FROM <tab_gen3> WHERE <key1> = a1 AND <key2> = a2 AND <key3>= a3

� SELECT * FROM <tab_gen3> WHERE <key1> = a1 AND <key2> = a2 AND <key3>= a3 and <key4> > a4

The following SQL statements cannot be processed with the help of theSAP buffer and require access to the database:

� SELECT * FROM <tab_gen3> WHERE <key1> = a1

� SELECT * FROM <tab_gen3> WHERE <key3> = a3

The buffer for the generic-3 buffered table is not accessed, because thefields <key1>, <key2> and <key3> are not all specified.

With a fully buffered table the buffer is always accessed, provided thatthe table in question has been loaded into the buffer.

Table <tab_ful> has full buffering. The fields <key1>, <key2>, <key3> and<key4> are the key fields of the table.

The following SQL statements access the SAP buffer:

� SELECT * FROM <tab_ful> WHERE <key1> = a1 AND <key2> = a2 AND <key3> = a3

� SELECT * FROM <tab_ful> WHERE <key3> = a3

Because the second statement does not specify the fields <key1> and<key2> and the table in the buffer is sorted according to these keyfields, all the data in the table must be read sequentially. If the table isrelatively large (for example with more than 100 records) it will bemore effective to optimize table access by not buffering the table butby creating a secondary index on the database using field <key3>.

As we can see in this example, in some cases access to a database canactually be more optimal than accessing a buffer. We will look at thisproblem in greater detail at a later stage in the book.


Other exceptionsThe following SQL statements do not access the SAP buffer:

� SQL statements with the clause BYPASSING BUFFER. This clause isused to indicate statements that should deliberately not access thebuffer.

� SELECT FOR UPDATE statements. These statements set a databaselock and as a result they involve a database access.

� SQL statements using the aggregate functions SUM, AVG, MIN, MAX

� SQL statements with SELECT DISTINCT

� SQL statements containing the operator IS NULL

� SQL statements that trigger sorts (except sorts by primary key)

� SQL statements that access views (except projection views)

� Native SQL statements

Buffer synchronization

If an entry to a buffered table is changed, the corresponding entries in thetable buffers of all SAP instances must be updated. This process is referredto as buffer synchronization.

First of all we will look at changes to tables executed with an ABAPstatement with no WHERE clause, that is to say with the ABAP statementsUPDATE dbtab, INSERT dbtab, MODIFY dbtab or DELETE dbtab. Onlyone row in the table is changed in this case.

Synchronization in the buffer involves four steps, as illustrated in Figure 9.3.As an example, let us assume that one record is changed in the bufferedtable T001.

1. On the SAP instance A, the buffered table T001 is changed by theABAP statement UPDATE T001. The database interface modifies tableT001 on the database and the buffer entry for instance A at the sametime. Thus, the buffer of the local SAP instance A is updatedsynchronously. At this time, the buffers of all SAP instances except for Aare not up-to-date.

2. After table T001 has been changed in the database, the databaseinterface (DBIF) for SAP instance A, logs the change by writing an entryto the database table DDLOG.

3. Table DDLOG is periodically read by all SAP instances. On the basis ofthe DDLOG entry, the buffer entry for table T001 is invalidated. Thebuffers of the SAP instances are still not updated, but the content oftable T001 in the buffer is marked as being invalid.


4. If table T001 is read again on an SAP instance other than A, thedatabase interface can recognize that the data in the buffer is no longervalid. The data is reloaded from the database into the buffer. In thisway, the buffers of all SAP instances other than instance A areasynchronously updated.

Pending period After an invalidation, the contents of a table are not immediately loadedinto the buffer at the next read access. Rather, a certain waiting or pendingperiod is observed. The next "n" accesses are redirected to the database. Thebuffer is only reloaded after the pending period. This protects the bufferfrom frequent successive invalidations and reloading operations.

The synchronization mechanism described here applies not only to tablebuffers, but also to other SAP buffers (such as the program buffer).

rdisp/bufrefmode,rdisp/

bufreftime

Buffer synchronization is controlled by the SAP profile parameters rdisp/bufrefmode and rdisp/bufreftime. For an SAP system with only one SAPinstance the parameter rdisp/bufrefmode should be set to "sendoff,exeauto". The "sendoff" entry means that no DDLOG entries can bewritten (as there is no other SAP instance to be synchronized). "exeauto"means that table DDLOG is read periodically. This is necessary for buffersynchronization after an import using the transport programs tp orR3trans. (The SAP Change and Transport system (CTS) writes entries to theDDLOG table to enable buffer synchronization after the import ofbuffered objects (for example table contents and programs). In an SAPsystem with multiple SAP instances rdisp/bufrefmode must contain thevalue "sendon, exeauto". rdisp/bufreftime specifies the frequency of

Figure 9.3 buffer synchronization

SAP instance BSAP instance A

Database interface

TableBuffer

DatabaseDDLOG

table

Database interface

TableBuffer

UPDATET001 ...

T001 tableINSERT DDLOG

SELECT DDLOG


buffer synchronization. You should not change the default value of 60(seconds). This means that table DDLOG is read every 60 seconds.

Granularity of table invalidation

Table entries are invalidated as follows:

� If a record is changed in a table with single record buffering, then justthis record is invalidated. All other buffered table entries remain valid.

� If a record in a fully buffered table is changed, then the entire contentsof the table are invalidated.

� If a record in a generically buffered table is changed, then the genericarea in which this record is located, is invalidated.

Thus, table contents are invalidated in the same units that they are filled.

A somewhat different buffer synchronization procedure is used when abuffered table is changed through an ABAP statement that uses a WHEREclause, for example with UPDATE <dbtab> WHERE..., DELETE FROM<dbtab> WHERE... This type of ABAP statement can be used to changeseveral records in a table. In this case, as a result, the entire <dbtab> tablein question is invalidated in the buffer of the local SAP instance (instanceA in our example) and on all other servers. For this reason, changes withWHERE clauses can increase buffer management workload much morethan change operations that do not use a WHERE clause.

When program or customizing settings are transported, invalidations alsooccur. Therefore, imports should not be carried out in a productivesystem at times of high workload. It is recommended that imports shouldbe scheduled once or twice per week at times of low workload.

Invalidations and displacements

Invalidations should not be confused with displacements, which aredisplayed in the SAP Memory Configuration Monitor (ST02) in the Swapscolumn. When there is not enough space in the buffer to store new data,the data that has not been accessed in the longest time is displaced.Displacement occurs asynchronously, determined by accesses to thebuffer. It occurs when the space available in the buffer falls below acertain level or when access quality falls below a certain point.

Activating buffering

1. To activate or deactivate buffering for a table, call the ABAP dictionaryfunction by selecting:

Tools • ABAP Workbench • Dictionary

2. Enter the table name, select the Display button and then Technicalsettings.


3. To activate buffering, select Buffering switched on. Finally, enter thebuffering type (full, generic or single record) and, in the case of genericbuffering, the number of key fields.

4. Save the new settings.

5. Once they have been saved, you can activate the changes. The settingsshould then show the status "active", "saved".

Since the technical settings of a table are linked to the SAP Change andTransport System (CTS), to change the buffering for a table you need achange request. Buffering can be activated or deactivated while the SAPsystem is running.

There are three options for setting buffering:

� Buffering not allowedThis setting deactivates buffering for a table. It is used if a table shouldnot be buffered under any circumstances (for example, if it containstransaction data that is frequently changed).

Figure 9.4 Technical settings of a table


� Buffering allowed but switched offThis setting also deactivates buffering for a table. It means that it ispossible to buffer this table, but in this particular system, for reasons ofperformance, buffering has been deactivated (for example, becausethe table is too large). Whether a given table with this characteristicshould in fact be buffered can be ascertained from the analysesdescribed later in this chapter.

� Buffering switched onThis setting activates the buffering for the respective table.

If you try to activate buffering for a table that SAP has delivered with thesetting Buffering not allowed, this is considered a modification of theSAP system and must be registered in the SAP Service Marketplace. Youshould activate the buffering for such tables only if you have beenexplicitly advised to do so by SAP.

If you set the buffering type for a client-dependent table to "full", thetable will automatically be buffered as generic 1.

What tables should be buffered?

Technical prerequisites

If tables are to be buffered, they must satisfy the following technicalprerequisites.

� Buffered data will be stored redundantly on all SAP instances. As aresult, buffering is only suitable for small tables that are readfrequently.

� Buffer synchronization causes a somewhat considerable loss inperformance when accessing buffered tables. Therefore, only tablesthat are not changed often should be buffered.

� Buffered tables are sorted and stored according to key fields. Tablebuffering is therefore optimal for statements that access the tablethrough the key fields. Table buffers do not support searching usingsecondary indexes.

� Buffer synchronization occurs after a certain delay. Therefore, youshould only buffer tables for which short-term inconsistencies areacceptable.

In the SAP system we differentiate between three types of data:transaction data, master data and customizing data.

Never buffer transaction data!

Transaction data includes, for example: sales orders, deliveries, materialmovements and material reservations which, for example, are stored inthe tables VBAK, LIKP, MKPF and RESB. These tables grow over time and


can reach several Mbytes or even Gbytes in size. In principle, transactiondata should not be buffered.

As a rule, do notbuffer master

data!

Typical master data includes, for example, materials, customers andsuppliers, stored in the tables MARA, KNA1 and LFA1. Tables with masterdata grow slowly over time and can reach sizes of several hundredMbytes. For this reason, master data is generally not buffered. Anotherargument against buffering master data tables is that master data isnormally accessed with many different selections and not necessarily viathe primary key. Rather than buffering, accesses to these tables can beoptimized by the use of secondary indices.

Customizing datais normally

buffered!

Customizing data portrays, among other things, the business processes ofyour enterprise in the SAP system. Examples of customizing data includethe definition of clients, the company codes, plant and salesorganizations, for example in tables T000, T001, T001W and TVKO.Customizing tables are generally small and are seldom changed once thesystem has gone live. As such, customizing data is very suited to tablebuffering.

Table TCURR, for example, contains exchange rates for foreign currencies.The key fields in this table are MANDT (client), KURST (type of exchangerate), FCURR (source currency), TCURR (target currency) and GDATU(start of validity period). In most customer systems this table is small, it israrely changed and thus meets all the conditions for buffering. As a result,it is delivered by SAP with the status "full buffering" set.

In some SAP systems, however, it may occur that this table grows quicklybecause many exchange rates are required and the rates are frequentlychanged. Because the table is fully buffered, older entries (entries withvalidity periods that have long since expired) are also loaded into the buffer,although they are no longer necessary for normal operation. As a result,once the table reaches a particular size, table buffering is no longereffective. If the table is changed during daily operation, invalidations anddisplacements reduce performance.

In this case, you should remove the table from buffering. You should also tryto achieve a long-term application-specific solution: are all table entriesreally necessary? Could old entries be removed – for example by archiving?We will look at this example again in greater detail in the section “Detailedtable analysis” on page 304.

Monitoring SAP Table Buffering 293

Condition tablesCondition tables contain the customizing data for the central logicalfunctions that determine such information as pricing, outputdetermination, partner determination, account determination and so on.These functions are used in the logistics chain, for incoming sales orders,goods issue, billing and so on. Given that these transactions are extremelycritical for performance in many SAP systems, the optimization ofbuffering for condition tables should receive special priority.

Condition tables are: A<nnn>, B<nnn>, C<nnn>, D<nnn>, KOTE<nnn>,KOTF<nnn>, KOTG<nnn> and KOTH<nnn>, with <nnn> = 000–999. Tableswith nnn = 000–499 are part of SAP standard and, with a few exceptions,are delivered with the attribute Buffering switched on. Tables with nnn =500–999 are generated in customizing as required and are not initiallybuffered.

Table A005 contains customer and material-specific price conditions. Inother words: In this table a price condition can be maintained for everycombination of customer and material. In addition, a validity period canbe set for the price condition. If the possibility of customer-specific pricesis used intensively in an SAP system, and these prices are frequentlychanged, this table would grow very quickly. A problem similar to whatwe have described above in the example of table TCURR occurs: In thiscase the table would have to be removed from buffering. Other conditiontables that would likewise grow quickly include A017 and A018 (pricesfor suppliers and material numbers).

Monitoring SAP Table BufferingProblem areasThree problems can occur in the area of SAP table buffering and they

should be monitored:

� Tables are designed too small and as a result, displacements (swaps)occur. Monitoring of displacements is described in chapter 2,“Analyzing SAP Memory Management” on page 98. Before continuingwith a detailed analysis, check that the table buffer has at least 10%free space and at least 20% free directory entries.

� Tables may be buffered that, for reasons of performance, should nothave been buffered, either because they are changed (invalidated) toooften or because they are too large.

� Tables that should be buffered for reasons of performance are notbuffered. This is mainly the case for tables that are created in thecustomer system, whether explicitly in the ABAP dictionary orimplicitly in customizing (for example, condition tables).


Monitoring table buffering is not a task that needs to be carried outperiodically. There follows some examples of when table buffers shouldbe examined:

� Users complain about occasional long response times in a transactionthat normally runs quickly.

� On analyzing the shared SQL area or an SQL trace you find expensiveSQL statements related to buffered tables which would indicate reloadprocesses caused by incorrect buffering.

� On analyzing the single record statistics (transaction code STAT), youfrequently find the entry "Note: Tables were saved in the table buffer"(see also chapter 4, “Single Record Statistics” on page 149).

The monitors and strategies described below help you to identifyproblems with incorrectly buffered tables.

Table access statistics

SAP Table Access Statistics (also called Table Call Statistics) is the mostimportant monitor for analyzing SAP table buffering.

1. The Monitor can be started as follows:

Tools • Administration • Monitor • Performance • Setup/Buffers • Calls

2. A selection screen appears. Here, you can select the time period, theSAP instance and the type of table to be analyzed. For this analysis,select "All tables", "Since startup" and "This server".

3. A screen is displayed that lists details on ABAP and database accessesand buffer status for all tables in the SAP system. You can navigatebetween different lists using the arrow buttons (from SAP Basis 4.0 on).By double-clicking on a row you can view all the information that isavailable for that table.

The most important fields are described in Table 9.1.

Field Explanation

Table Name of the table; if it is a pooled table, the name of the table pool is given first, for example, KAPOL A004

Buffer State The status of the table in the buffer – if this table can be buffered. See Table 9.2 for more information

Table 9.1 The fields in the Table Calls Statistics Monitor


Request, Open, Fetch

A table access in an ABAP program is called a request. We differentiatebetween five different types of requests: Direct Reads, SequentialReads, Inserts, Updates and Deletes. Direct Reads are SELECT SINGLEstatements that have specified all the primary key fields in the WHEREclause with an EQUALS condition. All other select statements are knownas sequential reads. Inserts, Updates and Deletes are referred to asChanges.

In a request, the ABAP program calls up the database interface of the SAPwork process. The database interface checks to see if the data needed forthe query can be provided by the table buffer in the SAP instance. If thisis not the case, the database interface passes the SQL statement on to thedatabase. An SQL statement performing a read is made up of an OPENoperation, that transfers the SQL statement to the database, and one ormore FETCHES, that transfer the resulting data from the database to theSAP work process. An SQL statement that is performing a change issimilarly made up of an OPEN operation and an EXEC Operation. Formore detailed explanations of the Prepare, Open, Reopen, Fetch andExec operations, see chapter 4, “Evaluating an SQL trace” on page 155.

Buf key opt Buffering type: "ful" indicates full buffering, "gen" indicates generic buffering and "sng" indicates single record buffering.

Buffer size [bytes]

Space occupied by the table in the SAP table buffer

Size maximum [bytes]

Maximum size of the table in the SAP table buffer since system startup

Invalida-tions

Number of invalidations

ABAP/IV Processor requests

Number of ABAP table access requests received by the database interface, subdivided into Direct Reads, Sequential Reads, Updates, Inserts, Deletes

DB activity Number of database operations (Prepare, Open, Reopen, Fetch or Exec), that the database interface has forwarded to the database, subdivided according to Direct Reads, Sequential Reads, Updates, Inserts, Deletes

DB activity – Rows affected

Number of rows that are transferred between the database and the SAP instance.

Field Explanation

Table 9.1 The fields in the Table Calls Statistics Monitor (Contd.)


For tables that cannot be buffered, the database interface automaticallypasses each request on to the database. For direct reads, inserts, updatesand deletes, each request corresponds to exactly one OPEN and oneFETCH. For sequential reads the situation is more complex because for eachrequest there can be more than one OPEN and more than one FETCH.

For tables that can be buffered, requests encounter one of three possiblesituations:

� The contents of the table are located in the buffer with the "valid"status: The required data can be read from the buffer. As a result, thisrequest requires no database activity.

� The contents of the table are located in the "valid" buffer, but the SQLstatement does not specify the correct fields or it contains the clauseBYPASSING BUFFER to prevent reading from the SAP buffer. Acomplete list of SQL statements that do not read from the SAP buffercan be found in the section “Buffer accessing” on page 285. In thissituation, database activity is required to satisfy the request.

� The table contents are not yet located in the buffer or are not valid: Inthis situation the data needed for the request cannot be read from thebuffer. The database interface loads the buffer (if the table is not in thepending period).

During the initial buffer load process, the field Database activity: Rowsaffected is not increased. If a table has been loaded only once into thebuffer and all subsequent requests are read from the buffer, the value inthe Database activity: Rows affected field remains at zero in the tableaccess statistics. If the table is invalidated or displaced and then reloadedinto the buffer from the database or if the buffer is bypassed, theDatabase activity: Rows affected field is increased by the number oftable rows that are read.

Buffer status The Buffer State field shows the buffer status of a table. The various statuspossibilities are listed in Table 9.2.

Status Explanation

valid The table (or parts of it) is valid in the buffer, which means that the next access can be read from the buffer.

invalid The table has been invalidated. It cannot yet be reloaded into the buffer because the operation that changed the table has not yet been completed with a "commit".

Table 9.2 Buffering status


Figure 9.5 shows the screen shot of a table access statistic in an SAPsystem (SAP Basis 3.1). The list is sorted according to the DB activity –Rows affected column which indicates the number of records read fromthe database. At the top of the list we find buffered tables, such as thecondition tables A004, A005 and A952. The entry KAPOL preceding thename indicates that these tables are located in the KAPOL table pool. Weshall come back to the evaluation of this example in the next section.

Analyzing buffered tables

Identify buffered tables for which buffering reduces rather than increasesperformance. To do so, proceed as follows:

1. Start the SAP Table Call Statistics as follows:

Tools • Administration • Monitor • Performance • Setup/Buffers •

Calls

2. In the following screen select All tables, Since startup and This server.

3. The screen that then appears should resemble that shown in Figure 9.5.

First step: Determine number of database accesses

In this first step sort the Table Call Statistics according to the "DB activity– Rows affected" column. The number of "rows affected" is an indicationof the database load caused by accesses to the table in question. Thetables with high database activity will appear at the top of the list. Theseshould be transaction data tables or large master data tables, for example,

pending The table has been invalidated. It cannot be loaded at the next access because the pending period is still running.

loadable The table has been invalidated. The pending period has expired and the table will be reloaded at the next access.

loading The table is currently being loaded.

absent, displaced

The table is not in the buffer (because, for example, it was never loaded or it has been displaced).

multiple Can occur for tables with generic buffering: Some generic areas are valid, others have been invalidated because of changes.

error An error occurred while the table was being loaded. This table cannot be buffered.

Status Explanation

Table 9.2 Buffering status (Contd.)


the tables VBAK, S508 and MDVM in Figure 9.5. For many of these tablesthe number of requests is around the same as the number of "rowsaffected".

For buffered tables the number of "rows affected" should be low, becausefor accesses to these tables, data should be read from the buffer and notfrom the database. Therefore, such tables should not appear towards thetop of the list. If, as in Figure 9.5, you find buffered tables with a highnumber of "rows affected", there are two possible causes:

� The table is relatively large and has been changed or displaced.Reloading processes and database read accesses during the pendingperiod are reflected in a high number of "rows affected". You shouldcheck to see if buffering should be deactivated for these tables.

� The type of buffering does not match the WHERE clause in the readaccesses so the database interface cannot use the buffer.

If buffered tables appear among the top entries in Table Calls Statisticssorted according to "rows affected", this is a sure sign that buffering thesetables is counter-productive. These tables should be analyzed in greaterdetail.

Figure 9.5 Table Call Statistics (first example)


Second step: Analyzing the rate of changes and invalidations

In a second step, determine the rate of change of the buffered tables("changes" / "requests" in the Table Calls Statistics) and the number ofinvalidations. To do this, sort according to the columns Invalidations orChanges. Using the guideline values given above, check to see ifbuffering should be deactivated for the tables with the highest rates ofchange and the most invalidations.

Third step: Determining table size

In a third step sort the Table Calls Statistics according to table size (theBuffer size column). First of all, you should check the buffering status ofthe largest table. It should be "valid". By comparing the values for "buffersize" and "size maximum" you can see if generic areas of the table havebeen displaced or invalidated. You should also check, using the guidelinevalues given below, if buffering should be deactivated for the largest table.

4.0BThe following counters may be of use in deciding whether a table shouldbe buffered or not: Tables that are smaller than 1 Mbyte and with aninvalidation rate of less than 1% do not generally present any technicalproblems and can be buffered. Tables between 1 Mbyte and 5 Mbytesshould have an invalidation rate of less than 0,1%. For tables that arebigger than 5 Mbytes, the developer must decide individually for eachtable whether buffering is worthwhile. Please note that these guidelinevalues reflect experience up to the time of going to print of this book.

Fourth step: logical analysis

Before deactivating buffering for a table, as a fourth step you shouldconsider the following recommendations:

� For customer-developed tablesChanges to table buffering status should only be made after jointconsideration involving the developer and the system administrator.

� For tables created by SAPIt may occur that you need to deactivate buffering for a table whichhad buffering activated in the standard delivery. An example could bethe TCURR table mentioned above or the SAP condition tables (suchas Annn). However you should never deactivate buffering unless youhave analyzed the table functions closely. This applies in particular forSAP basis tables, such as the tables DDFTX and USR*. If you find anSAP table for which you wish to deactivate buffering, you should firstlook for related notes in the SAP Service Marketplace.


Verifying the effects of changes

Once you have changed the buffering mode of a table, you should verifythe success of your actions.

Ideally, you should know the programs and transactions that access thetables in question and can directly observe how the changes affectruntime.

In the Table Calls Statistics you can verify the success of your changes bycomparing the number of "requests" to "rows affected". The purpose of atable buffer is to reduce the number of database accesses. This should bereflected in the ratio of "requests" to "rows affected". If, by changing thebuffering for a table you have not managed to increase this ratio,reanalyze the buffer and, if in doubt, undo the changes you made tobuffering.

Example

Figures 9.5 and 9.6 show two screen shots of Table Calls Statistics fromtwo real SAP systems. Both lists are sorted according to the DB activity –Rows affected column.

We shall first of all look at Figure 9.5. As mentioned above, we wouldexpect that tables with transaction data or a large volume of master datawould be at the top of the table, such as the tables VBRK, S508, MDVM.However, at the top of the list we see the buffered condition tables A004,A005 and A952. The buffering status of these tables is "valid", whichmeans that these tables are located in the buffer. On comparing thecolumns ABAP/IV Processor requests – Total and DB activity – Rowsaffected, you see that per request (that is to say, per ABAP access) anaverage of 1000 rows are read from the table. For these three tables atotal of around 7.5 million rows were read. This represents around 75% ofthe records read for all of the tables together (9.7 million). It is likely thatthe very high number of reads for these three tables is caused by frequentbuffer load-processes.

To verify this suspicion, examine the number of invalidations and the sizeof the table in the buffer. To do this, double-click the row containing thetable that you want to analyze. This takes you to a screen summarizing allthe available information on this table. In our example you will see thattables A004, A005 and A952 are frequently invalidated, which meansthat they have an invalidation rate or more than 1% of the total requests.The size of the tables in the buffer (Buffer size [bytes] field in Figure 9.5)


is between 3 and 10 Mbytes. According to the guidelines for tablebuffering given above, these tables should not be buffered. By analyzingTable Calls Statistics in this case, we have come to the conclusion thatbuffering should be deactivated for tables A004, A005 and A952.

On looking at the Changes column in Figure 9.5, at first you may besurprised to see that tables A004, A005 and A952 are invalidatedalthough there are no changes indicated in the column Changes. This isbecause the column Changes only displays the changes that areperformed on the local SAP instance (here, "appserv5_DEN_00").Modifications are not shown in the Changes field if they are executed onother SAP instances or if the changes to the customizing tables are carriedout in another SAP system, such as the development system, and thentransferred to the SAP system being examined. Nevertheless thesechanges from other SAP systems do cause an invalidation of the bufferentries and as a result start a local buffer reloading process.

An analysis similar to that just carried out on the Table Calls Statisticsshown in Figure 9.5 can also be carried out for Figure 9.6. In this examplethe list is also sorted according to DB activity – Rows affected and wealso have a number of buffered tables at the top of the list. The entry"displcd" in the Buffer State column shows that table A005 was notinvalidated because of a change, rather, it was displaced because of a lackof space in the buffer. Therefore, in this example two factors cometogether: On the one hand, tables were buffered that were possibly toolarge and changed too often for buffering, on the other hand the tablebuffer is too small and this causes displacements. You can see ifdisplacements occur in the table buffer, by checking the Swaps column inthe SAP Memory Configuration Monitor (transaction code ST02).

Since the example in Figure 9.6 reveals two problems, the correspondingsolution strategy is more complex. First of all, the size of the table buffersshould be increased. The size and number of invalidations in tables A005,A004, A006 and A017 should be examined in more detail and using theguideline values listed above, you should decide whether buffering shouldbe deactivated for these tables. For example, if you find that table A005 islarger than 1 Mbyte and the number of invalidations is greater than 0.1%,you should deactivate buffering for this table. After this first optimizationstep, you should carry out a second analysis on the Table Calls Statistics tosee if the number of database accesses to the buffered tables is noticeablyreduced. If not, analyze the table statistics further to determine whether youneed to enlarge the table buffer size or deactivate buffering for other tables.


For computers with large main memory it is not unusual for the genericbuffer table to be configured with as much as 100 Mbytes and single recordbuffers to be configured to 40 Mbytes.

Analyzing tables that are currently not buffered

In this section we will describe an analysis to help you decide if youshould activate buffering for any tables that are currently not buffered. Toperform the analysis, call up the Table Calls Statistics and proceed asfollows:

First step: Access statistics

Requests To identify tables that are currently not buffered and may potentiallybenefit from being buffered, in a first step sort the Table Calls StatisticsMonitor according to the ABAP/IV Processor requests – Total column. Atthe top of the list you will normally find the tables DDNTF and DDNTT.These are ABAP dictionary tables that are stored in the NTAB buffers – the"Field description buffer" and the "Table definition buffer". The nexttables in the list will be as follows:

� Tables with transaction data or large master data tables, such as thetables MARA, MARC, VBAK, MKPF from SAP logistics modules andSAP update tables VBHDR, VBMOD and VBDATA. These tables cannotbe buffered.

� Buffered tables with customizing data. Make sure that buffered tableswith a high number of requests show the "valid" status.

Figure 9.6 Table Call Statistics (second example)


If there are non-buffered customizing tables at the top of the list sortedby requests, you should consider activating buffering for these tables.

You should pay particular attention to customer-developed tables. Theseinclude tables explicitly created in the ABAP dictionary (for example,tables with names beginning with Y or Z) and condition tables generatedduring customizing (for example with Annn, nnn = 500).

The result from the first step is a list of tables that could potentially bebuffered because they receive a high number of requests.

Second step: technical analysis

In the second step you can determine the invalidation rate and the size ofthe table with a technical analysis.

ChangesOne criterion for deciding if a table should be buffered is the change rate,which can be calculated from the ratio of Changes to Requests. Note thatthe Changes column only displays the changes on the selected SAPinstance but not changes performed on other SAP instances nor thosethat are imported as table content.

Table sizeYou should also determine the size of the table (see also the section“Detailed table analysis” on page 304).

Third step: logical analysis

In the third step check to see if the logical prerequisites for buffering aremet (see also the section “What tables should be buffered?” onpage 291).

� For customer-developed tables:To determine if the technical prerequisites for buffering are met,contact the developer responsible to find out the purpose of the tableand determine whether or not the tables should be buffered, from alogical point of view. For example, condition tables are usually suitedto buffering, as mentioned above. The developer sets the type of tablebuffering. Note that single record buffering and generic buffering areonly useful if the key fields are specified in the WHERE clause of theaccess requests.

Changes to table buffering status should only be made after jointdeliberation between the developer and the system administrator.

� For tables created by SAPThe buffering status of SAP tables are already pre-set when the SAPsystem is delivered. Usually, most of the tables that can be buffered,


are buffered. If you find an SAP table that you feel should be buffered,check for relevant notes in the SAP Service Marketplace. You shouldnever activate buffering for tables with the characteristic "Buffering notallowed", unless you have explicit instructions to do so from SAP.

Activating buffering can lead to logical inconsistencies because ofasynchronous buffer synchronization. You should therefore never activatebuffering if you are not sure how the table functions and what type ofaccesses are made to the table. Activating buffering can also causeperformance problems if the table is too big and/or is changed toofrequently.

Detailed table analysis

With detailed table analysis you can determine the size of a table, thenumber of table entries and the distribution of the generic regions in atable.

1. To start the detailed table analysis, mark a table in the Table CallsStatistics Monitor and select the Analyze button, or enter thetransaction code DB05. For older SAP versions, start the reportRSTUNE59.

2. Enter a table name and mark Analysis for primary key. Start theanalysis. (Please note: This may take some time for large tables. Theresults of the analysis are then shown.

3. Use this list to check the size of the table. In the upper part of the listyou find, among other things, the number of table entries and the sizethat the table would be if fully buffered. This size can be smaller orlarger than the space needed for the table on the database. Forexample, database fragmentation can cause the table to consumeunnecessary space on the database. In addition, unlike somedatabases, the table buffer does not compress empty fields to minimizethe need for storage space.

4. Check the distribution of the generic areas of the table. You will findthe necessary information in the lower part of the analysis screen.

Rows per generic key

Distinct values

1–10 11–100 101–1 000

1001–10 000

10000–100 000

> 100 000

MANDT The following distribution applies to client 100

1. KURST 41 10 14 11 0 6

Table 9.3 Example of detailed analysis of generic regions for table TCURR


Table 9.3 shows an example of the possible distribution of generic regionsin table TCURR. (Compare also the section “What tables should bebuffered?” on page 291.) The distribution displayed concerns productiveclient 100. This distribution analysis is interpreted as follows:

� KURST rowThe Distinct values column shows the number of generic regions,which in this example is the number of different types of currencyexchange (KURST field). Table TCURR contains 41 different types ofcurrency exchange. Of these, 10 types have between 1 and 10 entriesin the table (1-10 column), 14 types have between 11 and 100 entriesand so on. Finally there are 6 exchange rates with between 10000 and100000 entries. No exchange rate type has more than 100000 entries.

� FCURR rowThere are 1311 different combinations of exchange rate types (KURSTfield) and source currencies (FCURR). There is no combination withmore than 10000 entries (The row 10000–100000 is empty).

� Last row; GATUThere are 169795 different entries with the combination MANDT,KURST, FCURR, TCURR and GDATU. This is also the total number ofentries in client 100, because MANDT, KURST, FCURR, TCURR andGDATU make up the complete primary key for table TCURR.

Ultimately, one row of this distribution analysis shows the averagenumber of rows read when one, two or n fields of the primary key arespecified.

How does this distribution analysis actually help you to decide how tableTCURR should be buffered?

� First of all you can see that table TCURR has 169795 different entriesin the live client. If TCURR has full or generic-1 buffering, a changeoperation always invalidates the client entirely. Therefore, after achange operation 169795 records must be reloaded into the buffer. In

2. FCURR 1311 877 209 175 50

3. TCURR 5188 1921 2920 347

4. GDATU 169795 169795

Rows per generic key

Distinct values

1–10 11–100 101–1 000

1001–10 000

10000–100 000

> 100 000

Table 9.3 Example of detailed analysis of generic regions for table TCURR (Contd.)


other words: the buffer loading process is justified only if users need tomake over 100000 read accesses. The invalidation rate for this tablemust have been very low to ensure that buffering the table does notcause too great a reduction in performance.

� Should you decide to set generic-3 buffering for table TCURR, amaximum of 1311 generic regions would be buffered, as can be seenin the "FCURR" row of the "Distinct values" column. The largestregions (50 in total) contain between 1001 and 10000 records. If arecord in the table TCURR is changed, then a maximum of 10000records would be invalidated and reloaded.

� It would also be possible to set generic-4 buffering. Up to 5188generic regions would then have to be buffered.

From this analysis it is clear that full buffering for table TCURR is out ofthe question. Depending on the invalidation rate, this table should be setto generic-3 buffering, or not buffered at all.

The larger the table, the more you should favor generic buffering.

In the initial screen of the detailed table analysis you have the possibility ofselecting the Analysis for fields function. This enables you to start analysesfor any combination of table fields, to be specified in the fields Field1,Field2 and so on. With this analysis you can determine the selectivity of asecondary index. See also chapter 11, "Optimizing SQL Statements withSecondary Indexes".

Monitoring buffer synchronization (DDLOG entries)

The buffer synchronization monitor displays the remaining, undeleted,entries in the DDLOG table.

1. The Monitor can be started as follows:

Tools • Administration • Monitor • Performance • Setup/Buffers •

Buffers • Detail analysis menu • Buffer Synchron

2. In the selection screen you can specify the buffer for which you wish toview the synchronization activities. With the Select all button you canselect all buffers.

3. Then select Read DDLOG. A list appears, displaying thesynchronization operations in accordance with the selection criteriaentered.

Figure 9.7 shows an example of the output of this monitor. Table 9.4explains the various different fields.


Shared SQL area and SQL trace

Normally, buffered tables should not give rise to any database accesses,except for the initial loading of the buffer. Once the SAP system has beenin production operation for some time, no SQL statements used forloading the buffer should appear in the shared SQL area and in the SQLtrace. However, if these statements appear among the expensive

Figure 9.7 Buffer synchronization monitor

Field Explanation

Hostname Name of the application server that has written the synchronization entry. If the referral originates from an import, this column shows the entry "tp" or "R3trans".

ID and SEQ.No.

Unique identification (for internal use)

Date and Time

Time stamp

Class Name of the buffer: NTAB, ABAP, TABLP, TABL etc.

Tablename Name of the table to be synchronized

Func Database operation: INS, DEL, UPD

Object key Relevant key, if the invalidated area is a generic region.

Table 9.4 Fields in the buffer synchronization monitor


statements in the shared SQL area or in the SQL trace, this shows they arenot being buffered properly.

An SQL statement that was used to load a buffer can be recognized asfollows:

� The WHERE clause for the generic-n buffered tables, specifies the first"n" fields with an equals sign. For a table with full buffering or generic-1 buffering, this is the client (if the table is client-dependent).

� The SQL statement contains an Order-by condition, which contains allthe fields of the table key.

The following SQL statement loads the buffer for table TMODU, ageneric-1 buffered table:

SELECT * FROM "TMODU" WHERE "FAUNA" = :A0 ORDER BY "FAUNA", "MODIF",

"TABNM", "FELDN", "KOART", "UMSKS"

If the table to be buffered is a pooled table, during buffer loading there isa database access to the table pool in which the table is located.

Pooled table A002 is fully buffered and is located in the KAPOL tablepool. The SQL statement for loading the buffer is:

SELECT "TABNAME", "VARKEY", "DATALN", "VARDATA" FROM "KAPOL" WHERE

"TABNAME" = :A0 ORDER BY "TABNAME", "VARKEY"

ATAB and KAPOL are important table pools. ATAB contains many SAPBasis buffered tables (such as T<nnn>), KAPOL contains many conditiontables (such as A<nnn>).

Summary

Buffering tables in the main memory of the SAP application server is animportant instrument for optimizing performance. Table buffering is onlyeffective if the following conditions are met:

� The table must be relatively small.

� The table must be accessed relatively often.

� The invalidation rate for the table must be low.

� The short-term inconsistency between the application servers, broughtabout by asynchronous buffer synchronization, can be tolerated.

� Access to the table must be using the first "n" fields of the primary key,where "n" is less than the total number of key fields.

Summary 309

The synchronization and loading processes of incorrectly buffered tablescan cause a reduction in performance that far outweighs any gains inperformance provided by buffering. In this case, users will sporadicallynotice long response times in a transaction that normally runs quickly.

The Table Calls Statistics Monitor is the central tool for monitoring SAPtable buffering. Using these statistics it can be decided whether thebuffering of a particular table is effective or not. The main statistics tolook at are the number of ABAP requests (ABAP/IV processor requests),the size of tables (buffer size [bytes]), the number of invalidations and thedatabase activity (DB activity: Rows affected). Figure 9.8 shows thecorresponding procedure roadmap for analyzing table buffering.

Important terms in this chapter

After studying this chapter you should be familiar with the followingterms:

� Generic regions of a table

� Single record buffering, generic buffering

� Buffer synchronization

� Invalidation and displacement

Questions

1. Which of the following factors are reasons for not activating fullbuffering on a table?

a) The table is very large.

Figure 9.8 Procedure roadmap for analyzing the efficiency of table buffering

Table Access Statistics (Transaction ST10 with option All tables)

Many Invalidations for buffered tables?

See rules on when to buffer tables and, if required deactivate buffering

Large Buffer size for buffered tables?


Many Rows affected for buffered tables?


Many Total ABAP Processor requests for non-buffered tables?

See rules on when to buffer tables and, if required activate buffering

?

?

?

?


b) In the SQL statement most frequently used to access the table, thefirst two of five key fields are contained in an equals condition.

c) The table is changed frequently.

2. Which statements apply in regard to buffer synchronization?

a) During buffer synchronization, the application server executing thechange instructs the message server to communicate the changemade to the buffered table to the other application servers.

b) After a transaction changes a buffered table, the change transactionmust first be completed with a database commit before the tablecan be reloaded into the buffer.

c) In a central system the SAP profile parameter rdisp/bufrefmodemust be set to "sendoff, exeoff".

d) In a central system, the entries in the table buffer are neverinvalidated, because the table buffer is changed synchronously aftera database change operation.

sap monitoring

Documents

sap service

sap work process

shared sql

single record

local sap

table calls

asynchronous

single record