October 1, 2025
BW, How-to
No Comments
ADSO Changelog

Reclaim BW/4HANA Memory from ADSO Changelogs

If you’ve worked with SAP BW(/4HANA) for even a short while, you’ve probably noticed something odd: change log tables growing, old delta requests lingering, and system storage needs growing, seemingly without any big changes in data volumes. This can become problematic as you might need to upscale your system if the necessary housekeeping steps are not implemented.

In this post, I’ll walk you through:

  1. What BW/4HANA changelogs are
  2. Why they accumulate over time
  3. How to set-up automatic cleanup
  4. what to do with Old Changelog requests that are not cleaned up
  5. How to identify the largest changelogs

What are BW/4HANA changelogs

A changelog is the internal mechanism that tracks every change (inserts, updates, deletes) that happens in a DataStore Object (ADSO). The changelog allows us to monitor data changes and enables upward delta processing since you can detect what has changed since the last load and pass only those changes onward instead of all the data.

Why do changelogs grow over time

Each system can have their own rules around traceability. this can even differ between domains. In Finance we might be obligated to retain change logs longer then Purchasing. This is presumably also the reason why by default there is no automatic changelog cleanup. This means that by default, changelogs are retained indefinitely.

How to set-up automatic cleanup

I would advise every BW4HANA system to have 1 generic housekeeping process chain in which different housekeeping activities can be maintained.

Within this housekeeping chain you can maintain 1 system wide variant for cleaning up changelogs for ADSOs. This variant should clean up all changelogs according to the maximum time any changelog should be kept in the system.

To cleanup changelogs in a process chain you can use the Clean up Old Requests in Datastore Objects (Advanced) component.

Create a variant and put:

  1. * as ADSO name
  2. Remove Old Requests from changelog as Clean-up Action
  3. The maximum days any changelog should be retained in the system – 100 days in the below example

Save the variant and activate the process chain.

When the changelogs of an ADSO are being cleaned, no data can be activated in the ADSO which is being cleaned. If there are a lot of changelogs in the system, you might want to initially start out with a higher number of days to be retained to do a more gradual cleanup.

Old Changelog requests not cleaned up

Even when the automatic changelog cleanup is correctly maintained you might encounter ADSOs with large changelogs or changelogs that are retained beyond the limit you’ve defined in the housekeeping.

In this section we’ll have a look at changelogs which are retained beyond the defined limit.
E.g. you have defined a 100 day retention period, but when checking a specific ADSO, you can find requests that are older than 100 days.

The most common reason causing changelog request to not be deleted is that there are some old requests which have not been propagated upwards. A changelog request cannot be deleted if the delta DTP to the next layer has not been executed for that request.

Using RSMNG, you can identify upward delta’s for an ADSO and when the last ran

  1. in RSMNG open the ADSO and show the connections
  2. in the right pane (targets), click the button to show al DTPs
  3. Only look at the Delta DTPS
  4. Note when they last ran

if there are delta DTPs that did not run for some time, it is usually caused by either:

  • A delta DTP that was decommisioned and should no longer run
  • A delta DTP that was ran , but should’ve not even existed

In both cases we’ll want to delete the culprit DTP, but this can be tricky with the normal procedure.
To be able to delete it we can use a program RSBK_LOGICAL_DELETE_DTP provided by SAP for doing a “logical Deletion” of the DTP. For more information, consult 1450242 – P24: Remove DTP from delta administration; logical deletion – SAP for Me.

To more easily identify ADSOs suffering from the above problem, we can pull some statistics from the system. We’ll go over a technique to do this in the next section.

Identify and monitoring the largest and oldest changelogs

Largest changelog tables

To easiest way to analyze the largest changelogs in the system is to use SQL directly on HANA.
We can get table statistics from M_CS_TABLES

select 
	table_name,
	round(sum(estimated_max_memory_size_in_total) / power(1024,2),0) as SIZE_MB 
from M_CS_TABLES
where table_name like '/BI%/A%3'
group by table_name
order by sum(estimated_max_memory_size_in_total) desc;

Oldest changelogs

Similarly, we can also get the tables containing the oldest changelogs, but from the RSPMREQUEST table in the ABAP Schema

set schema <your_abap_schema>;
select 
	datatarget,
	days_between(left(min(request_tsn),8),current_date) as age
from RSPMREQUEST
where storage = 'CL'
and request_status not in ('D','M')
group by datatarget
order by min(request_tsn) asc;

With the statistics from these 2 statements you are armed with enough information to dive deeper into problematic ADSOs and get them to a lean state.

Final thoughts

In itself, keeping your changelogs in check is a relatively easy activity. but as with everything – it would not be SAP if it was simple 🙂

Hopefully the information in this post has given you some necessary tools or additional information for reclaiming some of that expensive HANA memory in your system.

Tags: , ,