ABAP/4 Performance Tuning

Tips and Tricks

Author : Mario Opsomer

Last Updated : January 7, 1998

Table Of Contents

1) Incorporate CHECK statements for table fields into the WHERE clause of the SELECT statement.
2) Do NOT use Logical Databases as programs using Logical Databases are much harder to tune.
3) Avoid the usage of the nested select construct - Use views or the 4.x join construct instead.
4) Check whether your program uses the appropriate indexes using SQL Trace (ST05) - Explain SQL.
5) All programs run fine on small systems like DE2, so include performance tests on the QA systems.
6) Pay attention with clustered and pooled tables. These often cause unexpected performance issues.
7) Only SELECT the columns really needed instead of transferring all columns with SELECT *.
8) Make sure the users will use the program properly by including the available selection options.
9) Only use an ORDER BY in your SELECT if the order matches the index which should be used.
10) Avoid reading the same data rows over and over again from the database - read data once in itab.
11) Avoid complex tests in the WHERE clause of SELECTs as these can confuse the db optimizer.
12) Use aggregate functions for calculations/summations in the SELECT (whenever possible).
13) Use SELECT SINGLE instead of SELECT-ENDSELECT whenever possible.
14) Check whether you are using the right tables to retrieve the information needed by your program.
15) If the performance problem does not seem to be db-related, use one of the other Workbench Tools.

16) Check whether the runtime matches the amount of data to be retrieved from the database.
Appendix 1 : Example Explanation of an Informix Statement (=> SAP Documentation).
Appendix 2 : SQL Explain examples - How the SQL syntax used affects performance.
Appendix 3 : SQL Trace output example - Explanation of database operation types.
Appendix 4 : SQL Explain output - How user behavior affects performance.
Appendix 5 : Output from program ZZBCR006 for table MSEG on PR1.
Appendix 6 : List of the biggest database tables on the PR1 system (status on January 7, 1998).
Appendix 7 : Same as in Appendix 6, but sorted by category-tablename (status on January 7, 1998).
1) Incorporate CHECK statements for table fields into the WHERE clause of the SELECT statement.

The database can then use an index (if possible) and network load is considerably less.
There are cases in which such changes resulted in programs running 5 times faster.

select * from table.

check field1 = 001.
endselect.

should become

select * from table where field1 = 001.

endselect.

2) Do NOT use Logical Databases as programs using Logical Databases are much harder to tune.

It is very hard to tune programs using a logical database (=> not enough flexibility).
CHECK statements must often be placed behind the GET statements, and as mentioned
in tip 1, CHECK statements should be replaced by additional tests in the WHERE-clause
which is not possible when working with one of the standard SAP logical databases.

3) Avoid the usage of the nested select construct - Use views or the 4.x join construct instead.

Each SELECT statement involves a considerable amount of overhead (on db and network).
Using the traditional nested select construct generates a lot of SELECT statements,
especially if the inner select statements are often executed, causing bad performance.
By defining views which combine (join) the different involved tables, the program only
executes one select statement (against the view) reducing the db and network overhead.
In 4.x, SAP introduced the join construct into their ABAP/4 Open SQL, so you do not
need to define views anymore to avoid the traditional terrible nested loop construct.
When using views or the join construct, the db can also better optimize the disk accesses.

select v~vbeln v~auart v~bname v~kunnr

p~posnr p~matnr p~kwmeng p~meins e~etenr
into table itab
from vbak as v inner join vbap as p on v~vbeln = p~vbeln
inner join vbep as e on p ~vbeln = e~vbeln and p~posnr = e~posnr
where v~vbeln between '0000000000' and '0000001000'.

In the above example, an inner join is done between three tables (vbak, vbap, vbep).
This method is really much faster than having three separate SELECT statements.
(The complete source of program ZZSTU06E can be found on the DE2 system.)

IMPORTANT REMARK :
SAP did not only introduce the INNER JOIN into their ABAP/4 Open SQL in SAP 4.x,
but also the following very useful ANSI-SQL constructs : the OUTER JOIN, SUBQUERIES
and the GROUP BY - HAVING clause.
The difference between an INNER JOIN and an OUTER JOIN is the following. If a query on
an INNER JOIN of VBAK (outer table) and VBAP (inner table) finds a record in VBAK but
no matching records in VBAP, then no data is retrieved from the database because the inner
table is empty. If you still want to keep VBAK rows for which there are no matching VBAP
rows, you need to use the OUTER JOIN construct available in ABAP/4 Open SQL in 4.x..
While the ABAP/4 Open SQL was only covering a small part of the ANSI-SQL standard
in previous SAP releases, it is now covering most of the ANSI-SQL standard (at last).
Please try to understand and use these techniques, as they make programs more efficient !
If you are not familiar with SQL yet, borrow or buy a good book on SQL and study it.
4) Check whether your program uses the appropriate indexes using SQL Trace (ST05) - Explain SQL.

Learn how to use the SQL Trace tool (SAP Extended Help : BC ABAP Workbench Tools).
Learn how to use the Explain SQL function of SQL Trace and understand its output.

Appendix 1 is a copy of the topic called Example Explanation of an Informix Statement

from the SAP Extended Help : BC ABAP Workbench Tools.

It is CRUCIAL that programs use the proper index and use as much as possible of that index.
You can only verify this by using the SQL Trace EXPLAIN SQL function for statements.

Appendix 2 shows a number of select statements against the central FINANCE table BKPF.
Query 1 is phrased in three different ways, each time returning the same results,
but the runtime varies depending on the way the SQL is presented to Informix.
The runtime differences are small on DE2, but on QA2 the first version completes
in 2 minutes, while the other two version require 18 minutes (9 times longer !).
Query 2 is phrased in two different ways, each time returning the same results. The
runtime differences are again small on DE2 (1.5 seconds versus 9 seconds). When
running the same selects on QA2, the first version completes in 4 seconds while the
second version of the SELECT takes more than 19 minutes (~ 300 times slower !).

The Estimated Cost line indicates how expensive the SQL statement is for Informix.
It is just a number, but the higher that number, the longer the query probably will take.
Costs above 100,000 can be considered high (especially if # of rows returned should be low).
If a select is repeatedly executed (e.g. within a nested loop), the cost should be below 100.
Keep in mind that the estimated costs are different for different SAP systems (DE2 vs QA1).
The two thresholds mentioned here are thresholds for our bigger systems (QA# and PR1).
The Estimated Cost thresholds for DE2 are even much lower as there is less data on DE2.
The Index Keys line in the Explain SQL output shows the fields of the index being used.
The Lower Index Filter in the output shows how much is used for positioning within index.
Its important that a lot of tests are included there (and not in the Filters line of the output).

Appendix 3 shows the output from an SQL Trace on an execution of program ZZGXRC11.
It also contains an explanation of the different types of database operations.

Appendix 4 shows another example of an SQL statement with its Explain SQL output.
Because the user forgot to fill in the year and two other FI-GLX fields for which
there is only one valid value, the runtime was several hours on PR1. If the user
had filled in these fields, the runtime would have been less than 5 minutes on PR1.

Keep in mind that developpers can guide the user in the proper direction by using
the options DEFAULT and OBLIGATORY on the PARAMETER statement and
by using the options DEFAULT, OBLIGATORY, NO-EXTENSION and NO
INTERVALS on the SELECT-OPTIONS statements. The SAP environment should
be considered as an OLTP environment and not as some kind of data warehousing
environment in which the user can ask whatever they want. The developper should
really ask whether it should be allowed to run the programs without test on the most
important fields such as company code, ledger, plant, fiscal year, etc. Quite often, if
the user does not fill in a good test on these fields, the performance is really terrible.

You can run program ZZBCR006 to find technical information about a table which must be
accessed in your program. The output shows the number of rows and the size of the table.
It also shows in a single screen all indexes on the given table. Keep in mind that ZZBCR006
shows the output for the currently used SAP system, so you need to run it on QA# or PR1, if
you want to know more about the technical details of the table on our bigger SAP systems.

Appendix 5 shows the output of running program ZZBCR006 for the MSEG table on PR1.
5) All programs run fine on small systems like DE2, so include performance tests on the QA systems.

As the amount of data is very small in the DE2 db, most programs run very fast on DE2 !
So you really need to check the performance on our QA systems which are copies of PR1 !

Compare the amount of data you expect to be needed by the program run with the runtime.
If the runtime is not reflecting the amount of data needed by the run, check with SQL Trace.
In most cases, unexpected high runtimes are caused by too much data being read from the db.
It is for example possible that data is read for multiple plants and periods, although the user
only asked for data for a single plant-period combination, because the wrong index is used.

6) Pay attention with clustered and pooled tables. These often cause unexpected performance issues.

