ST12 performance tuning background job

Question

I would like to trace a program which will run about 3 hours.  In ST12, I cannot run the program in "current mode" since the execution time is too long.  How can I still use ST12 to trace the program execution when the program execute is submitted as background?  Pls advise the detail configuration needed in ST12.
Thanks very much for your help!
PS:  I tried to use "trace for" user instead of "current mode", and set the tasktype to "BT", when I press "start trace" and start the program background job in another session, seems nothing can be traced...
Edited by: Wing Yin, Anthony TANG on Aug 7, 2009 6:10 AM

Answer 1

Hi,
did you set up the trace on the same server where you background job was running?
3 hours is quite long... not possible to trace the whole execution.
With ST12 / SE30 (ABAP Trace) you can trace at maximum 4293 seconds. For ST05 i don't know no other limit then file size.
However you should not take such big traces.
Start with analyzing the STAD record in order to understand where the time is spent (CPU time, DB time, RFC + CPIC time, ...).
For CPU time you can continue with ST12 / SE30, for DB time you need ST05 and for RFC + CPIC time you can check the RFC Subrecords in STAD to see the 5 most expensive RFC calls (destination and FM).
In case of DB time a SQL Cache reset before the job execution and a delta analysis after the execution could help as
well if there is not too much other DB load on the system.
You can take some samples with traces. Start n traces with a few minutes duration and check the results agains STAD (overview). E.g. if according to STAD most of the time is spent in DB time but your sample trace shows mostly CPU time,
your sample is probably not a a good sample (not showing you a part where most of your time is spent).
Other than that, if your Batch Job is your program, you cann add some mesages to the job log to narrow down what part
of the programm consumes time (data selection, data processing, ...) . Another option is to evaluate if you can reduce the
processed data volume to take a trace in order to find out expensive parts of the program. This of course can change the
execution (e.g. of SQL statements) significantly.
You see analyzing long running batch processes could be a challenge
Kind regards,
Hermann