Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

RVKRED07 Program take longer time

former_member199632
Participant
0 Likes
1,722

Hi,

We have grouped the customers and running RVKRED07 in the background in off-peak hrs

(Note 363343 - Parallel processing of RVKRED77 if the runtime is too long)

It was ok up to ysterday, and execution time was around Group1- 2000 sec / Group2 - 1500 sec / Group3 - 1000 sec / Group4 -1200 sec... like wise

But suddenly, those values got increased and is still some of the groups are in active mode.

Group1- 15000 sec / Group2 - 28000 sec / Group5 -15500 sec...

What would be the reason for this, sudden increase of time;

Currently all active sessions accessing LIPS Table.

Action: Sequential Read LIPS

Table: LISP

Time is increasing .... Is it OK to stop this procees

How would this effect to the Production Operations

regards,

zerandib

Hi

See SAP Note 755395 - Parallel processing RVKRED77 for background processing.

Regards

Eduardo

5 REPLIES 5
Read only

volker_borowski2
Active Contributor
0 Likes
1,340

Hi,

check transaktion DB01 for possible LOCKs,

and check the DB session Monitor for the active SQL Statements

and their execution plans on the DB (This would be ST04 for some databases).

If you have long runing queries, post the statement from the sesison monitor and the execution plan.

Best regards

Volker

Read only

0 Likes
1,340

Btw., Volker, from my experience in the majority of cases the locks are indicated by "Direct Read" rather than "Sequential Read". I think here he might have a more general DB performance issue causing selects from LIPS taking longer than usual.

Read only

0 Likes
1,340

Hi Yuri,

agreed in general,

but esp. in this situation, when doing parallel abap processing, it ia always worth to cross-check, that the packages are split without overlaping.

A runtime jump times 10 suggest either a lock situation or a change in execution plan from index-supported to FTS or wrong index. I'd assume the real life distribution for those two in ranges 5:1 for situations like this (packaged parallel distribution). Chances for plan-turnover might be higher if it is a non-parallel situation.

Volker

Read only

ravi_lanjewar
Contributor
0 Likes
1,340

Hi,

This is standard program. You have to check for more notes or write to sap if you are not able to find any solution.

Meanwhile you are running the program in background even if it is taking more time I think it could not harm anything. You can continue with it untill you not get final soultion.

Kind Regards

Ravi Lanjewar

Read only

eduardo_hinojosa
Active Contributor
0 Likes
1,340

Hi

See SAP Note 755395 - Parallel processing RVKRED77 for background processing.

Regards

Eduardo