Change pointer performance (BD21)

[Former Member]

Hi folks,

We are facing problem in change pointer program, as we have 95,000 entries in both tables BDCP and BDCPS . I also look in to the OSS notes , as we have change the index and view the way oss note recommended . After that we also ran a program to re-create index on tables according to oss note . but above all its still taking 55 minutes for change pointer program . Do you have any idea what else we can do ? We also came across a t-code Bd22 which deleted the change pointer, but this screen has two options process and obsolete change pointers. What does it mean ? on which option we should ran this program .

Any of you is running this program and what frequency you guys have to delete the change pointer e.g. 5 days old, 10 days old.

What else you guys decide to make change pointers program more efficient ( BD21) , as we are getting this problem .

Thanks in Advance for your input/suggestions

[Former Member]

Have you put in OSS note 863744?

Rob

[Former Member]

We are using message type: HRMD_A. The note you refer is talking about Martial related issue.

Christian, Thanks for such a nice and informative note .

We are just migrated , and our system go-live 2 weeks before and i thought would it be good idea to schedule the BD22 to run daily and delete the change pointer Obsolete and as well as processed .

When I went to table BDCPS I can only see 10,000 entries process out of 95,000.

and In BDCP , I can see "U" Update flag . in almost 94,995 entries.

We have scheduled the program Bd21 every half and hour and also Resout00 .

If some xyz non-sap external partner ask us to re-send Idocs , even with success code '03' . so I can able to re-process it in Bd87 or we19 . Or I can write a small code to reset it to status '30' .

Deleting change pointers process/obsolete doesn’t effect them right ?

Thanks

Message was edited by: Saquib Khan

[christian_wohlfahrt]

Hi!

BD22: don't delete daily obsolete pointers. If there are some pointers (obvious 90%), which aren't used by any interface, then deactivate change pointer creation (BD50). Before going live, a complete deletion of all pointers is of course OK.

Update flag in BDCP is of no meaning in this context, it just says master data change was Update, not Insert - but your interface has to run anyway (or all change pointers have to be selected anyway, internal filter is possible).

Retention period (storing time) for processed pointers: It's OK to store the IDOCs for some time, then BD87 is a good tool. Still error analysis of missing triggers is an open question - but it's normally not a problem, so daily deletion of all processed pointers is OK.

Are your pointers distributed over several message types? If yes, I don't expect too much performance of deletion <i>other</i> message type's pointers.

How long takes creation of 1 (or 10) IDOCs? Is runtime more depending on total number of change pointers, or on total number of IDOCs to be created? In case IDOC (=output) is main figure, then have a look for user-exits or buffer/memory problems, not the change pointers...

Regards,

Christian

[christian_wohlfahrt]

Hi!

I had already installations with 10 millions change pointers in BDCPS (and some million in BDCP) - which was a workload of ca. 10 days.

So change pointers are normally used once, e.g. for sending a new entry to an other system. After (successful) usage, they are marked (status = 'X') - they won't be read again. These 'processed' change pointers can be deleted completely - you can store them for some days for error analysis purpose (no IDOC received - was there a trigger by change pointer?).

Obsolete change pointers weren't used up to now - but if they are half a year old, they won't be used ever. They can be deleted up to - let's say 2 weeks in the past. But be careful, this depends on schedule of your programs.

So far for BD22 - but with BD21 you are processing the whole IDOC creation. Here change pointer reading might be only a small part - all segment values have to be generated, too. Maybe you have some additions in user-exits, which make very time consuming steps. Make a run-time analysis.

A starting selection of about 1 minute for change pointers might have to be tolerated - here the index might help.

We had a daily schedule to delete processed change pointers, which are older than 7 days. This took about 30 - 60 minutes per day, but that's not so important. 7 days was just the estimation, how long will it take to discover the problem (1 day), go through the customer's service center (2-3 days) to reach some competent programmer (+ 2 days weekend).

Again to BD21: normally the change pointer part is fast, but the segment filling takes some time. Please analysis more detailed your specific IDOC (and situation).

Regards,

Christian