Reduce SAP non-production system size: five levers

Why QA and test systems are almost the size of production

Most non-production systems are created from production: by system copy, which transfers the entire database, or by client copy including application data. Neither method has a notion of time. The copy profiles of a client copy select types of data, not years (see the copy profiles of the SAP client copy). Every copy therefore gets the full history, even if the last few months would do for testing.

In SAP HANA, this is expensive, because the data resides in main memory. Accordingly, SAP recommends a memory sizing for every HANA system, and for existing S/4HANA systems the SAP HANA Master Guide points to the sizing report from SAP Note 1872170. The amount of data in a system determines how much RAM it needs, and with it the size of the hardware or cloud instance. Put simply, three full copies alongside production mean roughly four times the main memory. Why this matters particularly now is explained in the article RAM prices and S/4HANA.

There are two basic approaches: make the source smaller so that every copy shrinks with it, or copy less of the source. The first three levers work in the database itself, usually starting in production. The last two apply to the copy.

Levers 1 and 2: SAP database size reduction at the source

Housekeeping of technical tables is the quickest lever. Application logs, IDocs, work items, change pointers, spool and job data grow for years in many systems without anyone needing them. SAP Note 2388483 lists the clean-up method for each technical table. Deletion reports and standard jobs handle most of it; some data has to be archived or agreed with internal audit first. Whatever is cleaned up in production is missing from every subsequent copy. The limit: housekeeping only affects technical data. Documents, postings and master data remain. Typical tables and the jobs to schedule are covered in the article Cleaning up technical tables.

Data archiving removes completed business transactions from the database and writes them to archive files. Apart from deletion, it is the only way to shrink the production database itself, with an effect on main memory, disk and backup. In return, it is a project involving the business departments, internal audit and data protection. Residence times and retention periods decide what may be archived, and open transactions stay online anyway. Even after archiving, several fiscal years therefore often remain in the database, and so in every full copy. The process, ILM and the limits are described in the article SAP archiving in S/4HANA.

Lever 3: reduce SAP HANA memory with data aging and NSE

Data aging and the Native Storage Extension (NSE) cut main memory requirements without removing data from the database. That is the key difference from the first two levers: the data becomes historical or warm, but it is not gone.

Data aging, as SAP describes it, moves operationally less relevant data within the database from the current area to a historical area to free up working memory. In SAP HANA, the historical area consists of separate partitions of the table. The application logic of the aging object decides when data becomes historical, for example FI_DOCUMENT for accounting documents. By default, ABAP programs cannot see historical data; programs that need it have to be adapted. This makes data aging a matter for development and the business departments, not just for Basis.

NSE, according to the SAP documentation, is a built-in warm data store in SAP HANA. Rarely used tables, partitions or columns are flagged as ‘page loadable’. They stay on disk and are loaded into main memory page by page, on demand, via a buffer cache. The NSE Advisor suggests suitable objects based on access statistics. Access to warm data not currently in the buffer cache goes to disk and takes longer.

What matters for non-production systems: according to SAP, warm data remains a full part of the database and participates in backup and system replication. The historical partitions used by data aging also belong to the table. Both methods reduce main memory, but not the data volume on disk, the backup or the amount of data a full copy has to move. Whether it is also warm or historical in the target depends on the target system’s table settings. How both methods differ from archiving is explained in the section Data aging and NSE of the archiving article.

Lever 4: shell copy, the lean system shell

A shell copy is a system copy without application data. SAP describes it in its ‘SAP S/4HANA Shell Creation’ service as an enhancement of the standard system copy. The new system contains the repository, cross-client Customizing, cross-client data and the complete reference client 000. Tables holding application data are deliberately excluded. The result has the same structure as the source but is much smaller.

This shell cannot be used for testing yet. Client-specific Customizing, users and application data have to be added afterwards, for example through a client copy with a Customizing profile, through transports or with a test data tool. This second step decides the final size of the system.

A shell copy fits when a system needs the development and Customizing status of production but hardly any data, such as a new project or development system. It is less suited to the regular refresh of a QA system. Like any system copy, it overwrites the repository status in the target, and building and filling it is a separate undertaking each time. The article SAP system copy covers the procedure and post-processing.

Lever 5: client copy by time slice

