SM13 Update Issues after SRM 7.0 EHP1 implementation

[Former Member]

Dear Colleagues,

We are facing an issue with large volumes of Update entries type UP2 (about 1 million)

waiting to be processed in SM13 with status like [V1 processed (90% of them), start, initial]

Background : We have recently updated our SRM 7.0 system as below,

during the update we didn't face any installation error issues.

Application - From  SRM 7.0/NW 7.01    to SRM 7.0 EHP1 /NW 7.02   [ABAP STACK only]

Oracle        - From  Oracle 10.2.0.5.5   to Oracle 10.2.0.5.7

SAP Kernel  - From  701 Patch 137    to 720 patch 201

Platform:

-------------

OS        - RHEL AS release 4 (Nahant Update 9) {Linux 2.6.9-100.ELlargesmp #1}

DB - (16 CPU , 32 GB RAM) , APP.server - (16 CPU, 48 GB RAM)

Issue:

--------------------------------

After few days of regular processing in SRM system we found out that there are large volumes

of update entries type UP2 (about 1 million) still waiting to be processed in SM13

1) The performance of processing type UP2 work process is worse, like its processing 100 entries per hour

2) Most of the update entries are due to program BBP_GET_STATUS_2 , its not clear why this

program is creating so many updates after EHP update,because the actual shopping carts, PO's etc created

in the system is very low. Please note the variant in the background job running the program BBP_GET_STATUS_2

takes 7 days into account for processing.

Symptoms:

--------------------------------

1) SM21 logs show

Error adding a request to the dispatcher queue ( UP2)

Request (type UP2) cannot be processed

2) The update processes type UP2 have worse performance processing the existing entries in SM13

Analysis/Actions till now:

--------------------------------

Since it is V2 updates (less critical) that are hung , and the status are like [V1 processed (90% of them),

start, initial], SAP recommended to manually repeat these updates

Therefore, In order to process these updates quickly, i have done below parameter settings to the system

rdisp/wp_ca_blk_no = 5000

rdisp/appc_ca_blk_no = 5000

rdisp/elem_per_queue = 42000

rdisp/queue_size_check_value = on,50,30,40,500,50,500,40000

increased updated processes, rdisp/wp_no_vb2 (CI+App.server) = 20

But There is no improvement in processing performance of the type UP2 updates.

It is also noticed that immediately after a reboot the updates look to process faster but soon the dispatcher

queue hits the maximum entries because of the update volume awaiting which further hangs the UP2 work processes.

I have raised a message with SAP aswell.

Help needed for below topics:

--------------------------------

What is the best way to process such large volumes of pending updates ? obviously the above method is not working fast enough.

Did Anyone face similar issues with program BBP_GET_STATUS_2 which is creating lots of update requests in SM13 especially with EHP? if resolved, What's the solution?

Thanks in advance, your inputs are much appreciated, please let me know in case any further information is required related to this issue.

Best Regards,

Raju Nallabothula

[Former Member]

Hello,

We recently upgraded from SRM 4 to SRM 7 EHP1.

We had memory and lock issues with BBP_GET_STATUS_2.

We removed all existing jobs and rescheduled two variants according to note 1145063.

After this we have not had any issues.

Regards,

Sushil.