Tips & Tricks: Performance


Are you losing out?
Upgrading SAP
SAP Truths
Good Ideas Dept.
Site Map
Contact / Resume

Tips & tricks toward better performance:

This list is a mixed bag of non-basis performance enhancers!


    Pricing performance - don't read a condition record if you don't have to!

If you look at each of the IMG field configuration of pricing accesses there is a small checkbox labelled "I" in the table display.  This field controls whether an access will be made during pricing if the source field for the access has a blank value.

If you have the scenario where transaction fields important to pricing MAY be blank in the order/delivery/Invoice, then it makes sense to SET this flag at the "field access" level so that unnecessary condition reads are not made!

    Batch Determination performance I - refresh classification statistics!

Orders or delivery performance grinding to a halt & you have batch management switched on in SD?

Run transaction CLST - often!! 

This transaction reorganizes an index on the classification statistics data that is used to select batch master records.

Lower-level database reorgs will negatively impact this index - remember to run the transaction after each reorg!

(The report CLST calls may also be set up in a batch job for convenience.)

    Batch Determination performance II - fine tune batch determination!

SAP has a little table called TFSBD that sits in the background which allows you to tweak the sequence in which SAP determines the relevant batches for any order/delivery.  The sequence elements are: 
1)    classification data,
2)    the batch master records in the database and
3)    checking the availability of each batch 

You can determine what your sequence currently is by looking at the analysis of batch determination ("batch determination log") in the delivery.  The order that the list sections appear (classification/master data/availability) indicates your setup sequence.

The sequence that is applicable to you really depends on your batch master-data reorg/retention policy, the extent of your batch classification setup, plant definition and volume of batch master data.

Prototyping different sequences and monitoring performance results (preferably in a production mirror system) should indicate which sequence is right for you.


    Performance killer deluxe:  Nested SELECTS

The surest way I know to get terrible run times for any kind of report is to nest the database select statements.  These reports may run acceptably for test systems with light data volume, but you have a nasty surprise in store for larger data volumes. 

The most efficient method of retrieving data from multiple tables is thru sequential reads into internal tables: SELECT * ... INTO TABLE....   

Base all subsequent database reads off of the internal table data.

Here's an example:
a)    SELECT * from VBAK into table i_vbak where <condition>
b)    SELECT * from VBAP into table i_vbap for all entries in i_vbak where <condition>

In my experience, this approach beats any other hands down!