System-Refresh oder Mandanten-Refresh: Was passt wann?

System-Refresh vs. Mandanten-Refresh: die Begriffe

Ein SAP-Refresh überschreibt ein bestehendes System oder einen bestehenden Mandanten mit aktuellen Daten aus einer Quelle, meist aus der Produktion. Das Ziel bekommt den Datenstand der Quelle und soll trotzdem Testsystem bleiben, mit eigener System-ID, eigenen Verbindungen und eigenen Benutzern. Wie ein solcher Refresh als Projekt abläuft, zeigt das Runbook für den QS-Refresh. Hier geht es um die Frage davor: welches Verfahren?

Beim System-Refresh wird das Zielsystem per Systemkopie überschrieben. In S/4HANA-Landschaften ist das eine homogene Kopie mit SAP HANA Backup und Restore und dem Software Provisioning Manager (SWPM). Übertragen wird immer die gesamte Datenbank: das Repository mit Programmen und Dictionary-Objekten, die mandantenübergreifenden Daten und alle Mandanten. Einzelne Komponenten lassen sich laut SAP weder auswählen noch ausschließen.

Beim Mandanten-Refresh wird nur ein Mandant per Mandantenkopie überschrieben: lokal im selben System, remote über RFC oder per Export und Import. Übertragen werden die mandantenabhängigen Daten, je nach Kopierprofil Customizing, Anwendungsdaten und Benutzerstämme. Repository, mandantenübergreifende Einstellungen und die übrigen Mandanten des Zielsystems bleiben unberührt. Mandantenübergreifendes Customizing lässt sich bei der Remote-Kopie und beim Mandantentransport zwar mitnehmen. SAP sieht das aber nur für den Aufbau eines neuen Systems vor, weil bestehende Mandanten sonst Schaden nehmen können. Transaktionen und Profile erklärt der Grundlagenartikel zur SAP-Mandantenkopie.

Systemkopie vs. Mandantenkopie im Vergleich

Die Tabelle stellt beide Wege für den Refresh eines QS- oder Testsystems aus der Produktion gegenüber:

Vereinfachte Gegenüberstellung nach dem SAP-Leitfaden zur Systemkopie mit SWPM 2.0 und SAP Learning. Die Transaktionen mit N am Ende gibt es ab SAP_BASIS 7.54 (S/4HANA 1909).

Vorbehalt beim Mandantentransport. Im Leitfaden zur Systemkopie schreibt SAP, dass der Mandantentransport keine Methode für eine Systemkopie ist und der Transport von Produktivmandanten nicht unterstützt wird. Vorgesehen ist er für den Erstaufbau einer Systemlandschaft. Für einen Mandanten-Refresh aus der Produktion ist deshalb die Remote-Kopie mit SCC9 bzw. SCC9N der Weg, nicht SCC8 und SCC7.

Entwicklungsstand, Downtime und Nacharbeiten

Entwicklungsstand und Transporte. Der wichtigste Unterschied liegt im Repository. Ein QS-System ist der Produktion meist voraus: Dort liegen Transporte, die getestet, aber noch nicht produktiv sind. Eine Systemkopie ersetzt das Repository durch das der Produktion. Diese Transporte fehlen danach und müssen erneut importiert werden, bevor die Tests weitergehen.

Bei einer Mandantenkopie bleibt das Repository des Ziels erhalten. Überschrieben wird aber das mandantenabhängige Customizing. Auch hier müssen Customizing-Transporte nachgezogen werden, die noch nicht produktiv sind. Dafür gibt es eine andere Hürde: Die Remote-Kopie setzt laut SAP identische Tabellenstrukturen in beiden Systemen voraus. Liegen Quelle und Ziel auf unterschiedlichen Support-Package-Ständen, passen nicht alle Tabellen zusammen. Wie SCC9N damit umgeht, beschreibt der Artikel Neue Mandantenkopie-Tools ab S/4HANA 1909.

Andere Mandanten. Eine Systemkopie bringt genau die Mandanten der Quelle mit. Mandanten, die es nur im Zielsystem gab, etwa ein Schulungs- oder Projektmandant in QS, sind danach weg. Wer sie behalten will, muss sie vorher sichern, zum Beispiel per Mandantenexport. Ein Mandanten-Refresh lässt sie in Ruhe.

