Performance of a background job

[Former Member]

All,

One of our background job ran almost 8 times longer than last time and it got completed successfully.

What are the tcodes (like ST03N, ST02 , ST04 etc) and what exact options i can look for this completed job to see where is the bottleneck and why it took so long.....

I am basically looking into the best way to look for sequential read (which is what pretty much of the time the job did)

Thanks,

Murali.

[markus_doehr2 · Accepted solution]

You can run the job through SE30 - it will tell you exactly which statement is expensive.

Is that program a standard program or self-developed?

Markus

[Former Member · Accepted solution]

Hi MArkus,

Can i do a SE30 for a finished report ? It is a Z program

Thanks,

Murali.

[markus_doehr2 · Accepted solution]

It's impossible to find out what was causing the long running time a week later.

You should check with the developers of the program. I have seen many "select * from <tablename>" statements, where a huge amount of data is read which is not really needed.

Markus

[Former Member · Accepted solution]

Ok fine, let me talk to developers.

Thanks,

Murali.

[Former Member · Accepted solution]

Hi!

First you should find the cause using STAD and ST12, in order to see if you have a DB problem, system problem or hardware problem. ST12 transaction can help you adressing this issue to developers.

cheers

[Former Member · Accepted solution]

Closing it since it is opened for long

[former_member204746]

check ST05, trace the report, check explain plan to see which indexes are chosen. Compare with your QAS system to see about the same explain plan.

have you run DB_STATS lately?

[Former Member]

Hi Eric,

Job is completed week ago. I do not think ST05 can be used now for a finished report.

Thanks,

Murali.