Some of the SAP tables are not transparant, but pooled or clustered. Be aware of this !
There are a lot of limitations on how such tables can be accessed. You can not include such
tables in database views and join constructs. The FI-GL table BSEG, which is one of our
biggest PR1 tables, is an example of a clustered table. At the database-level, there is no table
called BSEG, but instead RFBLG is being used for the BSEG data. Most of the fields known
in BSEG are not known in the database table RFBLG, but are compressed in a VARDATA
field of RFBLG. So tests in the WHERE clause of SELECTs agains BSEG are not used by
the database (e.g. lifnr = vendor account number, hkont = G/L account, kostl = cost center).
As a consequence, these tests are done after the facts similar to using the CHECK statement,
and as already said in tip 1, CHECK statements are worse than tests in the WHERE-clause.

7) Only SELECT the columns really needed instead of transferring all columns with SELECT *.

All fields are transferred over the network with SELECT * although maybe a few are needed.
You can reduce this network overhead by explicitly naming the columns really needed.

8) Make sure the users will use the program properly by including the available selection options.

Developpers can guide the user in the proper direction by using the options DEFAULT and
OBLIGATORY on PARAMETER statements and the options DEFAULT, OBLIGATORY,
NO-EXTENSION and NO INTERVALS on the SELECT-OPTIONS statements.
The SAP environment should be considered as an OLTP environment and not as some kind
of data warehousing environment in which the user can ask whatever they want to.
The developper should really ask whether it should be allowed to run the programs without
tests on the most important fields such as company code, ledger, plant, fiscal year, etc.
If the user does not fill in a good test on these fields, the performance could be terrible !

9) Only use an ORDER BY in your SELECT if the order matches the index which should be used.

If the order you need is different from the order of the fields in the best index, do not use
ORDER BY in the SELECT but read the data rows into an internal table and sort the itab.
If the best index contains the fields in the same order as the one you want for the output,
then you can use the ORDER BY in the SELECT statement (and avoid sorting an itab).

10) Avoid reading the same data rows over and over again from the database - read data once in itab.

In some cases, the same SELECT is run repeatedly, each time reading and returning the
same data rows, especially when using the nested loop construct. Avoid this by reading the
data once into an internal table at the beginning and working with this itab afterwards.
It is much faster to read from an internal table (possibly using binary search) each time
which is in memory, than to run a SELECT against the database over and over again.
11) Avoid complex tests in the WHERE clause of SELECTs as these can confuse the db optimizer.

It is a fact that complex WHERE-clauses often confuse the optimizers of relational DBMS.
This is true for all RDBMS, so also for the one we are using for our SAP systems (Informix).

Some of the things which should be avoided in the WHERE clause of SELECTs are :

- OR-constructs : Never include OR-tests (for important fields) in your SELECTs !

Example of SELECT for which an alternative solution must be found :

select * from bsik

where xblnr in xblnr
and budat in date
and ( lifnr between 'PD0000' and 'PD9999' OR
lifnr between 'PR0000' and 'PR9999' ).

Use the IN-construct instead of the OR-construct, whenever possible !

select * from zzrefa1

where ( rldnr = C1 or rldnr = S1 ) and
bukrs = 4150 and ryear = 1999 and poper = 003

should become

select * from zzrefa1

where rldnr in ( C1 , S1 ) and
bukrs = 4150 and ryear = 1999 and poper = 003

IMPORTANT REMARK RELATED TO THE OR-CONSTRUCT :

Keep in mind that OR-tests can also be generated when the users fill
in complex combinations (e.g. multiple range-tests for a given field).
You can avoid that users use difficult combinations by using the options of
the SELECT-OPTIONS statement which were mentioned earlier (cfr. tip
8).

- NOT-conditions in a SELECT statement can not be processed via an index.

- Do NOT use the >= AND <= construct, but use BETWEEN construct instead.
The results will of course be identical, performance will however be improved !

select * from tab where field >= val1 and field <= val2

should become

select * from tab where field between val1 and val2

Always check whether the database access path (index) choosen by the cost-based Informix
optimizer is the most efficient one, by running an SQL trace in one of our QA environments.
12) Use aggregate functions for calculations/summations in the SELECT (whenever possible).

If you want to find the minimum/maimum/average value or sum of a db column or want to

find the number of rows (COUNT aggregate function), use a SELECT list with aggregate
functions instead of computing the aggregates yourself. When you do the calculations in
your program, you need to read all data rows from the db into the program (over the
network),
causing a considerable load on the network.

You can of course combine these aggregate functions with the GROUP BY clause to find
the minimum/maximum/average/sum/rowcount, grouped by one or more table columns.
The following SELECT will list the number of accounting document headers (rows in BKPF)
with document type EM for FY1999, for each of the company codes,

select mandt, bukrs, count(*) from bkpf

where blart = EM and gjahr = 1999
group by mandt, bukrs

In SAP 4.x, it is even possible to use the functions combined with GROUP BY - HAVING.
The following SELECT is similar to previous one, but only the companies fore which there
are more than 10000 accounting documents of type EM for FY1999 will be listed, again
reducing the network load and also avoiding additional coding in the ABAP/4 program.

select mandt, bukrs, count(*) from bkpf

where blart = EM and gjahr = 1999
group by mandt, bukrs having count(*) > 10000

13) Use SELECT SINGLE instead of SELECT-ENDSELECT whenever possible.

If you are interested in exactly one row of the db table or view, use the SELECT SINGLE
statement instead of the SELECT-ENDSELECT-loop, as SELECT SINGLE requires one
communication with the database system whereas SELECT-ENDSELECT needs two.

14) Check whether you are using the right tables to retrieve the information needed by your program.

It is often difficult to find the proper tables as SAP R/3 has over 10,000 tables and views.
In some cases, using different tables might give you the same information in less time.
In other cases, performance improvements are obtained by involving another database table
(going straight from A to B might be slower, than going from A to C and then from C to B).

In FI-GL, the secondary index tables BSIS, BSAS, BSIK, BSAK, BSID and BSAD often are
a better starting point to retrieve accounting document information than using the traditional
method (directly going from BKPF (accounting document header table) to the BSEG table).
For example, FI-GL programs which are normally run for a specific vendor account number
better start accessing BSAK and BSIK first, before accessing BKPF and BSEG, instead of
starting with the BKPF table. As the BKPF table does not contain vendor account number
information a lot of accounting documents are read which are not needed as they do not
match the vendor account specified by the user, in case BKPF is used as starting point.
In case BSAK and BSIK are used, only the accounting documents matching the specified
vendor account number will be read, reducing the runtime from several hours to minutes.

15) If the performance problem does not seem to be db-related, use one of the other Workbench Tools.

