Your batch job analysis shows that you are currently running the change pointer processing program RBDMIDOC,
and the change pointer cleanup program RBDCPCLR; but you notice that the size of your change pointer tables
continues to increase.

Now, it is time to analyze the change pointer data directly.  Here are some targets that I pursue:

1.  Count.
How many change pointer records are in your tables – thousands, hundreds of thousands, millions, billions?
This simple statistic alone reveals an interesting story.

While I typically try to use transaction SE11 to count the number of records in table BDCP, I have found,
on occasion, that this method would time out due to an excessively large number of records in this table.
In this case, you can write a simple ABAP which can be scheduled to run in background.

2.  Age and status.
Using the view BDCPV, determine the age and the status of your change pointer records.  The age of a change
pointer record is indicated by the field BDCPV-CRETIME, and the status of a change pointer record is indicated
by the field BDCPV-PROCESS.

In general, are the change pointer records days, weeks, months, or years old?
Are different ancient records found to be in both the ‘processed’ and ‘unprocessed’ status?
Are different recent records found to be in both the ‘processed’ and ‘unprocessed’ status?

3.  Message type and status.
Using the BDCPV view, determine the message type and status of your change pointer records.
The message type of a change pointer record is indicated by the field BDCPV-MESTYPE.

Are there different change pointer records for some message types that are never found in the ‘processed’ state?
Are there different change pointer records for a particular message type that are in both the ‘processed’ and the ‘unprocessed’ status?

Custom Reporting
For a more sohpisticated data analysis, you might consider writing an ABAP program to categorize your
change pointer records into ageing buckets, message types, and by status.  The cross-tab report shown here
is one that I use to analyze change pointer records.   It contains three sections -
Unprocessed Change Pointers by Message Type Within Ageing Category,
Processed Change Pointers by Message Type Within Ageing Category,
and a Grand Totals Summary.

Example Scenario Leading to Runaway Change Pointer Records
Of course, there are many reasons why you might observe some of the scenarios described above.  Here is one example:

Many years ago, your company’s business processes required the daily distribution of material master
data additions and changes to a remote plant.  Your functional analysts correctly configured the
change pointers and the ALE process for message type MATMAS to send this data to your remote plant.
RBDMIDOC and RBDCPCLR were both running daily for the material master data message type
MATMAS.   Change pointer records for material master data were created whenever users added
or changed certain data fields, IDOCs were created and sent, the change pointer records were marked
as ‘processed’, and were then purged – all on a daily basis.

Last year, business process changed, and your remote plant no longer required the distribution of
material master data changes.  The batch jobs running RBDMIDOC and RBDCPCLR for the material
master data message type MATMAS were cancelled, so that IDOCs would no longer be sent to the plant,
and because there was no need to clean up after these IDOCs for this message type.

But…

No one remembered to turn off the creation of change pointers in configuration for the material master
data message type MATMAS.  So, every time a user added or changed a material, new change pointer
records were still being created, causing the change pointer tables to needlessly increase in size.
And the status of these change pointer records will forever remain ‘unprocessed’.

Do you have custom code that is creating change pointer records?
There is another source of runaway change pointer table size that I would like to discuss here.    In some SAP systems that I have worked on, I have found that change pointer records were being created via custom ABAP programs.  This was done to support a custom process, having nothing to do with the SAP intended use of the change pointer records – the support of ALE distribution of master data.  Unfortunately, the system designers also forgot to write a custom program to either clean up their “custom-purposed” change pointer records, or to allow these records to be recognized by the SAP cleanup program.

Next Steps
So, now that we have discovered unnecessary change pointer records cluttering up our SAP database,
what do we do next?
What is the recovery cleanup process?
How do we stop the creation of change pointer records that are no longer needed?

This will be discussed in my next post.