Perfomance issue

Either ABAP or the database can consume most of the resources. If the database is consuming much more, it may indicate a bad select. Although if you are reading a lot of data and not doing much processing, then the high percentage is not a problem; however, if it's ABAP, you may have some inefficient nested loops. Long ABAP run times can normally be fixed. I've never seen R/3 consume too much.

If you're concerned about the database, a performance trace can give you a much better idea of what's going on.

Rob

Message was edited by: Rob Burbank

Just look that the Database utilization is less than 50%

Hi KP,

You use Run time Analysis and SQL trace to check if your program is having any pitfalls.

Usually DB time should be less when compared to ABAP and R/3.

Resolve SQL trace findings... your program will be optimal..

Regards,

Raj

I have found that most of the time performace issues are caused by bad ABAP code. Here are some common mistakes to look for.

1. Make sure that you are providing enough fields in 'where clause' to select statement to make it use an index.

2. Avoid using select single inside Loop and Endloop. Select the data before loop using FOR ALL ENTRIES cluase before loop endloop and only read the internal table in the loop.

3. Avoid using SELECT *. Retrieve only those columns that are actually needed.

4. Always use binary search on standard internal table. It creates huge difference when the read statement is inside LOOP and ENDLOOP.

Always start from run time analysis. sort the hit list by net period in descending order and start looking from the first item ( item consuming maximum time).

KP,

There is no hard and fast rule.

Usually the DB will not take more than 10%. If you have checked all the ways of improving the performance, then you can always advise the users to run the report only in the background.

What does the run time analysis of PRODUCTION and DEV say?

Regards,

Ravi

Using the runtime anaylsis will not solve your problem. I would suggest doing a Sql trace for the program. This will tell you exactly what is making the program run long. I am assuming that it is spending most time on the DB. Run ST05, click the "Trace On" button, back out of ST05, run your program. Now go back to ST05, and click Trace Off, then List Trace. This will give you a listing of the Sql statements that were executing, see anything with a high number or in RED. That's where your problems are.

Regards,

Rich Heilman