Find out root cause of long running batch process from ABAP side

[Former Member]

Dear Basis gurus,

I am anlyzing the root cause anaysis for the long running of one of the background processes that is compelted

in our productive system.

In ST03N I have found that there is very less impact on CPU, DB time.

I believe that most of the time is at ABAP side.

At this moment could you please tell me what are all the checks

I need to do to find out the exact cause of this issue.

Thanks and Regards

Purna.

[Former Member]

Your answer is very helpful Wim.

Unfortunately i could not take enough traces at the time when batch job process was running.

1. Is there any method to find out now, what has caused the issue in making the high ABAP processing time?

2. I also found that one particular table and its indexes statistics are very old, was it also one of the issues?

Thanks and Regards

Purna.

[Former Member]

Hello,

At runtime you will have much more detail when you perform SE30 or ST12.

What you can do now is analyse via ST03N what caused the high processing time (wait times, RFC calls, CPU, ...).

Problem is that you do not have enough detail.

Recalculating DB statistics can help, but you mentioned that DB time is no problem and that long runtimes come especially from the processing time.

With long runtimes caused by high processing time there is only one solution : in depth analysis of the calls via an ABAP trace or process trace.

Wim

[JPReyes]

You could do an SQL trace via ST05 and check if its stuck doing sequencial readings in large tables.... If thats the case then you might have to look into tweaking the indexes... talk to your abaper

Regards

Juan

[Former Member]

Hello,

ST05 will not help you.

I read that DB time is no issue (I assume it is below 30-40% of your response time) so it makes no sense in tracing your SQL statements.

If you say that ABAP processing time is the problem there is only one solution and that is to trace all the calls (routines, function modules, internal tables, ...).

You can best do this during runtime, you have time enough because it concerns a long running batch job.

You can do this via tcode SE30 (before you start the batch) or even at runtime you can measure a running process via ST12.

I often use ST12 to analyse long running processes at runtime to identify long running statements, long running loops on internal tables even for SQL traces.

Wim

[Former Member]

Hi,

>ST05 will not help you.

>I read that DB time is no issue (I assume it is below 30-40% of your response time) so it makes no sense in tracing your SQL >statements.

Well, you just can't know if you don't do an SQL trace.

In my experience, bad database access is the most frequent cause of too slow jobs.

Regards,

Olivier