SAP-Non-Prod-Systeme verkleinern: fünf Hebel

Warum QS- und Testsysteme fast Produktionsgröße haben

Die meisten Non-Prod-Systeme entstehen aus der Produktion: per Systemkopie, die die ganze Datenbank überträgt, oder per Mandantenkopie mit Anwendungsdaten. Beide Wege kennen keinen Zeitraum. Die Kopierprofile der Mandantenkopie wählen Datenarten aus, keine Jahre (mehr dazu bei den Kopierprofilen der SAP-Mandantenkopie). Jede Kopie bekommt damit die komplette Historie, auch wenn für Tests die letzten Monate reichen.

In SAP HANA ist das teuer, weil die Daten im Hauptspeicher liegen. Entsprechend empfiehlt SAP für jedes HANA-System ein Memory-Sizing. Für bestehende S/4HANA-Systeme nennt der SAP HANA Master Guide dafür den Sizing-Report aus SAP-Hinweis 1872170. Wie viele Daten ein System enthält, bestimmt also, wie viel RAM es braucht, und damit die Größe von Hardware oder Cloud-Instanz. Drei Vollkopien neben der Produktion bedeuten, vereinfacht gerechnet, rund das Vierfache an Hauptspeicher. Warum das gerade jetzt ins Gewicht fällt, zeigt der Artikel RAM-Preise und S/4HANA.

Grundsätzlich gibt es zwei Ansatzpunkte: die Quelle verkleinern, damit jede Kopie kleiner wird, oder weniger aus der Quelle kopieren. Die ersten drei Hebel wirken in der Datenbank selbst, meist zuerst in der Produktion. Die letzten beiden setzen bei der Kopie an.

Hebel 1 und 2: die SAP-Datenbank an der Quelle verkleinern

Housekeeping technischer Tabellen ist der schnellste Hebel. Anwendungs-Logs, IDocs, Workitems, Änderungszeiger, Spool- und Jobdaten wachsen in vielen Systemen über Jahre, ohne dass jemand sie braucht. SAP-Hinweis 2388483 nennt zu jeder technischen Tabelle den Weg zur Bereinigung. Das meiste erledigen Lösch-Reports und Standardjobs, manches muss archiviert oder mit der Revision abgestimmt werden. Was in der Produktion bereinigt ist, fehlt in jeder folgenden Kopie. Die Grenze: Housekeeping betrifft nur technische Daten. Belege, Buchungen und Stammdaten bleiben. Welche Tabellen typisch sind und welche Jobs Sie einplanen, steht im Artikel Technische Tabellen aufräumen.

Datenarchivierung entfernt abgeschlossene Geschäftsvorfälle aus der Datenbank und schreibt sie in Archivdateien. Neben dem Löschen ist sie der einzige Weg, die Datenbank der Produktion selbst zu verkleinern, mit Wirkung auf Hauptspeicher, Platte und Backup. Dafür ist sie ein Projekt mit Fachbereichen, Revision und Datenschutz. Residenzzeiten und Aufbewahrungsfristen bestimmen, was archiviert werden darf. Offene Vorgänge bleiben ohnehin online. Auch nach der Archivierung stehen deshalb oft mehrere Geschäftsjahre in der Datenbank und damit in jeder Vollkopie. Ablauf, ILM und Grenzen beschreibt der Artikel SAP-Archivierung in S/4HANA.

Hebel 3: HANA-Speicher reduzieren mit Data Aging und NSE

Data Aging und die Native Storage Extension (NSE) senken den Bedarf an Hauptspeicher, ohne Daten aus der Datenbank zu entfernen. Das ist der wichtigste Unterschied zu den beiden ersten Hebeln: Die Daten werden historisch oder warm, aber sie sind nicht weg.

Data Aging verschiebt laut SAP operativ weniger relevante Daten innerhalb der Datenbank aus dem aktuellen in einen historischen Bereich, um Arbeitsspeicher zu gewinnen. In SAP HANA besteht dieser Bereich aus eigenen Partitionen der Tabelle. Wann Daten historisch werden, entscheidet die Anwendungslogik des Aging-Objekts, für Buchungsbelege etwa FI_DOCUMENT. Historische Daten sind für ABAP-Programme standardmäßig nicht sichtbar. Programme, die sie lesen sollen, müssen dafür angepasst werden. Data Aging ist damit ein Thema für Entwicklung und Fachbereich, nicht nur für die Basis.

NSE ist laut SAP-Dokumentation ein eingebauter Warm-Speicher in SAP HANA. Selten genutzte Tabellen, Partitionen oder Spalten werden als „page loadable“ gekennzeichnet. Sie liegen auf der Platte und kommen nur seitenweise und bei Bedarf über einen Buffer Cache in den Hauptspeicher. Welche Objekte sich eignen, schlägt der NSE Advisor anhand von Zugriffsstatistiken vor. Zugriffe auf warme Daten, die gerade nicht im Buffer Cache liegen, gehen über die Platte und dauern länger.