The fifth lever targets the client copy. Instead of the full history, a time-slice client copy transfers a period, for example the last 90 days. For the target to work from a business perspective, every object these documents refer to has to come along: master data, preceding documents and open items, even if they are years older. The repository and cross-client data in the target remain untouched.

Standard SAP does not offer this, as the client copy has no concept of a time frame. You need a tool that resolves the dependencies reliably, including custom tables. If a link in the document chain is missing, tests fail on data gaps rather than program errors. In return, the lever takes effect with every refresh without touching production. For load and performance tests with the full data volume, a full copy is still required.

The five levers compared

Lever	Effect on size	Effort	Effect on production	With every refresh	Typical limits
Housekeeping of technical tables	Less technical data in production and in every copy	Low to medium: set up jobs and retention periods once	Becomes smaller; the jobs run there	Yes, applies to every new copy	Technical data only; some tables only after agreement
Data archiving	The database shrinks: main memory, disk and backup	High: a project with business departments, internal audit and data protection	Becomes smaller; archived data via separate access paths	Yes, applies to every new copy	Residence and retention periods; several years often stay online
Data aging and NSE	Less main memory; disk and backup unchanged	Medium: select objects, set up partitions or the buffer cache, adapt programs for data aging	Less main memory; access to older data may take longer	Only if the target system has the same settings	Data stays in the database and in every full copy
Shell copy	Very small without application data; the subsequent filling decides	High: system copy with table exclusions, then a separate filling step	None; production is only the source	Rarely, mostly for building new systems	Not usable for testing until filled; overwrites the repository status in the target
Client copy by time slice	Target only as large as the period plus dependent objects	Medium: introduce a tool, define the period and exclusions	None; production is only the source	Yes, that is what it is designed for	Not part of standard SAP; unsuitable for load tests with the full volume

The table shows the division of labour. Housekeeping and archiving shrink the source and therefore everything copied from it. Data aging and NSE save main memory, but not volume. Shell copy and time slice make the target smaller without changing production.

Shrinking the QA system: which combination for what

No lever replaces the others. They act in different places and can be combined. A split that works well in many landscapes:

Always: housekeeping in production. It costs little, and every copy benefits.
In the long term: archiving for objects with large volumes and clear rules. It shrinks production, backups and every full copy.
For production main memory: data aging or NSE where data has to stay online. In non-production, they do not replace copying less data: disk, backup and copy volume stay the same.
For QA, test and sandbox with regular refreshes: the time slice. The effect recurs with every refresh.
For new project or development systems: the shell copy, if the production status is needed but hardly any application data.
For load and performance tests: still the full copy, for example in a pre-production system. Housekeeping and archiving make it smaller too.

First measure where the memory sits: the database size and the largest tables of each system, for example with DB02. The differences between system copy, client copy and time slice are set out in the comparison of client copy, system copy and time slice.

Reducing non-production size with the Data Refresh Operator

The Data Refresh Operator (DRO) works with the fifth lever. It copies a time slice, for example the last 90 days, and adds all dependent objects from earlier years. Dependencies are resolved up to the fixpoint – the verifiable point at which no new objects are added. Tables nobody needs in the test system can be excluded via exclusion lists, down to table level. The system measurement in the control system shows the database sizes of all connected systems, and therefore where this pays off. Production remains unchanged.

–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 runs on SAP S/4HANA from release 2023 and replaces the client copy, not the system copy. Housekeeping and archiving in production keep their value: they keep the source lean, while DRO determines how much of it reaches QA, test and sandbox. More on this on the page Reducing HANA memory in QA, test and sandbox.

We are happy to work out with you what this means for your landscape: Book a demo.

Sources

SAP Help (SAP HANA 2.0 SPS 08): SAP HANA Master Guide, section ‘Sizing SAP HANA’ (PDF)
SAP Note 2388483: How-To: Data Management for Technical Tables (SAP Support Portal, login required)
SAP Help (ABAP Platform 2025): Data Aging: Frequently Asked Questions
SAP Help (SAP HANA 2.0 SPS 08): SAP HANA Native Storage Extension
SAP: DMLT Service SAP S/4HANA Shell Creation (service description)

Reduce SAP non-production system size: five levers compared