Skip to Content

The Fear Factor in SAP World – Part 2


 In this blog, I would like to discuss about change log deletion for Data Store Object(DSO) or Operational Data Store(ODS) as it was previously known. I too often hear  that the disk space is very cheap so focusing on optimizing the disk space utilization is a waste of time and efforts. I will give an example why this argument is not valid. I will also show you how mere 315GB of disk space translates to 10.5 Tera Bytes of disk/tape space.

Change log Deletion

SAP documentation states: 

“We recommend that you delete data from the change log of a datastore object if several requests that are no longer needed for the delta update and are no longer used for an initialization from the change log have already been loaded into the datastore object. If a delta initialization is available for updates to connected InfoProviders, requests have to be updated before the corresponding data can be deleted from the change log.

A temporary, limited history is retained. In some case the change log becomes so large that is advisable to reduce the volume of data and delete data from a specific time period.”

Here is another document titled “Important Housekeeping Principles for keeping your SAP Netweaver BW in good shape”:


Page 9 of this document states:



In one of the sites I support, the functional team has not implemented periodic deletion of change logs. As a result, the production database has 315GB of change logs. The database size is approximately 950GB. This means approximately 1/3rd of the database contains change log.

315GB of disk space equals 10.5 TB of Disk/Tape space. How?

 As stated earlier, the production database conatins 315GB of change log. This site has DR site with identical configuration. Data is replicated(mirror) to this site. Therefore DR site contains 315GB of change logs.

In addition, we backup this database every day with a retention period of 1 month so  9.450 TB (30 times 315GB) of tape space is used to store change logs; and the tapes would require physical storage space as well.

In addition, whenever we perform the system copy, 315Gb of change log is copied too. In addition to extra time spent in restoring the database, 315GB of change log is replicated to our sandbox.

The details of disk space consumption in a tabular form are given below:



Change log size

Production Disk


Production DR Site




QA System

175GB (Copied 2 years ago)

Tape (backup)

9.4 TB

Total Disk/Tape Space requirements

10.5 Tera Bytes






Other issues of not deleting change logs regularly

  • Since change logs undergo changes almost daily, update statistics not only runs on change log tables frequently but also runs longer because a few of change log tables contain more than 100 million records.
  • The system copy takes longer
  • The regular backup takes longer


The functional team unfortunately doesn’t want to come up with a process to delete change logs periodically because:

  • the disk is very cheap so they don’t want spend time in optimizing the disk space utilization
  • if data is corrupted, they could use the change logs to reload.
You must be Logged on to comment or reply to a post.
  • Yeah, it is fanny how many know that storage is cheap, but do not realize that PROCESSING still costs. You gave great examples of impact on processing side, like backups, system copies etc.
    My other example is designing the cubes that are sparse. Sometimes whole columns (key figures) are all zeros. It still costs to store and it costs to process this zero value information.
    Another thing that makes me smile is being proud of having TBs systems, like BW, and still have hundreds of GBs occupied by temporary, badly designed or unused data.
  • Rahul and Tamada:

    “Proud of having TBs of systems”: Yes,that makes me smile as well.
    Thanks for your comments,