Downtime. Beim System-Refresh steht das ganze Zielsystem still, für alle Mandanten und alle Nutzer. Die Dauer hängt an der Datenbankgröße: Sicherung, Übertragung, Restore und danach die Nacharbeiten. SAP empfiehlt, die Ausfallzeit mit einem Testlauf zu ermitteln. Beim Mandanten-Refresh ist der Zielmandant gesperrt, der Quellmandant optional. Die Laufzeit wächst mit der Menge der Anwendungsdaten. SAP nennt mehrere Stunden bis Tage und weist darauf hin, dass Datenmenge, Speicherbedarf und Kopierzeit bei Produktivmandanten erheblich sein können. Wo sich Zeit sparen lässt, zeigt der Artikel Mandantenkopie beschleunigen.

Nacharbeiten. Nach einer Systemkopie trägt das Ziel die Einstellungen der Produktion. Der SAP-Leitfaden listet eine lange Reihe von Schritten, vom neuen Lizenzschlüssel in SLICENSE über das Leeren der Tabellen TPFET und TPFHT und den Neuimport der Profile in RZ10 bis zu RFC-Destinationen, Jobs, Zertifikaten und dem Transportwesen in STMS. BDLS setzt mandantenabhängige und mandantenunabhängige Tabellen um. Nach einer Mandantenkopie bleiben die systemweiten Einstellungen, wie sie waren. Übrig bleiben die mandantenbezogenen Schritte: logische Systemnamen mit BDLS nur in den mandantenabhängigen Tabellen umsetzen, Benutzer zurückspielen, Schnittstellen, Jobs, Ausgabe und Nummernkreise prüfen. Die vollständigen Listen stehen in den Nacharbeiten nach der Systemkopie und in der Checkliste nach der Mandantenkopie.

Platz. Für den System-Refresh braucht das Ziel Platten- und Hauptspeicher für die komplette Datenbank, also etwa das Sizing der Produktion, dazu Platz für die Sicherung. Beim Mandanten-Refresh zählt die Größe des Mandanten. Eine zusätzliche lokale Kopie lässt die Datenbank um den kopierten Mandanten wachsen. SCC_CLIENT_SIZE schätzt den Bedarf vorab, laut SAP aber nur näherungsweise. Mit der Standard-Mandantenkopie kommt die komplette Historie des Mandanten mit, und in SAP HANA liegt sie im Hauptspeicher.

Typische Einsatzfälle

Aus den Unterschieden ergeben sich klare Muster, wann welcher Refresh passt:

• QS komplett auf Produktionsstand: Soll QS ein vollständiges Abbild der Produktion sein, mit Repository und allen Mandanten, ist der System-Refresh der passende Weg. Danach folgen die Transporte, die noch nicht produktiv sind.
• Last- und Performancetests: Aussagekräftige Laufzeiten brauchen realistische Datenmengen. Dafür ist meist eine Systemkopie nötig.
• Sandbox: Eine Sandbox mit dem Stand der Produktion, etwa für Probeläufe von Upgrades oder zum Nachstellen von Fehlern, entsteht per Systemkopie. Braucht eine bestehende Sandbox nur frische Daten, genügt der Mandanten-Refresh.
• QS mit laufenden Projekten: Ein QS-System mit Transporten in der Pipeline bekommt neue Daten per Remote-Mandantenkopie. Der Entwicklungsstand bleibt erhalten.
• Schulungsmandant: Ein Vorlagemandant hält stabile Beispieldaten. Vor jedem Kurs wird der Schulungsmandant daraus per lokaler Mandantenkopie neu aufgesetzt.
• Mehrere Mandanten in einem System: Liegen Test-, Schulungs- und Projektmandant in einem System, frischen Sie jeden für sich auf. Eine Systemkopie würde alle auf einmal ersetzen.

Wie Systeme und Mandanten in einer Landschaft üblicherweise verteilt sind, beschreibt der Artikel SAP-Systemlandschaft und Mandantenkonzept.

Entscheidungshilfe: sieben Fragen vor dem SAP-Refresh

Bevor Sie ein SAP-Testsystem aktualisieren, helfen diese Fragen bei der Wahl des Verfahrens:

