Poor throughput rates and response times.
Cause and prerequisitesUnfavorable selection or combination of parameters in SD Customizing.
Solution**********************************************************************
* This note can be found in German in SRV-CICS under number 10218.
* If will be updated as necessary in CSP, and since the middle of
* September '94 has been in the Lotus Notes Consultants Info Library
* (in English).
**********************************************************************
Due to an unfavourable choice and/or combination of parameters in
SD-Customizing several installations showed performance problems.
This consultant note is based on facts that have been observed by
'EarlyWatch' at productive customer installations.
This note describes critical functions and parameters and shows ways
to optimize SD. These ways apply to any system constellation at
present customer projects.
You should also refer to corresponding hints in our R/3 system
documentation and in our online documentation.
Please note the following principles: deactivate all functions you
don't use, minimize the functions you use, optimize the functions by
using SAP tools and monitors, use SAP services such as "EarlyWatch
sessions".
You should see to it that these measures are taken before you go
productive. Consider also topological parameters such as database
organization, buffer organization, I/O architecture and networks. This
way you can have satisfied customers, ease the load on yourself and
your colleagues in the Hotlines.
Ulrich Flamm / SAP Corporate Consultant Service.
**********************************************************************
**********************************************************************
1. Pricing.
1.1 Procedures.
1.1.1 Condition types in a procedure.
The procedures in use should contain only those condition types that
are relevant to the corresponding project. The use of standard
procedures leads to unnessecary access when the condition types
defined in them are not used and can be accessed automatically.
Group conditions should be used only when there are no other
possibilities. It is absolutely necessary to check the parameter
control of each condition type in use, in particular the "group
condition" indicator.
1.2 Formulas and Conditions
If possible, use the formulas and conditions provided by the standard
even when you use your own new condition types and procedures. New
procedures that do not contain formulas and conditions given by the
standard may produce incorrect results. When new requirements make new
formulas or conditions necessary you can set them up via the
transaction "VOFM".
Please document the new rules in "VOFM".
By skilfully defining conditions you can avoid unnecessary access.
Example: For one condition type, you use access via "Price group
Customer" and you know that out of ten defined price groups condition
records are only maintained for groups 01 and 02.
Condition amounts for the remaining eight groups are always added to
the document by hand or they are not considered at all. In this case,
a condition which has the effect that access can only be made for the
characteristics "01" or "02" should be stored in the procedure.
1.3 Access Sequence
Reduce the number of tables defined in an access sequence to the
minimum necessary.
Example: A customer exclusively uses price lists for administration
purposes and for fixing sales prices.
Thus the tables designed for purely material oriented as well as those
for both customer and material oriented pricing can be deleted from
the access sequence for "PR00", even though these options were
supplied.
The best solution would be to set up your own new access sequence in
order to prevent SAP standards from being changed.
As long as cascading access is necessary please use the "Exclusive
access" option. It ends the search in additional price tables as soon
as a valid record has been found.
When combining header and item conditions, you can also reduce the
search process by using "Pre-step".
Example: Condition types that are not indicated in the condition
header of an order need not be checked on the following items.
1.4 Condition types and price tables
Only activate and use project relevant condition types. Types that are
always allocated by hand do not need an access sequence. If possible,
you should use the "Condition supplements" technique.
Try to minimize the number of tables, the content of tables and thus
the number of condition records by reducing key combinations (for
example, customer/material price group).
Prevent the use of redundant keys or key elements.
Example: The key of a condition table is set up in the following way:
customer price group/customer number/material number.
This combination does not necessarily make sense since the customer
price group can be derived from the customer master record and a
"customer number/material number" key would have the same effect.
1.5 Buffering price tables
When the customer has sufficient resources at his disposal the price
tables used most often can be maintained in the memory as "100%
resident".
In doing so, you should pay attention to the frequency of
changes and buffer behaviour. As of R/3 2.2, it is planned to buffer
price tables generically, since buffer techniques will then have a
"crowding-out effect". At the moment - when the buffer is full -
additional requirements are directly imported by the disk and thus
place additional strain on I/O.
1.6 Buffering pricing scales.
As from R/3 3.0, it is planned to buffer scales generically.
2. Partner determination.
For the processing of partners please refer to the Chapter "Pricing".
For example, the use of more than ten partner roles in one document
raises doubts about an efficient organisation of this customer
project.
3. Text determination.
For the processing of texts please also refer to the Chapter
"Pricing".
The use of too many text IDs in one document raises doubts about
whether the customer is organized effectively.
Please see to it that the "text origin" is set correctly. Missing or
wrong origins may lead to unnecessary access.
4. Message control.
Processing in the "Print immediately" mode should be regarded as a
computer and database intensive procedure. In order to put less strain
on the online mode we recommend that you transfer all message types,
as far as possible, to the offline mode and to process them as
"collective printing".
4.1. Buffering message conditions.
As from R/3 3.0, it is also planned to buffer these condition records
generically, provided the message determination is condition
controlled.
5. Organizational units and "common master data".
Try to reduce your setup to the minimum necessary. For example, for
technical reasons it is not very useful to set up new sales areas and
to maintain condition tables for each area separately.
6. Dispatch scheduling.
Deactivate this option if not used.
7. Transport scheduling.
Deactivate this option if not used.
8. Routes.
Deactivate this option if not used.
9. Credit limit check.
Deactivate this option if not used.
10. Processing customer information records
Deactivate this option if not used.
11. Availability check
Deactivate this option if not used. For performance reasons, you
should choose processing of summarized requirements rather than
processing of individual requirements.
Do you use different checking strategies for different material groups
which lead to simplification and load reduction?
Do you really need block mechanisms for material masters in a concrete
project situation or may specific materials or groups of materials be
processed without being blocked?
12. Statistics update (SIS).
The update of SIS tables should be reduced to the minimum necessary.
To shorten the processing time you should use the asynchronous V-2
posting as much as possible.
13. Reporting.
Use "fast displays" as much as possible.
Increasing depth of access requires more processing capacity than a
purely index oriented evaluation, the case
"Index -> Document header -> Document item -> Schedule line"
is an extreme example.
You can delete the additional display "partner name" if it is not
used.
If possible, reports should be processed in offline mode and not
necessarily in daily operation.
14. Collective processing transactions 'VLO4' and 'VF04'.
If used, both the creation of deliveries and the creation of billing
documents should be transferred to offline mode.
Standard jobs are available.
There are further notes and error notes on 'VF04'.
15. Individual ABAP developments.
The performance of individual developments must be checked with the
monitor tools available. Programs which are used frequently should be
optimized as far as possible. For processing mass data it is necessary
to run a mass test under production conditions in advance.
15.1 Data transfer programs.
To transfer data, please use the standard programs available. As long
as you have several servers/CPUs at your disposal you can use load
modules in parallel to each server/CPU, provided that an underlying
source file has been usefully pre-sorted and/or usefully split into
several files.
Example: 100 000 customer masters have to be loaded from an external
system. Two servers are available, the data has been extracted from an
existing system and is in a sequential dataset "A".
File "B" is created.
Then file "A" is sorted, and the data distributed to the two files.
Then the two files are imported by the load module to one server each
and hence imported into SAP.
15.2 Programs with access to document flow (table "VBFA").
May only be used in exceptional cases, since all necessary data can be
accessed via original document tables.
In doing so, it is absolutely necessary for you to contact SAP
(EarlyWatch/Development).
No comments:
Post a Comment