The SQL Trace tool (ST05 transaction) is the perfect utility for detecting and solving
performance issues which are caused by inefficient database accesses. If however, the db
accesses do not seem to cause the performance problem, use another tool such as the ABAP
Debugger, the Runtime Analyzer (SE30), the Enqueue Trace and the RFC Trace. The RFC
Trace and Enqueue Trace are new in SAP 4.x. They can be started using transaction ST05.
16) Check whether the runtime matches the amount of data to be retrieved from the database.

When running performance tests for a program in one of the QA environments, check
whether the runtime reflects the amount of data which is needed from the database.
A runtime of one hour is acceptable when all accounting data is requested for a whole fiscal
year for one of our bigger company codes. However, if the runtime is one hour when you
expect that only a limited amount of data must be read, than there is something wrong with
the way the program accesses the database tables (e.g. wrong database index is being used,
not enough GOOD tests are available for the key fields of the index).

Suppose the Informix SELECT generated by a program is the following (this Informix
SELECT is for example executed when a user runs the transaction FB03 with a reference
document number (XBLNR column in BKPF table) without filling in a company code test.

select * from bkpf where mandt="008" and bstat=" " and xblnr = 415000106410"

BKPF contains only one index in which column XBLNR is included, so you want and expect
the Informix optimizer to use that index. BKPF is a big table; NOT using that BKPF index
would be terrible for performance.

index .bkpf______1 on bkpf (mandt,bukrs,bstat,xblnr)

However, due to the absence of a test on company code, Informix does not choose this index,
but another one which does not even include XBLNR, causing this transaction to run for
hours.
If the user had specified a company code test, the transaction completes within a few seconds.

Case 1 : Output from Explain SQL when user only specifies an XBLNR test :

select * from bkpf where mandt="008" and bstat=" " and xblnr = "0000415000106410"

Estimated Cost: 8051245 Estimated # of Rows Returned: 2

1) bkpf: INDEX PATH

Filters: (bstat = ' ' AND xblnr = '0000415000106410' )
(1) Index Keys: mandt bukrs cpudt bstat
Lower Index Filter: mandt = '008'

As you can see, the estimated cost is very high (8,051,245) and the index choosen is not the
one we expected. The only test Informix uses is the test on client (mandt), so we will read
ALL accounting document headers (BKPF rows) for ALL companies for ALL fiscal years.
With the sizes of finance tables in our QA and PR1 environments, this is really a disaster.

Case 2 : Output from Explain SQL when user specifies an XBLNR and BUKRS test :

select * from bkpf

where mandt="008" and bukrs="4150" and bstat=" " and xblnr = "0000415000106410"

Estimated Cost: 5 Estimated # of Rows Returned: 1

1) bkpf: INDEX PATH

(1) Index Keys: mandt bukrs bstat xblnr
Lower Index Filter: (mandt = '008' AND (bukrs = '4150' AND
(bstat = ' ' AND xblnr = '0000415000106410' ) ) )

As you can see, the estimated cost is now only 5 and the proper index is used. All the tests
which are specified in the WHERE-clause can be used for fast access to the data rows. As
daid before, the runtime is here only a few seconds, while the previous case runs for hours !
Appendix 1 : Example Explanation of an Informix Statement (=> SAP Documentation).

You can use the SQL Trace facility to view explanations of specific Informix statements.
From within an SQL trace file display, you use the Explain SQL function to display more
information about a specific database request. The Explain function is available only for
PREPARE and REOPEN operations. To analyze a statement:

Place the cursor on a line containing the database request you want explained.
Choose Explain..
The Explain screen shows you the database's strategy for carrying out the selected
operation.

If you are working with an Informix database and you display the explanation for the following
statement:

select owner from systables where tabname = 'atab'

The system provides the following explanation:

Execution plan of a select statement (Online Optimizer)

QUERY:
SELECT OWNER
FROM SYSTABLES
WHERE TABNAME = ATAB

Estimated Cost: 1
Estimated # of Rows Returned: 1

1) informix.systables: INDEX PATH

(1) Index Keys: tabname owner (Key-Only)
Lower Index Filter: informix.systables.tabname = ATAB

The fields in the explanation have the following meanings:

QUERY Identifies the SQL statement that was traced.

Estimated Cost Estimates the database expenditure required to execute the statement.
The cost-based optimizer estimates this value in terms of the I/O and CPU
required by the statement. The larger the Estimated Cost the greater
the expenditure.
Estimated # of Rows Estimates the number of table rows that the SQL statement will return.
Returned:

Immediately below the number of rows returned is the selected execution plan. In the above
example, the execution plan is as follows:

1) informix.systables: INDEX PATH

The 1) indicates that the system processes the systables table as the first step of the
execution plan. For queries that span several tables (views and joins), the numbering
sequence indicates the order the system processes the tables. In this example, only a single
step was needed.
The execution plan specifies the type of table access. In the above example, the access was
the INDEX PATH . Access to the required data row is made using the index of the
systables table. Normally, the execution plan uses the primary key as an index. Every
transparent table in the ABAP Dictionary has a primary key and the system automatically
creates an index for this key.

For this example, the system did not need to read the row that corresponds to the index key.
The information that was required was present in the key itself. The explanation indicates this
using the phrase Key-Only as follows:

(1) Index Keys: tabname owner (Key-Only)

If a SELECT statement is specified without a fully-qualified key, the database may need to
read the relevant rows with a FULL TABLE SCAN.

In this case, you will not see an index in the SQL-Explain output but instead you will see
something like the following:

1) informix.systables: SEQUENTIAL SCAN

This indicates that a read of the entire table is necessary (FULL TABLE SCAN).

With more complex operations, where the combination of results from several SELECTS on
different tables is required, you will see further strategies mentioned (such as MERGE JOIN,
DYNAMIC HASH JOIN). These refer to the join strategy chosen by the optimizer.

In case, you do not understand the output from the Explain SQL function, consult your
DBA.
Appendix 2 : SQL Explain examples - How the SQL syntax used affects performance.

primary key index "sapr3".bkpf______0 (mandt,bukrs,belnr,gjahr)

index "sapr3".bkpf______1 on "sapr3".bkpf (mandt,bukrs,bstat,xblnr);
index "sapr3".bkpf______2 on "sapr3".bkpf (mandt,bukrs,bstat,budat);
index "sapr3".bkpf___j on "sapr3".bkpf (blart,cpudt);

QUERY 1 : select * from bkpf where mandt="008" and bukrs="4025" and bstat=" " and
budat between "19960101" and "19960228"

Estimated Cost: 1 Estimated # of Rows Returned: 1 Time : 1.81 sec

1) bkpf: INDEX PATH

(1) Index Keys: mandt bukrs bstat budat

Lower Index Filter: (bkpf.mandt = '008' AND (bkpf.bukrs = '4025' AND
(bkpf.bstat = ' ' AND bkpf.budat >= '19960101' ) ) )
Upper Index Filter: bkpf.budat <= '19960228'

QUERY 1 b : select * from bkpf where mandt="008" and bukrs="4025" and

budat between "19960101" and "19960228"

Estimated Cost: 525 Estimated # of Rows Returned: 1 Time : 2.74 sec

1) bkpf: INDEX PATH

Filters: (bkpf.budat >= '19960101' AND bkpf.budat <= '19960228')

(1) Index Keys: mandt bukrs bstat budat

Lower Index Filter: (bkpf.mandt = '008' AND bkpf.bukrs = '4025' )

QUERY 1 c : select * from bkpf where mandt="008" and bukrs="4025" and bstat=" " and
( budat between "19960101" and "19960131" OR
budat between "19960201" and "19960228" )

Estimated Cost: 19 Estimated # of Rows Returned: 1 Time : 3.70 sec

1) bkpf: INDEX PATH

Filters: ((bkpf.budat >= '19960101' AND bkpf.budat <= '19960131') OR

(bkpf.budat >= '19960201' AND bkpf.budat <= '19960228' ) )