1. Brauchen Sie im Ziel den Entwicklungsstand der Produktion? Wenn ja, etwa für eine Sandbox oder für Performancetests, ist der System-Refresh der Weg. Soll das Ziel seinen Stand mit allen Transporten behalten, spricht das für den Mandanten-Refresh.
2. Gibt es im Zielsystem Mandanten, die ihren Stand behalten sollen? Dann frischen Sie gezielt einzelne Mandanten auf. Eine Systemkopie ersetzt alle.
3. Stimmen Release und Support-Package-Stand überein? Die Remote-Kopie braucht identische Tabellenstrukturen. Ist das Ziel weiter, etwa mitten in einem Upgrade-Projekt, prüfen Sie die Mandantenkopie zuerst im Testmodus. Eine Systemkopie würde das Ziel auf den Stand der Produktion zurücksetzen.
4. Brauchen die Tests das volle Datenvolumen? Für Last- und Performancetests ja, dann passt die Systemkopie. Funktions- und Integrationstests brauchen vollständige Belegketten, aber selten jedes Jahr der Historie.
5. Wer ist von der Downtime betroffen? Beim System-Refresh alle Nutzer des Zielsystems, beim Mandanten-Refresh die des Zielmandanten. Die Dauer leiten Sie aus dem letzten Lauf oder einem Testlauf ab.
6. Wie viel Platz und Hauptspeicher hat das Ziel? Die Systemkopie braucht das Sizing der Produktion, die Standard-Mandantenkopie den Platz des Mandanten samt kompletter Historie.
7. Wie oft soll aufgefrischt werden? Je häufiger der Refresh, desto stärker zählen Laufzeit und Nacharbeiten. Das spricht für den kleineren Umfang: Mandant statt System, Zeitraum statt kompletter Historie.

Führen die meisten Antworten zum Mandanten-Refresh, sind aber Laufzeit und Platz das eigentliche Problem, lohnt der Blick auf eine dritte Option.

Dritte Option: Mandantenkopie mit Zeitscheibe

Zwischen beiden Wegen liegt die zeitscheiben-basierte Mandantenkopie. Sie überschreibt wie die Mandantenkopie nur einen Mandanten. Kopiert wird aber nicht die komplette Historie, sondern ein Zeitraum, zum Beispiel die Belege der letzten 90 Tage. Damit der Zielmandant fachlich funktioniert, müssen alle Objekte mitkommen, auf die diese Belege verweisen: Stammdaten, Vorgängerbelege und offene Posten, auch wenn sie Jahre älter sind.

Der Gewinn liegt bei Laufzeit und Platz. Weniger Daten heißt eine kürzere Kopie, weniger Hauptspeicher im Ziel und weniger Tabelleninhalt, den BDLS durchsuchen muss. Die Grenze: Sonderfälle, die nur in älteren Daten stecken, fehlen. Für Last- und Performancetests mit vollem Datenvolumen bleibt die Systemkopie der passende Weg.

Mit den Standardwerkzeugen geht das nicht, denn Kopierprofile wählen Datenarten aus, keinen Zeitraum. Nötig ist ein Werkzeug, das die Abhängigkeiten zwischen den Objekten auflöst. In ECC-Landschaften war dafür oft SAP TDMS im Einsatz. Laut SAP-Hinweis 2696183 wird TDMS im S/4HANA-Kontext nicht unterstützt. Mehr zur Teilkopie lesen Sie im Artikel Testdaten für S/4HANA.

Mandanten-Refresh mit dem Data Refresh Operator

Der Data Refresh Operator (DRO) setzt diese dritte Option für SAP S/4HANA um. 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. Logische Systemnamen ersetzt DRO beim Import, bevor die Daten in die Datenbank geschrieben werden. Ein nachträglicher BDLS-Lauf entfällt. Playbooks automatisieren den Ablauf drumherum: Ankündigung, Ramp-down, Backup der Benutzerstämme, Import, kundenspezifische Nacharbeiten und Ramp-up.

3–5×

schneller als eine Vollkopie, in der Praxis

0

BDLS-Läufe nach dem Import

Praxiswert, keine Garantie. Je nach System, Zeitraum und Ausnahmelisten kann der Vorteil auch deutlich größer sein. DRO läuft ab SAP S/4HANA 2023.

Für die Entscheidung oben heißt das: DRO ersetzt die Mandantenkopie, nicht die Systemkopie. Wo Sie einen System-Refresh brauchen, etwa für Performancetests oder eine Sandbox mit dem Entwicklungsstand der Produktion, bleibt es bei SWPM. Wie Standard-Mandantenkopie, Systemkopie und Zeitscheibe im Detail abschneiden, zeigt der Vergleich von Mandantenkopie, Systemkopie und Zeitscheibe. Welcher Weg zu Ihrer Landschaft passt, besprechen wir gern mit Ihnen: Vorstellungstermin vereinbaren.

Quellen

• SAP-Hilfe: System Copy for SAP ABAP Systems Based on UNIX: SAP HANA 2.0 Database, Using Software Provisioning Manager 2.0 (PDF)
• SAP Learning: Client Copy and Client Transport Tools (englisch)
• SAP-Hilfe: Umsetzung logischer Systeme (SAP NetWeaver 7.0 EHP3)
• SAP-Hinweis 2696183: TDMS-Komponenten bei Installation und Upgrade von S/4HANA 1809/1909 (SAP-Support-Portal, Anmeldung nötig)