This list is a mixed bag of non-basis performance
enhancers!
Configuration
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.
Development
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!
