RVKRED07 Program take longer time

[former_member199632]

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

[former_member199632]

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

[volker_borowski2]

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

[yuri_ziryukin]

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.

[volker_borowski2]

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

[ravi_lanjewar]

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

[eduardo_hinojosa]

Hi

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

Regards

Eduardo