Für Non-Prod-Systeme ist entscheidend: Warme Daten bleiben laut SAP vollständiger Teil der Datenbank und nehmen an Backup und Systemreplikation teil. Auch die historischen Partitionen des Data Aging gehören zur Tabelle. Beide Verfahren senken den Hauptspeicher, nicht aber das Datenvolumen auf der Platte, das Backup oder die Datenmenge, die eine Vollkopie bewegt. Ob die Daten im Ziel ebenfalls nur warm oder historisch liegen, hängt von den Tabelleneinstellungen im Zielsystem ab. Wie sich beide Verfahren von der Archivierung abgrenzen, zeigt der Abschnitt Data Aging und NSE im Archivierungsartikel.

Hebel 4: Shell-Kopie, die schlanke Systemhülle

Eine Shell-Kopie ist eine Systemkopie ohne Anwendungsdaten. SAP beschreibt sie in seinem Service „SAP S/4HANA Shell Creation“ als Erweiterung der Standard-Systemkopie. Das neue System enthält das Repository, das mandantenübergreifende Customizing, mandantenübergreifende Daten und den vollständigen Referenzmandanten 000. Tabellen mit Anwendungsdaten werden gezielt ausgeschlossen. Das Ergebnis hat die Struktur der Quelle, ist aber deutlich kleiner.

Testfähig ist diese Hülle noch nicht. Mandantenabhängiges Customizing, Benutzer und Anwendungsdaten müssen danach gezielt hinein, etwa per Mandantenkopie mit einem Customizing-Profil, per Transport oder über ein Werkzeug für Testdaten. Wie groß das System am Ende wird, entscheidet diese zweite Befüllung.

Die Shell-Kopie passt, wenn ein System den Entwicklungs- und Customizing-Stand der Produktion braucht, aber kaum Daten: etwa ein neues Projekt- oder Entwicklungssystem. Für den regelmäßigen Refresh eines QS-Systems eignet sie sich weniger. Wie jede Systemkopie überschreibt sie den Repository-Stand im Ziel, und Aufbau und Befüllung sind jedes Mal ein eigenes Vorhaben. Wie eine Systemkopie abläuft und was danach zu tun ist, beschreibt der Artikel SAP-Systemkopie.

Hebel 5: Mandantenkopie per Zeitscheibe

Der fünfte Hebel setzt bei der Mandantenkopie an. Eine zeitscheiben-basierte Mandantenkopie überträgt nicht die gesamte Historie, sondern einen Zeitraum, zum Beispiel die letzten 90 Tage. Damit das Ziel fachlich funktioniert, müssen alle Objekte mitkommen, auf die diese Belege verweisen: Stammdaten, Vorgängerbelege und offene Posten, auch wenn sie Jahre älter sind. Repository und mandantenübergreifende Daten im Ziel bleiben unberührt.

Der SAP-Standard bietet das nicht, die Mandantenkopie kennt keinen Zeitraum. Nötig ist ein Werkzeug, das die Abhängigkeiten zuverlässig auflöst, einschließlich kundeneigener Tabellen. Fehlt ein Glied der Belegkette, scheitern Tests an Datenlücken statt an Programmfehlern. Dafür wirkt der Hebel bei jedem Refresh, ohne die Produktion anzufassen. Für Last- und Performancetests mit dem vollen Datenvolumen bleibt die Vollkopie trotzdem nötig.

Die fünf Hebel im Vergleich

Hebel	Wirkung auf die Größe	Aufwand	Wirkung auf die Produktion	Bei jedem Refresh	Typische Grenzen
Housekeeping technischer Tabellen	Weniger technische Daten in der Produktion und in jeder Kopie	Gering bis mittel: Jobs und Fristen einmal einrichten	Wird kleiner, die Jobs laufen dort	Ja, wirkt in jeder neuen Kopie	Nur technische Daten; manche Tabellen erst nach Abstimmung
Datenarchivierung	Datenbank wird kleiner: Hauptspeicher, Platte und Backup	Hoch: Projekt mit Fachbereichen, Revision und Datenschutz	Wird kleiner, Archivdaten über eigene Zugriffswege	Ja, wirkt in jeder neuen Kopie	Residenzzeiten und Aufbewahrung; mehrere Jahre bleiben oft online
Data Aging und NSE	Weniger Hauptspeicher; Platte und Backup unverändert	Mittel: Objekte auswählen, Partitionen oder Buffer Cache einrichten, bei Data Aging Programme anpassen	Weniger Hauptspeicher, Zugriffe auf ältere Daten können länger dauern	Nur, wenn das Zielsystem gleich eingestellt ist	Daten bleiben in der Datenbank und in jeder Vollkopie
Shell-Kopie	Sehr klein ohne Anwendungsdaten; am Ende entscheidet die Befüllung	Hoch: Systemkopie mit Tabellenausschlüssen, danach eigene Befüllung	Keine, die Produktion ist nur Quelle	Selten, meist für den Aufbau neuer Systeme	Ohne Befüllung nicht testfähig; überschreibt den Repository-Stand im Ziel
Mandantenkopie per Zeitscheibe	Ziel nur so groß wie Zeitraum plus abhängige Objekte	Mittel: Werkzeug einführen, Zeitraum und Ausnahmen festlegen	Keine, die Produktion ist nur Quelle	Ja, dafür gedacht	Nicht im SAP-Standard; für Lasttests mit vollem Volumen ungeeignet

