Data Refresh Operator
Reduce HANA memory in QA, test and sandbox
In S/4HANA, data resides in main memory – and every full copy pays for it again. If you size non-production systems according to their purpose, you cut one of the largest running costs of your landscape.
Why non-production is so expensive
Main memory determines the bill. With SAP HANA, RAM determines sizing, hardware or cloud instances, and licensing models. History used to sit on inexpensive disks; today it occupies the most expensive component of the infrastructure.
Full copies multiply the history. Besides production, a typical landscape has at least one QA, one development and one sandbox system. With standard client copies, each of them receives the full history – and therefore needs almost production-level sizing.
Testing needs only a fraction. For projects, releases and support, the last few months usually matter most. Even so, years or even decades of data are copied.
4× full history in main memory1× full history, plus lean time slices
Schematic diagram
Three levers for less main memory
- Reduce data in production
- Archiving and data aging shrink production itself. The effect is lasting, but it is a project of its own that requires alignment with the business departments. More on SAP archiving in S/4HANA
- Fewer non-production systems
- Merging systems saves memory but costs flexibility for parallel projects, releases and tests. Client strategy and system landscape
- Non-production only as large as necessary
- Time-slice-based client copies fill QA, test and sandbox only with the period that is needed – plus all dependent documents. Production remains unchanged.
How the Data Refresh Operator reduces memory
DRO copies business objects from a selected period, for example the last 90 days. DRO automatically adds dependent objects from earlier years – orders, contracts, master data – until the fixpoint is reached. The target client is fully usable from a business perspective and occupies only a fraction of the memory of a full copy.
Because smaller copies run faster, refreshes become routine: scheduled in line with your releases rather than as a major weekend operation. And storage and backups of the non-production systems shrink as well.
- –75%
- HANA RAM in non-production
- –60%
- Storage & backup
Guideline values from reference scenarios. The actual effects depend on system size, history and refresh cycles.
DRO measures the database sizes of all connected systems itself, in the control system – the basis for sizing non-production systems according to their purpose.
What would DRO save in your landscape?
In a free demo, we show you DRO live using your own use cases – remotely and with no obligation. We discuss where the benefits lie for memory, refresh time and operating costs, and how you can try DRO in your own landscape.
- Benefits specific to your use cases
- A live look at time slice, dependency resolution, export and import
- Answers directly from the team behind DRO