Performance Issues with SDV03V02

[Former Member]

Hi,

The order rescheduling program(SDV03V02) runtime is too long. We have searched for notes in the OSS database but have not found any suitable notes. One of the oss notes suggested implementing indexes on VAPMA and VBUK but that has not helped either. We are thinking of writing a Z program which would submit the standard SAP program into multiple jobs-The Z program would schedule the program into multiple jobs using different sets of materials.

Has anyone faced runtime issues with this program? Any other suggestions?

Regards,

Aravind

[Former Member]

What release are you on?

For a standard SAP program, you should consider opening an OSS message for this if there are no notes that help.

Rob

[Former Member]

Aravind,

the program invokes availability check for all backourders based on material.

I would check the following :

- how many documents it's going to process ?

- if the number of documents is too big and there are really old docs - you may have a problem with order status update (your order never goes to "complete" status even if all items are rejected or fully shipped - just an example)....

- if you really need to reschedule many orders - you'll have to consider parallel rescheduling.... BUT it's not as simple as submit parallel jobs for different materials (material ranges)....as jobs will very likely fail due to a contention.

- another option to speed up the process (may really help) is to change timing of all order outputs which are set to process immediately to '1' -> to be processed via RSNAST00, then schedule a job after your rescheduling is complete to process all these outputs. It may really help as you separate output processing from avail.check/order save.... and since same order may be saved several times during rescheduling -> it may really help. You can do it by defining a "timing" routine for your output types.

- always good to run SQL trace or to just monitor this job in SM50 to see what it's doing... OR run it under new USER ID and check statistics for that ID to see which programs/tables took the most time.

Would be good to measure an average order processing time (check how many orders were processed in this job... I hope it has this info in the spool or you can calculate it based on messages in job log). It may help to determine if the problem is casued by too slow order processing or just by increased order volume.

There are many options to look at regarding rescheduling...but I would start from order processing performance.