Are You Properly Managing Your SAP Change Pointers Part 2 – A Simple Source of Runaway Growth
Last time, in my 50,000 foot view post, I presented an overview of the purpose, the location, and the expected lifecycle of change pointer records. I also briefly discussed two programs:
RBDMIDOC - triggers IDOC distribution for ‘unprocessed’ change pointer records, and marks those change pointer records as ‘processed’. RBDCPCLR - deletes the ‘processed’ change pointer records from the change pointer tables.
One obvious source of runaway change pointer table growth is never running the cleanup program RBDCPCLR. Using transaction SM37 (batch jobs), you can determine if RBDCPCLR is running in a batch job, and how frequently it is running. As shown in the screen shot below, enter RBDCPCLR in the ABAP Program Name box, enter a relevant date range, and check the various job status boxes that you might be looking for. I recommend setting a significantly wide date range, as I have found situations where RBDCPCLR was running in a scheduled batch job a while ago, but for some unknown reason is no longer currently running.
Pressing the EXECUTE button will produce a list of batch jobs containing RBDCPCLR.
Analyze the scheduled batch job list.
If the list is empty, then RBDCPCLR is not running in a regularly scheduled batch job. Unless RBDCPCLR is executing via some other means, ‘processed’ change pointer records are not being purged. This is one simple source of runaway change pointer table growth.
I have encountered many reasons why RBDCPCLR is not currently running when change pointers are turned on. In some instances, my clients did not know that active management of the change pointer tables was necessary. In others, they knew about managing the change pointer tables, had at one time, run periodic batch jobs executing the program RBDCPCLR, but for some reason, were not currently running these jobs.
While you are here in transaction SM37, you might also want to check out the frequency of your RBDMIDOC executions. If RBDMIDOC is not running, it is possible that new change pointers are created as master data is changed, never triggering the creation of their outbound IDOCs, and never marking change pointer records as “processed” so that RBDCPCLR can clean them up.
If the scheduled job list or other analysis shows that RBDMIDOC and RBDCPCLR are currently running periodically, and your change pointer tables are still increasing in size, then you need to analyze the change pointer data itself to determine the cause.
I like data forensics. It can reveal some rather interesting facts if you know how to analyze your data. In my next post, I will discuss several change pointer data forensic methods that I use to reveal other sources of runaway change pointer table growth.
