As a consultant, I have the opportunity to work on many different SAP installations.  I continue to be surprised by the discovery that many of these companies are not properly managing their change pointer tables, allowing these tables to continuously increase in size over long periods of time.  Using data forensics, I have seen change pointer record counts as large as two billion (and still growing), and change pointer record creation dates that have aged many years with status of both processed and unprocessed.
What are change pointers, where are they located, and what is their purpose in an SAP system?
When turned on in configuration, change pointer records are written to SAP change pointer data tables when master data is maintained, as part of the shared master data facility.  Their primary purpose is to facilitate the distribution of master data additions and changes from the SAP host system to remote systems, via ALE using IDOCs.  Configuration customizing is used to determine whether or not change pointer record creation is turned on or off, and if turned on, which message types and data table-field changes will trigger the creation of change pointer records.
Change pointer records reside in data tables BDCP and BDCPS.  There is also a view BDCPV which combines fields from these two tables.  Table BDCP is the primary change pointer data table, and table BDCPS contains the status (processed or unprocessed) of the change pointer record.
A new change pointer record is created in the ‘unprocessed’ state, and creates a “demand” in the SAP system to create an outbound IDOC.  This “demand” is recognized by the SAP program RBDMIDOC (typically scheduled in a periodic batch job) which triggers the creation of the outbound IDOC, and then alters the state of the change pointer record to ‘processed’.  But while the status of change pointer record is marked as ‘processed’, the record still resides in the BDCP and BDCPS tables.
So, how are these consumed change pointer records deleted from the change pointer tables?  This is accomplished with the SAP Program RBDCPCLR (typically scheduled in a periodic batch job).  Depending on your business processes, the life cycle of a change pointer record is typically not that long.  If you are distributing your master data change IDOCs to remote systems daily, then the related change pointer records can be purged daily.  If your distribution cycle is weekly, then your cleanup cycle should also occur weekly.
If everything is working properly, the creation of change pointers is turned on, the creation of change pointer records is conditioned by message type and data table-fields, RBDMIDOC is running in a scheduled periodic batch job to distribute the master data changes via IDOCs and mark the change pointer records as ‘processed’, and RBDCPCLR is running in a scheduled periodic batch job to clean up the ‘processed’ change pointer records.
What, then, would cause runaway growth in the change pointer tables?
In my next two posts, I will review several methods I use to identify sources of runaway growth in the change pointer record tables.