(1) Index Keys: mandt bukrs bstat budat

Lower Index Filter: (bkpf.mandt = '008' AND (bkpf.bukrs = '4025' AND
bkpf.bstat = ' ' ) )
primary key index "sapr3".bkpf______0 (mandt,bukrs,belnr,gjahr)
index "sapr3".bkpf______1 on "sapr3".bkpf (mandt,bukrs,bstat,xblnr);
index "sapr3".bkpf______2 on "sapr3".bkpf (mandt,bukrs,bstat,budat);
index "sapr3".bkpf___j on "sapr3".bkpf (blart,cpudt);

QUERY 2 : select * from bkpf

where mandt="008" and blart in ("N1","N2") and cpudt="19970127"

Estimated Cost: 29 Estimated # of Rows Returned: 15 Time : 1.48 sec

1) bkpf: INDEX PATH

Filters: bkpf.mandt = '008'

(1) Index Keys: blart cpudt

Lower Index Filter: (bkpf.blart = 'N1' AND bkpf.cpudt = '19970127' )

(2) Index Keys: blart cpudt

Lower Index Filter: (bkpf.blart = 'N2' AND bkpf.cpudt = '19970127' )

QUERY 2 b : select * from bkpf

where mandt="008" and blart between "N1" and "N2" and cpudt="19970127"

Estimated Cost: 20914 Estimated # of Rows Returned: 15 Time : 9.00 sec

1) bkpf: INDEX PATH

Filters: (bkpf.blart >= 'N1' AND (bkpf.blart <= 'N2' AND bkpf.cpudt = '19970127' ) )

(1) Index Keys: mandt bukrs bstat budat

Lower Index Filter: bkpf.mandt = '008'

---------------------------------------------------------------------------------------------------------------------------

SAME QUERIES EXECUTED ON QA2, WHICH IS A COPY OF PR1 :

QUERY 1 : Estimated Cost: 50334 Estimated #Rows Returned: 88711 Time : 02:03
QUERY 1 b : Estimated Cost: 1212170 Estimated #Rows Returned: 88755 Time : 18:40
QUERY 1 c : Estimated Cost: 1212170 Estimated #Rows Returned: 87853 Time : 18:35
QUERY 2 : Estimated Cost: 2384 Estimated #Rows Returned: 5110 Time : 00:04
QUERY 2 b : Estimated Cost: 2385858 Estimated #Rows Returned: 5114 Time : 19:14

Query 1 is phrased in three different ways, each time returning the same results (BKPF data rows),
but the runtime varies depending on the way the SQL is presented to Informix. The runtime
differences are not that big on DE2, but on QA2 the first version completes in 2 minutes, while the
other two versions require 18 minutes (~ 9 times longer !).

Query 2 is phrased in two different ways, each time returning the same results (BKPF data rows).
The runtime differences are again not that spectacular on DE2 (1.5 seconds versus 9 seconds).
However, when running the same two selects on QA2, the first version completes in 4 seconds while
the second version of the SELECT takes more than 19 minutes (~ 300 times slower !).
Appendix 3 : SQL Trace output example - Explanation of database operation types.

Executed the ABAP/4 program ZZGXRC11 on DE2 with some selection criteria :

Transaction/Report= SE38 PID= 0000004436 Client= 008 User= MOPSOMER

hh:mm:ss.ms Duration Program Table Operation Curs Records Ret.code Db Request

08:48:54.715 1,188 ZZGXRC11 FREE S_48&

08:48:54.717 2,564 ZZGXRC11 FREE C_48&
08:48:54.719 13,750 ZZGXRC11 ZZREFA2 PREPARE 48 SELECT
08:48:54.733 478 ZZREFA2 DECLARE 48
08:48:54.734 150 ZZGXRC11 ZZREFA2 OPEN 48 SELECT
08:48:54.734 7,459,325 ZZGXRC11 ZZREFA2 FETCH 48 58 0 Array: 58
08:49:02.204 111,273 ZZGXRC11 ZZREFA2 FETCH 48 58 0 Array: 58
08:49:02.325 701,185 ZZGXRC11 ZZREFA2 FETCH 48 58 0 Array: 58
08:49:03.037 13587,000 ZZGXRC11 ZZREFA2 FETCH 48 58 0 Array: 58
08:49:16.634 30,407 ZZGXRC11 ZZREFA2 FETCH 48 58 0 Array: 58
08:49:16.675 359,958 ZZGXRC11 ZZREFA2 FETCH 48 44 0 Array: 58
08:49:17.042 75 ZZGXRC11 ZZREFA2 FETCH 48 0 100 Array: 58
08:49:17.042 91 ZZGXRC11 ZZREFA2 CLOSE 48

The SQL trace tool measures the following database requests :

DECLARE XY :
Creates a new cursor within an SAP work process and assigns a unique cursor ID.
The SAP System and the database system use these cursor IDs to communicate.

PREPARE XY stmt SELECT WHERE condition :

Translates the corresponding SQL stmt and determines how the stmt is carried out.

OPEN XY SELECT WHERE condition :

Opens a cursor for the prepared statement. OPEN fills in the exact values to use
for the database access. OPEN is used only for SELECT statements.
REOPEN XY SELECT WHERE condition :
Reopens a cursor that the system prepared for a specific stmt and transfers
the new input values to the database.

FETCH XY :
Moves the cursor through the selected set of retrieved records in the db that
correspond to the condition specified with OPEN. FETCH transfers records from
the db to the program interface. You can execute a single FETCH or an array FETCH.
A single FETCH transfers a single record to the program interface, for example,
with SELECT SINGLE. An array FETCH transfers records in packets, not individually.

EXEC XY statement :
Like OPEN, except the stmts executed with EXEC change the data in the
database, for example via UPDATE, DELETE, or INSERT.
REEXEC XY statement :
Reopens a stmt the system already prepared for a previous EXEC stmt.

Check for high values in the column duration. If any, look at the corresponding SQL, by
positioning the cursor on the line containing OPEN as operation, and choose Explain SQL. You
will receive information from the Informix optimizer similar to the output shown in the two previous
appendixes.
Appendix 4 : SQL Explain output - How user behavior affects performance.

Choose EXPLAIN SQL for OPEN statement :

Execution plan of a select statement (Online optimizer)

QUERY:

SELECT RCLNT , GL_SIRID , RLDNR , RRCTY , RVERS , RYEAR , RTCUR ,

RUNIT , DRCRK , POPER , DOCCT , DOCNR , DOCLN , RBUKRS ,
RACCT , RZZPER , RZZSAR , RZZSDF , RZZFUN , RZZSOP , RZZPDV ,
RZZMAG , RBUSA , RKOSAR , RZZTAX , RZZDEP , RVBUND , SBUKRS ,
SACCT , SZZPER , SZZSAR , SZZSDF , SZZFUN , SZZSOP , SZZPDV ,
SZZMAG , SBUSA , SKOSAR , SZZTAX , SZZDEP , SVBUND , TSL ,
HSL , KSL , MSL , ASL , AUNIT , SGTXT , AUTOM , DOCTY , ACTIV ,
BVORG , BUDAT , WSDAT , REFDOCNR , REFRYEAR , REFDOCLN , REFDOCCT ,
REFACTIV , CPUDT , CPUTM , USNAM , AWTYP , AWORG , LOGSYS
FROM ZZREFA2
WHERE RCLNT = '008' AND RLDNR = 'R1' AND RBUKRS = '1000' AND
POPER = '010' AND USNAM BETWEEN 'A' AND 'C'

Estimated Cost: 60841

Estimated # of Rows Returned: 28

1) sapr3.zzrefa2: INDEX PATH

