"BD21" Strange behavior.....

[Former Member]

Hi folks,

We are coming across a strange problem. As we migrated from another system. I have setup ALE/Idocs for certain countries. We schedule the change pointer “BD21” program and the “RSEOUT00”. These program were running fine since 3 weeks and I can see the transaction Bd87,We02 that Idocs are successfully passing to the target system . They also confirmed they are getting data.

In between these days, we have found that BD21 is taking a long time, like it taking 1 hour to process the 90,000 entries. I looked in to different OSS notes and then I implement them. In addition, we finally schedule the program “BD22”. After this , the change pointer run time again come to under 30 minutes .

Yesterday, we have notice that “Bd21” is keep on running for last 17 hours . We have get some much complained that clients haven’t received any Idocs. Obviously, If its keep on running how can they receive the Idocs. So we cancel the background job and re-schedule it and then it created Idocs for the message type “hrmd_a”.This time it ran just in 30 minutes.

I am in great dilemma, why it took 17 hours, what is the reason … could you please help me and bring in your thought and suggestion. Why it took so many hours to run.

What need to be check? What can be the possibility?

I’ll appreciate your help and concern.

Thanks in Advance

[Former Member]

I'm afraid it might be problem with background job rather than the transaction BD21. Did you checked the status of the program/job in SM51 . Some times the process terminates at the Unix level but the Job in SM37 shows active status. In such case you can confirm whether job is running or not by highligting the job and select Job->check status. This will show whether the job was active or cancelled.

Hope this helps.

[Former Member]

Please check out the OSS notes 328355 also.

[christian_wohlfahrt]

Hi!

Also have a look into ST22 for dumps, SM13 for hanging updates or SM21 for general (syslog) problems. Often you can find a hint, what was going wrong.

Regards,

Christian

[Former Member]

I already look in to Sm51 /STAT.. Db12.DB02 ...SM13, SM21, ST22 But couldn’t fine any thing. OSS 328355 doesnt not exist. I think you mistyped the number.

What else could the problem?

Thanks

[Former Member]

The OSS number is 328355 and the text is read as BD21 : Long access times for BDCPV View.Please check again.

[Former Member]

I remember I already went through this OSS note. We already implemented this note in our system

Thanks For your prompt reply!!

[christian_wohlfahrt]

Hi!

Also a general 'bad performance' might be a reason. Spoken more technical: it's possible to run into a deadlock.

This happens, when one program holds a lot implicit (read) locks on a table, so that others can't make write accesses (change pointer status). After some time locks can't be handled on single entry level and will be hold in pages -> even more locks.

That's just database behavior (maybe only Oracle, I'm not sure) - there is no connection with SAPs lock concept.

If you want to have a look at a similar situation: take a non-buffered number range, create an according object and stop in middle of saving in debugging (after FM number_get_next, before commit). Now it's impossible to create a second object -> saving in other sessions just shows hour glases until you finish your debugging.

Maybe you had such a number range buffering problem with a number linked to IDOCs.

This can just be analyzed <i>during</i> the problem -> have a look at SM50/SM66 in case of long runtimes next time. You should see either a long table access of wait reasons (hopefully).

Regards,

Christian