Die Tabelle zeigt die Arbeitsteilung: Housekeeping und Archivierung verkleinern die Quelle und damit alles, was daraus kopiert wird. Data Aging und NSE sparen Hauptspeicher, aber kein Volumen. Shell-Kopie und Zeitscheibe verkleinern das Ziel, ohne die Produktion zu ändern.

QS-System verkleinern: welche Kombination wofür

Kein Hebel ersetzt die anderen. Sie wirken an verschiedenen Stellen und lassen sich kombinieren. Eine Aufteilung, die sich in vielen Landschaften anbietet:

Immer: Housekeeping in der Produktion. Es kostet wenig, und jede Kopie profitiert.
Langfristig: Archivierung für Objekte mit großem Volumen und klaren Regeln. Sie verkleinert Produktion, Backups und jede Vollkopie.
Für den Hauptspeicher der Produktion: Data Aging oder NSE, wo Daten online bleiben müssen. Für Non-Prod ersetzen sie das Kopieren von weniger Daten nicht, denn Platte, Backup und Kopiervolumen bleiben.
Für QS, Test und Sandbox mit regelmäßigem Refresh: die Zeitscheibe. Der Effekt wiederholt sich bei jedem Refresh.
Für neue Projekt- oder Entwicklungssysteme: die Shell-Kopie, wenn der Stand der Produktion gebraucht wird, aber kaum Anwendungsdaten.
Für Last- und Performancetests: weiterhin die Vollkopie, etwa in einem Pre-Production-System. Housekeeping und Archivierung machen auch sie kleiner.

Messen Sie vorher, wo der Speicher liegt: je System die Datenbankgröße und die größten Tabellen, etwa mit DB02. Wie sich Systemkopie, Mandantenkopie und Zeitscheibe im Einzelnen unterscheiden, zeigt der Vergleich von Mandantenkopie, Systemkopie und Zeitscheibe.

Non-Prod-Systeme verkleinern mit dem Data Refresh Operator

Der Data Refresh Operator (DRO) setzt beim fünften Hebel an. Er kopiert eine Zeitscheibe, zum Beispiel die letzten 90 Tage, plus alle abhängigen Objekte aus älteren Jahren, aufgelöst bis zum Fixpunkt. Nachweisbar fehlt nichts. Tabellen, die im Testsystem niemand braucht, schließen Sie über Ausnahmelisten bis auf Tabellenebene aus. Die Systemvermessung im Control-System zeigt die Datenbankgrößen aller verbundenen Systeme und damit, wo sich das lohnt. Die Produktion bleibt unverändert.

–75 %: HANA-RAM in Non-Prod
–60 %: Storage & Backup

Richtwerte aus Referenzszenarien. Die tatsächlichen Effekte hängen von Systemgröße, Historie und Refresh-Zyklen ab.

DRO läuft ab SAP S/4HANA 2023 und ersetzt die Mandantenkopie, nicht die Systemkopie. Housekeeping und Archivierung in der Produktion behalten ihren Wert: Sie halten die Quelle schlank, DRO bestimmt, wie viel davon in QS, Test und Sandbox ankommt. Mehr dazu auf der Seite HANA-Speicher in QS, Test und Sandbox senken.

Was das für Ihre Landschaft bedeutet, rechnen wir gern mit Ihnen durch: Vorstellungstermin vereinbaren.

Quellen

SAP-Hilfe (SAP HANA 2.0 SPS 08): SAP HANA Master Guide, Abschnitt „Sizing SAP HANA“ (PDF, englisch)
SAP-Hinweis 2388483: How-To: Data Management for Technical Tables (SAP-Support-Portal, Anmeldung nötig)
SAP-Hilfe (ABAP-Plattform 2025): Data Aging: Häufig gestellte Fragen
SAP-Hilfe (SAP HANA 2.0 SPS 08): SAP HANA Native Storage Extension
SAP: DMLT Service SAP S/4HANA Shell Creation (Servicebeschreibung, englisch)

SAP-Non-Prod-Systeme verkleinern: fünf Hebel im Vergleich