In my last post, I discussed a collaborative effort with functional business owners to devise and execute a proper cleanup plan.  I also discussed a functional review of the configuration to make sure that change pointers are being created only when needed.

So now that you have achieved control over your change pointer data, how do you make sure that it does not go out of control again?

1. Continuously purge PROCESSED and UNPROCESSED change pointer records based on established ageing parameters.

Once a change pointer record is processed, it has no further use – there is no reason to keep it for several weeks or longer.  Someone once tried to convince me that they needed to change pointer records as proof that an IDOC was created.  I suggested that they use SAP transaction WE05 instead.

Determine and agree upon a reasonable time period for which processed and unprocessed change pointer records should be permitted to persist in the change pointer tables.  Once these values are determined, you should set up an SAP job using ABAP program RBDCPCLR with an appropriate variant that will insure that change pointer records cannot persist beyond the specified length of time.

Unprocessed change pointer records that persist beyond the specified date indicate a problem.  These should be allowed to persist long enough for analysis purpose to determine and fix the root cause of why these records still remain.  This should be a matter of days and not weeks.

2. Establish a process to periodically review whether or not the current change pointer
configuration settings are supporting the business needs.

Make sure that you include your functional business owners in this process.

3.Consider the impact of a database restore.

While this is a rare occurrence, a major catastrophe may trigger the need to restore the SAP database from a backup that was created some time in the past.  For example, restoring the database from yesterday’s backup would resurrect some “processed” change pointers because yesterday, they were “unprocessed”.  Now consider that the external consumers of your IDOCs are not resetting their databases to yesterday, and have already received yesterday’s IDOC distributions.

4. Continuous monitoring.

Continue to monitor the size of tables BDCP and BDCPS.  Unless there is an unusually large amount of master data maintenance occurring at a given time, the size of these tables should remain relatively static.

Ideally, the monitoring process should be automated.  Possible automation alert triggers are:
a)      The change pointer tables increase in size by a pre-determined percentage or count above the
nominal value.
b)      Records exist in the change pointer tables that are aged beyond a specified number of days.

In this blog, I tried to cover the most common scenarios that I have encountered.  Because I see and learn new and wonderful things all the time, I realize that you may be facing a scenario that is entirely different from what was discussed here.  But I hope that this blog provides enough information to help you solve your particular issues.

Of course, if you have any questions or suggestions, I sincerely look forward to hearing from you.