Are You Properly Managing Your SAP Change Pointers Part 4 – The Cleanup



In my last post on this topic, I discussed several change pointer data forensic methods that I use to point me in the right cleanup direction.
The change pointer data forensics will determine how to design the cleanup process.  Armed with meaningful statistics, I usually approach the functional business owners to collaborate on a solution.  Typical of the many questions that I ask are “Why are change pointers configured for this message type if we are never distributing the IDOCs?”

Discussion points and procedures for the cleanup process.

1. Unless there is custom ABAP code depending on the continued existence of processed change pointers, they serve no further purpose and should be deleted.  ABAP Program RBDCPCLR should be scheduled on a regular basis so that recent “processed” change pointers are purged.

If there is a large quantity of very old “processed” change pointer records, then consider special executions of RBDCPCLR where the selected date range is old enough to collect and purge these records.

To cleanup processed change pointers, use the Processed Change Pointers section on the select option screen of program RBDCPCLR.  Make sure that the “Processed Change Pointers” check box is checked, and enter the proper date range.  You can further limit the data selection by entering a message type in the message type box.

Note that on the selection screen there is also a “Test Run” check box that will list which records would be selected for purging, without actually purging them.  I find this feature very useful, and I strongly recommend using it prior to actual purging.
delete change pointers 1

2. “Unprocessed” change pointer records that are very old are most likely not useable.  If the IDOCs that they represent were triggered now, the data distributed might no longer be valid.  The important discussion point here is the definition of “very old”.  Is it one year, six months, two weeks?  This decision definitely needs input from the functional business owners.

Once the definition of “very old” has been established, schedule executions of RBDCPCLR with the “Obsolete Change Pointers” box checked, and the agreed-to “very old” date entered in the date box.  This execution will remove both “processed” and “unprocessed” change pointer records up to the specified date.

Note that on the selection screen there is also a “Test Run” check box that will list which records would be selected for purging, without actually purging them.  I find this feature very useful, and I strongly recommend using it prior to actual purging.
delete change pointers 2

3. “Unprocessed” change pointers that are deemed recent must be analyzed to determine why these records are configured for creation if they are never actually processed.  Perhaps, they were needed at one time, and are no longer needed now.  What I need from the functional business owners here is an agreement to turn off, in configuration, the creation of these change pointers.  Not turning them off will only continue to add unnecessary records to the change pointer tables.

After the creation of these change pointers is turned off in configuration, then schedule an execution of RBDCPCLR using the obsolete section on the selection screen.  Enter the message type in the message type box and the current date.  This will purge all change pointers of the specified message type, regardless of their status, up to the specified date.  Special care must be taken here to make sure that the selection options are entered correctly.

Note that on the selection screen there is also a “Test Run” check box that will list which records would be selected for purging, without actually purging them.  I find this feature very useful, and I strongly recommend using it prior to actual purging.
delete change pointers 3

4. Compare the list of message types that are configured to create change pointers (use SAP transaction BD50), to the list of message types in RBDMIDOC executions and the list of message types RBDCPCLR executions.  Make sure that all three lists agree.  Review these lists with the functional business owners.  Make sure that what is configured is meeting the needs of the current business processes.

I also ask the functional business owners to review the selected table-field values that, when changed or created new, will trigger the creation of change pointer records (use SAP transaction BD52).  The goal, again, is to make sure that what is configured is meeting the needs of the current business processes.

Now that we have cleaned up, how do we keep the size of the change pointer tables in check?
In my next post, I will discuss items that I recommend monitoring.

Comments

  1. Naresh Bharadwaj says:

    Hi Mike,

    Great series of blogs on change pointers.

    What does the “Scan Tables” option do? How is it different from the “Test Run”?

    N.

  2. Hello N.

    You would select the Scan Tables option if you have manually changed the number range for the change pointers. This also applies if the number range has been exhausted and rolls over from the beginning of the range.

    This option insures that all change pointers are included in the change pointer reorganization process. When RBDCPCLR is running with the scan option, no new change pointers can be generated whils the tables are being scanned. You will need to find a “change pointer quiet time” on your system.

    The test option allows RBDCPCLR to identify for you which change pointers meet the selection criteria for reorganization without actually deleting any records.

    Best Regards,
    Mike Salvo

  3. Prema Kota says:

    BD22 ie program RBDCPLR can only delete change pointers upto certain date. But how do you delete a single change pointer not deleting the ones before or after that. All I know in this case is change ponter ID and its in not processed status.

    Is there a program to delete specific change pointers?

  4. Mike Salvo says:

    Hello Prema,

    There is no standard SAP to delete a single change pointer. Program RBDCPCLR is driven by date and message type, which is more than likely to have more than one change pointer linked to it. You might want to consider a custom program to help with your situation.

    Best Regards,
    Mike Salvo

  5. Hi Mike,

    I am trying to run the job (for the program RBDMIDOC) faster for performance. And deleted records from BDCP and BDCPS tables using program RBDCPLR. Previously the count was 363K and now it is 1000+ records only. But the program RBDIDOC is still taking same amount of time to run i.e close to 5000 seconds in both cases.

    Can you please advise what’s the problem? Why the job taking the same amount of time in both cases.

    Thank you.
    Ananth

Add Comment Register



Speak Your Mind

*