Filters: (sapr3.zzrefa2.rldnr = 'R1' AND

(sapr3.zzrefa2.rbukrs = '1000' AND
(sapr3.zzrefa2.poper = '010' AND
(sapr3.zzrefa2.usnam >= 'A' AND sapr3.zzrefa2.usnam <= 'C'))))

(1) Index Keys: rclnt gl_sirid

Lower Index Filter: sapr3.zzrefa2.rclnt = '008'

Conclusion of the investigation of the SQL trace output :

- The run did use a "bad" index (rclnt,gl_sirid) to answer the query.

- Index (rclnt,rldnr,rrcty,rvers,ryear,rbukrs,racct,rzzper) is better

if the user (or the pgm) had also entered a value for rrcty and rvers
(both fields only have one possible value anyway in Raychem's systems)
and if user also entered year (instead of only the month of the year).

- This run took more than 20 seconds on DE2 (zzrefa2 is small on DE2)
(on QA1, QA2 and PR1, the same run would have taken several hours !).

- With appropriate values for the screen fields rvers, rrcty and ryear,
the runtime would have been less than 1 second. On QA1, QA2 and PR1,
the runtime would have been a couple of minutes instead of hours.
Appendix 5 : Output from program ZZBCR006 for table MSEG on PR1.

Technical Information for Informix Table MSEG on SAP System PR1

The technical information for a given table is different on each SAP system.

Db Table Name Number of Rows Total Size (Kb) No of Extents

MSEG 2.516.229 2.735.360 2

DBA-defined size category classification for Informix tables [1=S -> 5=XXL].

DBA-defined size category for table MSEG on PR1 : 4

Db Table Name Index Name Position Column Name

MSEG primary key index 1 mandt

2 mblnr
3 mjahr
4 zeile

MSEG mseg___9 1 mandt

2 werks
3 aufnr
4 bwart
5 mblnr

MSEG mseg______m 1 mandt

2 matnr
3 werks
4 lgort
5 bwart
6 sobkz

Remark : It is important to know what the size is of a table which needs to be accessed in your
program. For big tables, not using the right index or not using enough fields of the right index
could cause a significant performance degradation. Try to have EQUALITY-tests on the leading
fields of the index you want to be used by your program. Missing a good test on a column which
is close to the beginning of an index can have a significant impact on the performance of your
program. In tip 16, this was illustrated with an example. In the example, the fact that there was
no test on company code caused the program to run for hours. If the user had filled in a test on
company code as well, the same program would have been completed in less than 5 seconds !
Appendix 6 : List of the biggest database tables on the PR1 system (status on January 7, 1998).

TABLENAME APPLCAT NUMROWS KBYTES TYPE SAP TABLE DESCRIPTION

zzrefa2 glx 50.050.802 27.361.280 TRANS CCARD GLX Line Items (Actual)
zzrefa1 glx 50.621.017 25.804.944 TRANS Operational GLX GL Line Items (Actual)
bsis fi 37.380.561 23.490.576 TRANS Accounting: Secondary index for G/L accounts
rfblg fi 13.456.650 20.951.056 CLUST Cluster fr Buchhaltungsbeleg
glpca pca 11.938.097 12.800.016 TRANS EC-PCA: Actual Line Items
cosb co 5.581.813 12.483.000 TRANS CO Object: Total Variances/Results Analyses
coss co 4.463.354 10.994.734 TRANS CO Object: Cost Totals - Internal Postings
bkpf fi 13.370.140 9.850.896 TRANS Accounting document header
cosp co 3.489.332 7.741.440 TRANS CO Object: Cost Totals - External Postings
bsas fi 14.568.621 7.475.200 TRANS Accounting: Secondary index for G/L accounts (cleared items)
zzrefa1 glx 0 7.415.372 TRANS Operational GLX GL Line Items (Actual)
zzreft1 glx 3.189.999 7.208.960 TRANS Operational GLX Summary Table
coep co 6.660.072 5.509.120 TRANS CO object: period-related line items
bsad fi 3.753.865 4.771.840 TRANS Accounting: Secondary index for customers (cleared items)
tst03 system 274.140 4.546.560 TRANS TemSe data
cdcls fi 7.871.606 4.096.000 CLUST Clusterstruktur fr nderungsbelege
glidxa glx 25.576.343 4.034.560 TRANS Index to Find FI-SL Documents Based on AWKEY
m_zzrd shared 7.261.570 3.696.640
bsak fi 2.880.545 3.600.000 TRANS Accounting: Secondary index for vendors (cleared items)
acctit fi 2.542.648 2.744.320 TRANS Compressed data from Accounting document
mseg esprit 2.523.993 2.735.360 TRANS Document Segment: Material
reguh fi 1.212.783 2.662.400 TRANS Settlement data from payment program
zzreft2 glx 1.935.038 2.375.680 TRANS CCARD GLX Summary Table
cmfp shared 4.199.921 2.334.720 TRANS Storage Structure for Errors Collected
nast esprit 1.775.979 2.252.800 TRANS Message status
apqd system 3.956.610 1.966.080 TRANS DATA DEFINITION Queue
dbtabprt shared 2.931.468 1.515.520 TRANS Table of log records for table tupel changes
arch_idx shared 6.565.295 1.413.120 TRANS Index table for data object selection
anlp fi 3.693.230 1.372.176 TRANS Asset periodic values
stxh shared 2.623.399 1.367.680 TRANS STXD SAPscript text file header
vbfs esprit 3.991.126 1.320.304 TRANS Error Log for Collective Processing
ausp shared 1.977.973 1.184.400 TRANS Characteristic Values
ttxy shared 490.851 1.057.110 TRANS External tax interface: tax information
reguc fi 1.213.107 1.038.626 CLUST Cluster fr Einzelpositionen der Zahlungsregulierung
swelog shared 1.442.456 1.003.520 TRANS Table for entries of the event log
ltap esprit 919.075 993.280 TRANS Transfer order item
qamv esprit 848.665 947.750 TRANS Characteristic specifications for inspection processing
chvw esprit 1.515.660 946.426 TRANS Table CHVW for Batch Where-Used List
vbfa esprit 3.097.763 849.936 TRANS Sales Document Flow
anlc fi 1.095.323 819.216 TRANS Asset-value fields
acctcr fi 5.085.296 808.960 TRANS Compressed data from Acctg document - currencies
bsip fi 2.765.143 798.736 TRANS Index for vendor validation of double documents
stxl shared 1.374.046 778.256 TRANS STXD SAPscript text file lines
cobk co 2.139.287 737.296 TRANS CO Object: Document header
vbrp esprit 635.985 696.320 TRANS Billing: Item Data
moni system 114.235 655.360 TRANS Monitor table MONI
ekpo esprit 564.212 614.416 TRANS Purchasing Document Item
d010s system 228.800 614.416
ckis esprit 509.167 561.020 TRANS Unit Costing: Items / Product Costing: Itemization
bsid fi 381.216 552.976 TRANS Accounting: Secondary index for customers
atab shared 2.047.533 540.410
ekbe esprit 1.622.704 540.298 TRANS History of Purchasing Document
vbpa esprit 2.389.765 539.750 TRANS Sales Document: Partner
edi30c esprit 205.838 538.668 CLUST Intermediate document cluster (data records) from 3.0C
dokclu shared 587.257 513.958 CLUST Docu. lines
jest esprit 4.753.391 501.760 TRANS Object status
s033 esprit 1.270.650 491.520 TRANS Statistics: Movements for Current Stock (Individual Records)
zzrefo1 glx 1.562.324 487.632 TRANS Operational GLX Object Table 1 (Object/Partner)
jcds esprit 3.577.239 485.084 TRANS Change Documents for System/User Statuses (Table JEST)
qasv esprit 2.000.918 476.308 TRANS Sample specifications for inspection processing
prow esprit 5.197.767 471.040 TRANS Forecast Values
plmk esprit 413.424 460.680 TRANS Inspection characteristic
s507 esprit 775.458 450.560 TRANS Polyswitch Forecast
cosl co 381.681 444.316 TRANS CO Object: Activity Type Totals
edids esprit 959.683 423.176 TRANS Status record (EDI IDoc)
snap shared 6.331 409.600 TRANS ABAP/4 snapshot for run-time errors
s792 esprit 771.574 389.120 TRANS Trade&Interco sale,ship daily
koclu esprit 611.908 377.826 CLUST Cluster fr Konditionen in Einkauf und Verkauf
vekp esprit 471.056 368.640 TRANS SD Document: Shipping Unit Header
lips esprit 344.019 368.640 TRANS SD document: Delivery: Item data
resb esprit 270.571 348.160 TRANS Reservation/dependent requirements
mckalkw co 699.608 337.936 TRANS Versions: Cost Itemization
s027 esprit 933.819 335.872 TRANS Product Costs
s793 esprit 664.093 328.730 TRANS Trade&Interco w/o valuat.class
mkpf esprit 1.493.584 327.696 TRANS Header: Material Document
e071k shared 1.025.684 327.696 TRANS Key objects (tables, views,...) of a correction
s508 esprit 504.557 307.200 TRANS Tubing Forecast
qamr esprit 528.035 302.258 TRANS Characteristic results during inspection processing
msta esprit 1.804.234 299.536 TRANS Material Master Status
rf048 esprit 1.787.986 290.246 TRANS Subseq.BA/PC adjustmnt: Index/distributn vector (calculate)
d010l system 15.006 289.176
s504 esprit 531.478 286.720 TRANS Tubing Actuals
kbed esprit 370.433 286.720 TRANS Capacity requirements records
s022 esprit 308.007 277.520 TRANS SFIS: Order Operation Data for Work Center
qals esprit 119.534 272.738 TRANS Inspection lot record
vbap esprit 242.398 271.598 TRANS Sales Document: Item Data
moff esprit 1.191.421 245.776 TRANS Outstanding Material Master Records
afvc esprit 217.693 244.028 TRANS Operation within an order
afru esprit 306.845 235.778 TRANS Order completion confirmations
anla fi 103.861 230.416 TRANS Asset master record-segment
afvv esprit 217.693 229.978 TRANS DB structure of the quantities/dates/values in the operation
ekkn esprit 512.731 225.296 TRANS Account Assignment in Purchasing Document
pcl1 shared 101.244 225.280 TRANS HR Cluster 1
s034 esprit 565.563 217.362 TRANS Statistics: Material Movements for Batches
bsim fi 1.058.366 213.172 TRANS Secondary Index, Documents for Material
funct shared 681.136 204.816 TRANS Function Module Short Texts
ekko esprit 306.692 204.816 TRANS Purchasing Document Header
aufm esprit 581.128 203.808 TRANS Goods movements for order
coepl co 761.886 201.856 TRANS CO Object: Line Items for Activity Types (by Period)
vrpma esprit 635.949 200.924 TRANS SD Index: Billing Items per Material
e071 shared 604.212 199.132 TRANS Objects of a request or task (E070)
glpct pca 158.839 185.788 TRANS EC-PCA: Totals Table
febep fi 262.637 184.336 TRANS Electronic Bank Statement Line Items
eket esprit 595.250 184.336 TRANS Delivery Schedules
s012 esprit 351.753 184.320 TRANS PURCHIS: Purchasing Statistics
plpo esprit 85.149 181.168 TRANS Task list - operation/activity
sww_contob shared 471.506 180.256 TRANS Container Cont. for Work Item Data Container (Only Objects)
coej co 81.384 170.796 TRANS CO object: year-related line items
todir shared 409.588 163.856 TRANS Switch object list
dokhl shared 626.356 163.856 TRANS Documentation: Headers
vbdata esprit 64.587 161.792 TRANS Update data
vbdata esprit 64.587 161.792 TRANS Update data
z9mkl esprit 435.547 158.256 TRANS Material Group Conversion - Log Table
marc esprit 209.481 157.512 TRANS Material Master: C Segment
mbew esprit 208.169 157.508 TRANS Material Valuation
likp esprit 142.816 155.640 TRANS SD Document: Delivery Header Data
tbtcp shared 112.523 155.000 TRANS Batch job step overview
bsik fi 79.441 154.736 TRANS Accounting: Secondary index for vendors
qasr esprit 267.086 153.336 TRANS Sample results for inspection characteristics
vbep esprit 384.264 152.208 TRANS Sales Document: Schedule Line Data
ltak esprit 573.728 146.432 TRANS WM transfer order header
zs012 esprit 231.976 143.376 TRANS PURCHIS: Purchasing Statistics
dsyat shared 383.307 143.376 TRANS Structures: Texts for Maintenance Structure
dd03l system 517.645 143.376 TRANS Table Fields
coka co 708.217 143.376 TRANS CO Object: Cost Element Control Data
zzrefo2 glx 543.640 141.484 TRANS CCARD GLX Object Table 1 (Object/Partner)
m_prpr shared 219.758 141.400
s001 shared 207.681 140.478 TRANS SIS: Customer Statistics
balm shared 355.677 139.264 TRANS Application log: log message
mard esprit 386.798 138.998 TRANS Material Master: Storage Location/Batch Segment
mchb esprit 435.776 138.686 TRANS Batch Stocks
vari shared 138.682 134.286 TRANS ABAP/4: Variant storage (similar to INDX)
mch1 esprit 379.630 133.826 TRANS Batches (if Batch Management Cross-Plant)
plfv esprit 384.619 133.120 TRANS PI Characteristics/Sub-Operation Parameter Values
mcha esprit 381.114 131.394 TRANS Batches
m_vmsk shared 294.359 128.742
swwwihead shared 172.796 125.408 TRANS Header Table for all Work Item Types
s026 esprit 405.743 124.318 TRANS Material usage
d301t shared 923.483 122.896 TRANS Texts for Program Functions and Menu Bars
anlb fi 346.119 122.896 TRANS Depreciation terms
mara esprit 113.301 121.748 TRANS Material Master: General Data
accthd fi 701.281 121.086 TRANS Compressed data from Accounting document - header
qakl esprit 391.167 118.378 TRANS Results table for value classes
vbrk esprit 223.167 118.148 TRANS Billing: Header Data
nach shared 157.794 116.842 TRANS Detailed output data
ltbp esprit 324.310 113.358 TRANS Transfer requirement item
cossd co 262.756 111.574 TRANS CO Object: Settled Secondary Cost Totals
aablg shared 121.644 110.662 CLUST Cluster fr Abrechnungsbeleg
lisplf esprit 276.774 108.396 TRANS Planning Entries Table for Background Planning in LIS
d342l shared 59.838 107.312 TRANS Table for long CUA objects
s789 esprit 211.337 106.496 TRANS Trade & Interco sales,shipping
d020l system 18.667 105.212 TRANS Screen (run-time format)
d021t system 469.285 102.416 TRANS Screen key word texts
anep fi 452.090 102.416 TRANS Asset line item
ckrco esprit 126.838 101.584 TRANS Anchor Entry of Summarized CO Object (Summarization Object)
edidc esprit 165.800 101.394 TRANS Control record (EDI Intermediate Document)
vlpma esprit 343.979 100.754 TRANS SD Index: Delivery Items by Material
pbhi esprit 614.652 100.004 TRANS Independent requirements history
m_vmcf shared 223.167 99.078
dokil shared 577.369 97.808 TRANS Index for Documentation Table DOKH
jsto esprit 920.832 97.280 TRANS Status object information
onr00 shared 1.112.052 96.024 TRANS General Object Number
konp shared 257.468 95.332 TRANS Conditions (Item)
d021s system 50.884 94.736
vepo esprit 580.825 94.208 TRANS SD Document: Shipping Unit Item (Content)
indx shared 28.622 92.176 TRANS System table INDX
d010t system 191.129 92.176
glt0 glx 103.624 92.160 TRANS G/L Account Master Record Monthly Debits and Credits
mcafvgv shared 184.832 90.776 TRANS Versions: Order Procedure
coepb co 334.577 90.644 TRANS CO Object: Line Items Variance/Period-based Results Analysis
s031 esprit 224.946 90.240 TRANS Statistics: Movements for current stocks
vapma esprit 242.327 88.312 TRANS Sales Index: Order Items by Material
d010y system 11.238 86.366
lfa1 fi 68.949 84.496 TRANS Vendor master (general section)
d022s system 52.198 84.496
affv esprit 326.618 84.480 TRANS Order process instruction values
ckit esprit 509.174 83.970 TRANS Texts for CKIS
kna1 fi 66.224 81.936 TRANS General Data in Customer Master
dd04t system 261.675 81.936 TRANS R/3 DD: Data element texts
kalo esprit 193.786 81.920 TRANS Costing Run: Costing Objects (KVMK)
Appendix 7 : Same as in Appendix 6, but sorted by category-tablename (status on January 7, 1998).

TABLENAME APPLCAT NUMROWS KBYTES TYPE SAP TABLE DESCRIPTION

cobk co 2.139.287 737.296 TRANS CO Object: Document header
coej co 81.384 170.796 TRANS CO object: year-related line items
coep co 6.660.072 5.509.120 TRANS CO object: period-related line items
coepb co 334.577 90.644 TRANS CO Object: Line Items Variance/Period-based Results Analysis
coepl co 761.886 201.856 TRANS CO Object: Line Items for Activity Types (by Period)
coka co 708.217 143.376 TRANS CO Object: Cost Element Control Data
cosb co 5.581.813 12.483.000 TRANS CO Object: Total Variances/Results Analyses
cosl co 381.681 444.316 TRANS CO Object: Activity Type Totals
cosp co 3.489.332 7.741.440 TRANS CO Object: Cost Totals - External Postings
coss co 4.463.354 10.994.734 TRANS CO Object: Cost Totals - Internal Postings
cossd co 262.756 111.574 TRANS CO Object: Settled Secondary Cost Totals
mckalkw co 699.608 337.936 TRANS Versions: Cost Itemization
affv esprit 326.618 84.480 TRANS Order process instruction values
afru esprit 306.845 235.778 TRANS Order completion confirmations
afvc esprit 217.693 244.028 TRANS Operation within an order
afvv esprit 217.693 229.978 TRANS DB structure of the quantities/dates/values in the operation
aufm esprit 581.128 203.808 TRANS Goods movements for order
chvw esprit 1.515.660 946.426 TRANS Table CHVW for Batch Where-Used List
ckis esprit 509.167 561.020 TRANS Unit Costing: Items / Product Costing: Itemization
ckit esprit 509.174 83.970 TRANS Texts for CKIS
ckrco esprit 126.838 101.584 TRANS Anchor Entry of Summarized CO Object (Summarization Object)
edi30c esprit 205.838 538.668 CLUST Intermediate document cluster (data records) from 3.0C
edidc esprit 165.800 101.394 TRANS Control record (EDI Intermediate Document)
edids esprit 959.683 423.176 TRANS Status record (EDI IDoc)
ekbe esprit 1.622.704 540.298 TRANS History of Purchasing Document
eket esprit 595.250 184.336 TRANS Delivery Schedules
ekkn esprit 512.731 225.296 TRANS Account Assignment in Purchasing Document
ekko esprit 306.692 204.816 TRANS Purchasing Document Header
ekpo esprit 564.212 614.416 TRANS Purchasing Document Item
jcds esprit 3.577.239 485.084 TRANS Change Documents for System/User Statuses (Table JEST)
jest esprit 4.753.391 501.760 TRANS Object status
jsto esprit 920.832 97.280 TRANS Status object information
kalo esprit 193.786 81.920 TRANS Costing Run: Costing Objects (KVMK)
kbed esprit 370.433 286.720 TRANS Capacity requirements records
koclu esprit 611.908 377.826 CLUST Cluster fr Konditionen in Einkauf und Verkauf
likp esprit 142.816 155.640 TRANS SD Document: Delivery Header Data
lips esprit 344.019 368.640 TRANS SD document: Delivery: Item data
lisplf esprit 276.774 108.396 TRANS Planning Entries Table for Background Planning in LIS
ltak esprit 573.728 146.432 TRANS WM transfer order header
ltap esprit 919.075 993.280 TRANS Transfer order item
ltbp esprit 324.310 113.358 TRANS Transfer requirement item
mara esprit 113.301 121.748 TRANS Material Master: General Data
marc esprit 209.481 157.512 TRANS Material Master: C Segment
mard esprit 386.798 138.998 TRANS Material Master: Storage Location/Batch Segment
mbew esprit 208.169 157.508 TRANS Material Valuation
mch1 esprit 379.630 133.826 TRANS Batches (if Batch Management Cross-Plant)
mcha esprit 381.114 131.394 TRANS Batches
mchb esprit 435.776 138.686 TRANS Batch Stocks
mkpf esprit 1.493.584 327.696 TRANS Header: Material Document
moff esprit 1.191.421 245.776 TRANS Outstanding Material Master Records
mseg esprit 2.523.993 2.735.360 TRANS Document Segment: Material
msta esprit 1.804.234 299.536 TRANS Material Master Status
nast esprit 1.775.979 2.252.800 TRANS Message status
pbhi esprit 614.652 100.004 TRANS Independent requirements history
plfv esprit 384.619 133.120 TRANS PI Characteristics/Sub-Operation Parameter Values
plmk esprit 413.424 460.680 TRANS Inspection characteristic
plpo esprit 85.149 181.168 TRANS Task list - operation/activity
prow esprit 5.197.767 471.040 TRANS Forecast Values
qakl esprit 391.167 118.378 TRANS Results table for value classes
qals esprit 119.534 272.738 TRANS Inspection lot record
qamr esprit 528.035 302.258 TRANS Characteristic results during inspection processing
qamv esprit 848.665 947.750 TRANS Characteristic specifications for inspection processing
qasr esprit 267.086 153.336 TRANS Sample results for inspection characteristics
qasv esprit 2.000.918 476.308 TRANS Sample specifications for inspection processing
resb esprit 270.571 348.160 TRANS Reservation/dependent requirements
rf048 esprit 1.787.986 290.246 TRANS Subseq.BA/PC adjustmnt: Index/distributn vector (calculate)
s012 esprit 351.753 184.320 TRANS PURCHIS: Purchasing Statistics
s022 esprit 308.007 277.520 TRANS SFIS: Order Operation Data for Work Center
s026 esprit 405.743 124.318 TRANS Material usage
s027 esprit 933.819 335.872 TRANS Product Costs
s031 esprit 224.946 90.240 TRANS Statistics: Movements for current stocks
s033 esprit 1.270.650 491.520 TRANS Statistics: Movements for Current Stock (Individual Records)
s034 esprit 565.563 217.362 TRANS Statistics: Material Movements for Batches
s504 esprit 531.478 286.720 TRANS Tubing Actuals
s507 esprit 775.458 450.560 TRANS Polyswitch Forecast
s508 esprit 504.557 307.200 TRANS Tubing Forecast
s789 esprit 211.337 106.496 TRANS Trade & Interco sales,shipping
s792 esprit 771.574 389.120 TRANS Trade&Interco sale,ship daily
s793 esprit 664.093 328.730 TRANS Trade&Interco w/o valuat.class
vapma esprit 242.327 88.312 TRANS Sales Index: Order Items by Material
vbap esprit 242.398 271.598 TRANS Sales Document: Item Data
vbdata esprit 64.587 161.792 TRANS Update data
vbdata esprit 64.587 161.792 TRANS Update data
vbep esprit 384.264 152.208 TRANS Sales Document: Schedule Line Data
vbfa esprit 3.097.763 849.936 TRANS Sales Document Flow
vbfs esprit 3.991.126 1.320.304 TRANS Error Log for Collective Processing
vbpa esprit 2.389.765 539.750 TRANS Sales Document: Partner
vbrk esprit 223.167 118.148 TRANS Billing: Header Data
vbrp esprit 635.985 696.320 TRANS Billing: Item Data
vekp esprit 471.056 368.640 TRANS SD Document: Shipping Unit Header
vepo esprit 580.825 94.208 TRANS SD Document: Shipping Unit Item (Content)
vlpma esprit 343.979 100.754 TRANS SD Index: Delivery Items by Material
vrpma esprit 635.949 200.924 TRANS SD Index: Billing Items per Material
z9mkl esprit 435.547 158.256 TRANS Material Group Conversion - Log Table
zs012 esprit 231.976 143.376 TRANS PURCHIS: Purchasing Statistics
acctcr fi 5.085.296 808.960 TRANS Compressed data from Acctg document - currencies
accthd fi 701.281 121.086 TRANS Compressed data from Accounting document - header
acctit fi 2.542.648 2.744.320 TRANS Compressed data from Accounting document
anep fi 452.090 102.416 TRANS Asset line item
anla fi 103.861 230.416 TRANS Asset master record-segment
anlb fi 346.119 122.896 TRANS Depreciation terms
anlc fi 1.095.323 819.216 TRANS Asset-value fields
anlp fi 3.693.230 1.372.176 TRANS Asset periodic values
bkpf fi 13.370.140 9.850.896 TRANS Accounting document header
bsad fi 3.753.865 4.771.840 TRANS Accounting: Secondary index for customers (cleared items)
bsak fi 2.880.545 3.600.000 TRANS Accounting: Secondary index for vendors (cleared items)
bsas fi 14.568.621 7.475.200 TRANS Accounting: Secondary index for G/L accounts (cleared items)
bsid fi 381.216 552.976 TRANS Accounting: Secondary index for customers
bsik fi 79.441 154.736 TRANS Accounting: Secondary index for vendors
bsim fi 1.058.366 213.172 TRANS Secondary Index, Documents for Material
bsip fi 2.765.143 798.736 TRANS Index for vendor validation of double documents
bsis fi 37.380.561 23.490.576 TRANS Accounting: Secondary index for G/L accounts
cdcls fi 7.871.606 4.096.000 CLUST Clusterstruktur fr nderungsbelege
febep fi 262.637 184.336 TRANS Electronic Bank Statement Line Items
kna1 fi 66.224 81.936 TRANS General Data in Customer Master
lfa1 fi 68.949 84.496 TRANS Vendor master (general section)
reguc fi 1.213.107 1.038.626 CLUST Cluster fr Einzelpositionen der Zahlungsregulierung
reguh fi 1.212.783 2.662.400 TRANS Settlement data from payment program
rfblg fi 13.456.650 20.951.056 CLUST Cluster fr Buchhaltungsbeleg
glidxa glx 25.576.343 4.034.560 TRANS Index to Find FI-SL Documents Based on AWKEY
glt0 glx 103.624 92.160 TRANS G/L Account Master Record Monthly Debits and Credits
zzrefa1 glx 50.621.017 25.804.944 TRANS Operational GLX GL Line Items (Actual)
zzrefa1 glx 0 7.415.372 TRANS Operational GLX GL Line Items (Actual)
zzrefa2 glx 50.050.802 27.361.280 TRANS CCARD GLX Line Items (Actual)
zzrefo1 glx 1.562.324 487.632 TRANS Operational GLX Object Table 1 (Object/Partner)
zzrefo2 glx 543.640 141.484 TRANS CCARD GLX Object Table 1 (Object/Partner)
zzreft1 glx 3.189.999 7.208.960 TRANS Operational GLX Summary Table
zzreft2 glx 1.935.038 2.375.680 TRANS CCARD GLX Summary Table
glpca pca 11.938.097 12.800.016 TRANS EC-PCA: Actual Line Items
glpct pca 158.839 185.788 TRANS EC-PCA: Totals Table
aablg shared 121.644 110.662 CLUST Cluster fr Abrechnungsbeleg
arch_idx shared 6.565.295 1.413.120 TRANS Index table for data object selection
atab shared 2.047.533 540.410
ausp shared 1.977.973 1.184.400 TRANS Characteristic Values
balm shared 355.677 139.264 TRANS Application log: log message
cmfp shared 4.199.921 2.334.720 TRANS Storage Structure for Errors Collected
d301t shared 923.483 122.896 TRANS Texts for Program Functions and Menu Bars
d342l shared 59.838 107.312 TRANS Table for long CUA objects
dbtabprt shared 2.931.468 1.515.520 TRANS Table of log records for table tupel changes
dokclu shared 587.257 513.958 CLUST Docu. lines
dokhl shared 626.356 163.856 TRANS Documentation: Headers
dokil shared 577.369 97.808 TRANS Index for Documentation Table DOKH
dsyat shared 383.307 143.376 TRANS Structures: Texts for Maintenance Structure
e071 shared 604.212 199.132 TRANS Objects of a request or task (E070)
e071k shared 1.025.684 327.696 TRANS Key objects (tables, views,...) of a correction
funct shared 681.136 204.816 TRANS Function Module Short Texts
indx shared 28.622 92.176 TRANS System table INDX
konp shared 257.468 95.332 TRANS Conditions (Item)
m_prpr shared 219.758 141.400
m_vmcf shared 223.167 99.078
m_vmsk shared 294.359 128.742
m_zzrd shared 7.261.570 3.696.640
mcafvgv shared 184.832 90.776 TRANS Versions: Order Procedure
nach shared 157.794 116.842 TRANS Detailed output data
onr00 shared 1.112.052 96.024 TRANS General Object Number
pcl1 shared 101.244 225.280 TRANS HR Cluster 1
s001 shared 207.681 140.478 TRANS SIS: Customer Statistics
snap shared 6.331 409.600 TRANS ABAP/4 snapshot for run-time errors
stxh shared 2.623.399 1.367.680 TRANS STXD SAPscript text file header
stxl shared 1.374.046 778.256 TRANS STXD SAPscript text file lines
swelog shared 1.442.456 1.003.520 TRANS Table for entries of the event log
sww_contob shared 471.506 180.256 TRANS Container Cont. for Work Item Data Container (Only Objects)
swwwihead shared 172.796 125.408 TRANS Header Table for all Work Item Types
tbtcp shared 112.523 155.000 TRANS Batch job step overview
todir shared 409.588 163.856 TRANS Switch object list
ttxy shared 490.851 1.057.110 TRANS External tax interface: tax information
vari shared 138.682 134.286 TRANS ABAP/4: Variant storage (similar to INDX)
apqd system 3.956.610 1.966.080 TRANS DATA DEFINITION Queue
d010l system 15.006 289.176
d010s system 228.800 614.416
d010t system 191.129 92.176
d010y system 11.238 86.366
d020l system 18.667 105.212 TRANS Screen (run-time format)
d021s system 50.884 94.736
d021t system 469.285 102.416 TRANS Screen key word texts
d022s system 52.198 84.496
dd03l system 517.645 143.376 TRANS Table Fields
dd04t system 261.675 81.936 TRANS R/3 DD: Data element texts
moni system 114.235 655.360 TRANS Monitor table MONI
tst03 system 274.140 4.546.560 TRANS TemSe data