Symptom

You face slow performance when running RPTIME00 (tcode PT60).

Cause

There could be any number of reasons for performance problems. This page describes some hints and best practices to avoid such kind of issue.

Solution

From our development colleagues, you can find some more information below:

1. First and very important is that it is advisable to run RPTIME00 daily and again during end of the period (for the whole month);
2. Try to run RPTIME00 in parallel by using report RPCS0000 to schedule with a smaller number of employees on each run. You need to do it with even smaller groups (maybe 500 employees). BUT make sure that the RPTIME00 jobs are started on different servers and not all on the same (if possible). If all run on one server, that server will be overloaded;
3. If any of the runs in RPTIME00 force a retro-calculation for a significant number of the employees processed, the longer runtimes can be expected. Check the field ‘PDC recalculation’ in the infotype 0003 of the evaluated persons. This field means, since when the time events must be evaluated by RPTIME00. If this field is not set or an early date, this might be the reason for an more and more longer running RPTIME00. Note: If you run RPTIME00 in test mode, this field is not changed;
4. There are some things you might check in your schema:

• Do you use a schema with COLER F (COLER E) in it?
• Do you have a LIMIT rule (T559P) that creates a message with type COLER F (COLER E).
• Does a COLER F exist, that causes a retro calculation into the past?
• Checking all the different messages and errors (origin and number, especially message type E and F – protocol and statistics of rptime, Cluster B2: table FEHLER, Cluster B1: table ERT).

Improving performance in time tables

Via transaction SE11 you can create Indexes on tables TEVEN, FEHLER, PCL1 and PCL2. In case of RPTIME00 spending a lot of time with the reading of TEVEN, an Index on the fields MANDT, PERNR, LDATE and LTIME would be reasonable. Please also refer to the online-documentation for further information. If you have many entries in your TEVEN table, you only can delete the oldest entries unfortunately in the SAP standard a reorganization of the time events is not possible. You can create a customer program and delete it, if you do not need this data in the future. Please have a look at the note 62157, it may help you to create this report.

The “display log” option

In related performance issues for RPTIME00 we have forwarded notes 166053 and 166506 which related to performance issues with the log turned on. It is highly recommended that the log is not turned on. In addition, our developers have forwarded note 103747 which refers to performance parameter recommendations which you may find helpful.

STORAGE_PARAMETERS_WRONG_SET error

Note 166551 gives an explanation of how to diagnose memory problems when the STORAGE_PARAMETERS_WRONG_SET error appears, also review note 44528.

Please refer to note 103747 and check your system resources for the right value. Please ensure that the parameter abap/heap_area_total is always larger than abap/heap_area_dia or -nodia.

The LIMIT function

According to our development department please also check, whether function LIMIT is used in your time evaluation schema. In this case also quite old periods are evaluated. Please also check, how many retrocalculations take place, which can also be caused via data inconsistencies or uncorrected errors. You can verify this via error messages in the worklist (transaction PT40) and report RPCLSTB1 (cluster B1). Please also check, whether calculations ‘far in the past’ are taking place for some personnel numbers. Also, for testing purposes, please start the calculation for groups of employees to find out, whether a certain personnel number is affected especially.