ABAP Runtime error !!! Timeout error

[Former Member]

Hi friends,

This time i have an error in the production . The result of the error is becoz of the following short dump that occurs when a report is run . I would appreciate if you can give me some advice on how to overcome this issue . Sometime the report runs fine and fetches all the data from the table but sometimes it takes forever and results in a short dump.

Error analysis

-

---

After a certain length of time, the program is terminated. In the case of a work area, this means that

- endless loops(DO,WHILE, ...),

- database accesses producing an excessively large result set,

- database accesses without a suitable index (full table scan)

do not block the processing for too long.

The system profile "rdisp/max_wprun_time" contains the maximum runtime of a

program. The current setting is 600 seconds. Once this time limit has been exceeded,

the system tries to terminate any SQL statements that are currently

being executed and tells the ABAP processor to terminate the current

program. Then it waits for a maximum of 60 seconds. If the program is

still active, the work process is restarted.

In my SQL query i have used SELECT SINGLE ....INTO TABLE ... .

Should i use SELECT * .....INTO TABLE ????

Please let me know .

Thanks

[Former Member]

Hi Hari,

This is coz of long running program. Try to performance tune the program.

Remove all select statements from within the loop and use read statement with binary search. Try using sorted table where ever possible that should bring down your run time.

Never use select * , only select the fields you are really going to use. Array fetch is always a better option then selecting data in a loop.

Cheers

VJ

[Former Member]

Thank you Mr Rao for your suggestion . I will sure try tommorrow and see the results. There is one problem since there is a lot of data in the table . We run a batch program to run this report in the background . One thing i should let you know is that it works fine in the development environment . I think may be there is not enough data .

Thanks once again .

[Former Member]

If it works well in DEV, but not production, I'd bet on the problem being an un-indexed select statement.

It's difficult to analyze the problem, without seeing the code, so if you post it, we can give more help.

Additionally, you can use SE30 (runtime analysis) to pin-point long running areas of the program.

Rob

Message was edited by: Rob Burbank

[Former Member]

Hi Friends,

Thanks for all your tips . Yes i agree that this is a performance issue . The problem is that this report is trying to fetch data from a table where there are 10,145,405 entries . This report runs in background and takes usually 4-5 hours to get the results .Sometimes it works fine in background but at times givesa short dump . Rob as you asked me i am posting the SELECT Query that i am using . Please go through andlet me know . also let me know how do i do the run time analysis since this report runs in background .

Thanks once again .

SELECT RSNUM

MATNR

BDTER

WEMPF

BDMNG

MEINS

WERKS

LGORT

SGTXT

KZEAR

ENMNG

INTO TABLE itab

FROM RESB

WHERE RSNUM IN l_RSNUM

AND MATNR IN l_MATNR

AND WERKS IN l_WERKS

AND XLOEK NE 'X'

AND BDTER IN S_BDTER

AND BDART = 'MP'

AND BWART IN S_BWART.

Message was edited by: Hari Gopalakrishna

[Former Member]

Well the select will use the index nicely so long as either l_RSNUM or l_MATNR is not empty. You should check that one of these tables has entries before doing the select, otherwise it will search through the entire table without using either index. Also make sure that you are only checking for equality or between in each.

Rob

[Former Member]

Hi Rob ,

The problem here is that they are not using any RSNUM or MATNR on the selection screen . The only entries on the selection screen are WERKS , BDTER and BWART . Using these 3 fields the user is trying to get all the data .

Well as you say there is RSNUM and MATNR . Will it help if we add MATNR or RSNUM ???

Thanks

[Former Member]

It doesn't matter if it's on the selection screen or not, but both l_RSNUM and l_MATNR shouldn't be empty; otherwise, the program will run a long time. How are these two ranges filled now?

Rob

[Former Member]

Rob is Right these internal tables should not be empty, you can include these codes before proceeding to your SQL statement:

IF i_rsnum[] IS NOT INITIAL

AND i_matnr[] IS NOT INITIAL.

select rsnum

.

.

.

ENDIF.

These will somehow keep the SQL statement from returning volumes of data similar to an open search

[Former Member]

Hi,

I dont think the error is because of use of "select single..". In fact its far better than using "Select * ..".

You need to performance tune your program.

Adding to Vijay's suggestions, you also need to emphasis on "select single.." rather than "select ..upto 1 rows".

Avoid nested loops.

Avoid unecesary multiple database hits.

Avoid select within a loop.

Avoid using " select ...into corresponding fields..".

The error might be due to some database accesses without a suitable index. If there is lot of data in the database, it may result in time out dump.

Regards,

Tanveer.

[Former Member]

Hi Hari ,

Your program is going to short dump due to lack of proper code optimization and performance issues as others have also stated.

In addition to do the runtime analysis , you can make use of following also:

1. You can make use of SAP Code Inspector ( transaction code : SCI) to check your program. It will give you an idea how to optimize your select queries and detailed analysis of other errors/ warnings whihc will help you to fine tune your program.

2. The runtime analysis is also a good option because it will tell you which table is highly being used and then accordingly you can optimize your code.

3. Select single is always a better option than using select *. Moreover if you know which data actuallu to retreive , you should use obly those fields yto retreive.

4. Avoid using nested select statements and nested loops as far as possible.

Hope these points help you analyze your program in a better way and give you a certain solution to optimize your code.

Thanks and Regards,

Cheers.

Kunal.

[Former Member]

Hi !

If it is not possible to tune up your programm you can run it in background as a "batch" programm.

In the background there is no runtime limitation !

Regards

Rainer

Some Reward Points would be fine if this helps a bit...

[kiran_k8]

Hari,

To my knowledge,even a background job will have some limitations in terms of runtime.There is an ample chance that this long running job will impact other critical jobs in Production.So better do the performance optimisation rather than brushing it under the carpet in the name of "program scheduled as a background job".

K.Kiran

[Former Member]

Hai

Updation of the timeout limit is task of BASIS.

In Tcode : RZ10, you can maintain systme parameters.

The parameter name is rdisp/max_wprun_time. If it not maintained in the profile it will be default 10 mins(600 seconds) as SAP has recommended.

Make sure about your system before changing that.

ALSO CHECK OUT WITH THESE LINKS

http://sap.ittoolbox.com/groups/technical-functional/SAP-R3-DEV/timeout-in-abap-debugger-560635

http://sap.ittoolbox.com/groups/technical-functional/SAP-R3-DEV/timeout-in-abap-debugger-560756

Thanks & Regards

Sreenivasu P

Message was edited by: Sreenivasulu Ponnadi

[Former Member]

Hi normally sertan time limit will be set by the basis people to run the abap programs in foreground

I think in your case as mentioned below you fellow all the performense issues with select stmts and use secondary indexes

and use the commit work immediateely after the database update explicitly in the program so that the run times will reset

use the commit work in several places then let me it shoud work fine .

Cheers,

srinu reddy.

[Former Member]

This message was moderated.