SAP-Mandantenkopie beschleunigen: Laufzeit verstehen und verkürzen

Wovon die Laufzeit einer Mandantenkopie abhängt

Dass Kopien mit der Historie wachsen, beschreibt der Grundlagenartikel im Abschnitt Warum Mandantenkopien so lange dauern. Hier geht es um die einzelnen Faktoren. Die Dauer einer Mandantenkopie ergibt sich aus zwei Größen: wie viele Daten bewegt werden und wie schnell System und Datenbank sie bewegen können.

Den Umfang sollten Sie kennen, bevor Sie an Parametern drehen. SAP empfiehlt vor dem Kopieren einen Testlauf. Sein Protokoll zeigt, welche Tabellen mit wie vielen Daten betroffen sind. Ab SAP_BASIS 7.54 schätzt zusätzlich die Transaktion SCC_CLIENT_SIZE die Größe eines Mandanten aus Zeilenzahl und Tabellengröße.

Wo die Zeit verloren geht

Die neuen Kopierwerkzeuge, die SAP mit SAP_BASIS 7.54 (S/4HANA 1909) eingeführt hat, arbeiten in vier Phasen. Welche Transaktionen dazugehören, zeigt der Artikel Neue Mandantenkopie-Tools ab S/4HANA 1909.

1. Initialisierung. Die Liste der relevanten Tabellen wird aufgebaut, die Mandanten werden gesperrt.
2. Analyse. Exits legen fest, welche Tabellen geleert, kopiert oder ausgelassen werden. Sehr große Tabellen werden in Pakete zerlegt.
3. Löschen und Kopieren. Zuerst werden die Tabellen im Zielmandanten geleert, dann die Daten der Quelle eingefügt. Diese Phase wächst direkt mit der Datenmenge.
4. Nachbearbeitung. Exits passen Daten im Ziel an, die Sperren werden aufgehoben, das Protokoll wird geschrieben.

Tabellen, die in allen Mandanten leer sind, erkennt das Werkzeug an den Statistiken der HANA-Datenbank und überspringt sie. Kopieren Sie wiederholt zwischen denselben Mandanten, lässt es außerdem Tabellen aus, die sich seit dem letzten Lauf nicht geändert haben. Das hilft vor allem, wenn Sie einen abgebrochenen Lauf wiederholen. Einen klassischen Neustart an der Abbruchstelle bieten die neuen Werkzeuge nicht.

Wichtig für die Planung: Die gesamte Laufzeit ist Ausfallzeit. Der Zielmandant ist gesperrt, und auch im Quellmandanten soll laut SAP während der Kopie nicht gearbeitet werden, weil sonst Inkonsistenzen entstehen können. Bei einer Kopie aus der Produktion ist das ein starkes Argument für kurze Läufe.

Mandantenkopie parallel: Prozesse richtig einstellen

Der wichtigste Hebel im Werkzeug selbst ist die Parallelisierung. Über die Parameter für parallele Prozesse legen Sie fest, wie viele Prozesse die Kopie höchstens nutzt und aus welcher RFC-Servergruppe sie kommen. Die Servergruppe pflegen Sie in RZ12. Parallele Prozesse nutzen lokale und Remote-Kopien ebenso wie das Löschen eines Mandanten.

• Anzahl: Als Richtwert nennt die SAP-Hilfe zwei Prozesse je verfügbarer Datenbank-CPU. Die Zahl der Applikationsserver ist dabei nicht begrenzt.
• Dialogprozesse einplanen: Die parallelen Prozesse sind immer Dialogprozesse, auch wenn der Hauptlauf im Hintergrund startet. Die Server der Gruppe brauchen also genug freie Dialog-Workprozesse. Der automatische Schutz vor Ressourcenüberlastung kann die Zahl zusätzlich begrenzen.
• Laufzeitgrenze prüfen: Dialogprozesse haben eine maximale Laufzeit. Für große Kopien empfiehlt SAP, diese Grenze zu erhöhen, bei Remote-Kopien auch im Quellsystem. Welcher Profilparameter sie in Ihrem Kernel-Release steuert, prüfen Sie in RZ11.
• Große Tabellen splitten: Die neuen Werkzeuge zerlegen sehr große Tabellen über eigene WHERE-Bedingungen in Pakete und kopieren diese parallel. Das beschleunigt den Lauf und verhindert, dass Speichergrenzen in SAP HANA oder im ABAP-Server überschritten werden. Ab SAP_BASIS 7.56 ist das Splitten fest aktiviert.
• Exklusive Sperren: Mit dieser Option sperrt die Kopie jede Tabelle während des Kopierens exklusiv in der Datenbank. Das spart Speicher und Zeit, blockiert die Tabelle aber für alle anderen Zugriffe.

Die Servergruppe wertet die Kopie nur einmal zu Beginn der Kopierphase aus. Änderungen während des Laufs greifen erst beim nächsten Start. Ob die Einstellung trägt, sehen Sie im Lauf: den Fortschritt in SCC3, die Workprozesse in SM50 und lang laufende SQL-Anweisungen in DB02 oder im SAP HANA Cockpit. Wie Sie Protokolle lesen und Abbrüche behandeln, zeigt der Artikel SCC3 und typische Fehler bei der Mandantenkopie.

Lokal, remote oder Export: was schneller ist

Lokal bleiben die Daten in der Datenbank. Die neue lokale Kopie (SCCLN) überträgt sie per INSERT aus SELECT direkt vom Quell- in den Zielmandanten, ohne Umweg über den Applikationsserver. Nach internen Tests von SAP ist sie rund zehnmal schneller als das alte Werkzeug.

Remote (SCC9N) holt das Zielsystem die Daten per RFC aus der Quelle. Jede Zeile läuft über Applikationsserver und Netz, Bandbreite und Latenz zwischen den Systemen zählen also mit. Vorab vergleicht das Werkzeug die Tabellendefinitionen beider Systeme und lässt inkompatible Tabellen aus. Die neue Remote-Kopie ist laut SAP bis zu fünfmal schneller als die alte. Für den QS-Refresh aus der Produktion ist sie trotzdem der Normalfall, denn lokal geht nur innerhalb eines Systems.

Export und Import (SCC8N, SCC7N) teilen die Kopie in zwei Läufe mit Dateien dazwischen. Das spart keine Arbeit, entkoppelt aber Quell- und Zielsystem. Ab SAP_BASIS 7.55 gibt es zusätzlich Mandanten-Snapshots, die direkt in der Datenbank liegen. Laut SAP sind sie in der Regel doppelt so schnell wie der Export in Transportaufträge.

Weitere Stellschrauben

• Zielmandant leer: Ein gefüllter Zielmandant wird vor dem Kopieren geleert, und das kostet Zeit im Kopierfenster. SAP empfiehlt deshalb, in einen neu angelegten Mandanten zu kopieren, statt einen bestehenden zu überschreiben. Alternativ löschen Sie den alten Zielmandanten vorab mit SCC5N, das ebenfalls parallel arbeitet. Die Arbeit fällt damit nicht weg, liegt aber vor dem eigentlichen Fenster. Eine neue Mandantennummer hat Folgen, etwa für logische Systeme und Schnittstellen. Das gehört in die Planung.
• Technische Tabellen bereinigen: IDocs, Workitems oder Änderungszeiger wachsen in der Produktion oft unbemerkt und reisen mit jeder Kopie mit. Was dort regelmäßig bereinigt wird, muss keine Kopie mehr bewegen. Wie das geht, zeigt der Artikel Technische Tabellen aufräumen.
• Ruhe im System: Auch Benutzer und Jobs in anderen Mandanten verzögern die Kopie, etwa über Sperren. SAP rät, Quell- und Zielmandant per Systemnachricht (SM02) zu sichern und die Anmeldungen in SM04 zu kontrollieren.
• Korrekturen einspielen: SAP bündelt Empfehlungen zur Performance in KBA 2163425, für große Produktivmandanten in Hinweis 489690, für SAP HANA in Hinweis 2555451 und für Remote-Kopien in S/4HANA in KBA 2953662. Viele Korrekturen gelten nur für bestimmte SAP_BASIS-Stände.

Selektive Mandantenkopie: was der Standard kann

Schneller wird eine Kopie auch, wenn sie weniger überträgt. Die Standard-Mandantenkopie bietet dafür drei Wege, jeder mit einer klaren Grenze:

• Reduziertes Profil: Wer keine Anwendungsdaten braucht, etwa für einen Customizing- oder Schulungsmandanten, kopiert mit SAP_CUST oder SAP_UCUS nur einen Bruchteil. Für den QS-Refresh hilft das nicht, denn dort sind die Anwendungsdaten der Zweck. Mehr zu den Kopierprofilen im Grundlagenartikel.
• Tabellen ausschließen: Über die Experteneinstellungen der Mandantenkopie nehmen Sie einzelne Tabellen aus, die im Ziel nicht gebraucht werden. Details beschreibt SAP-Hinweis 446485. Vorsicht bei Anwendungsdaten: Was fehlt, reißt Lücken in Belegketten.
• Nur einzelne Transportaufträge: Mit SCC1 bzw. SCC1N übertragen Sie den Inhalt einzelner Transportaufträge zwischen Mandanten desselben Systems, etwa neues Customizing in einen Testmandanten. Für Anwendungsdaten ist das nicht gedacht.

Was der Standard nicht kann: Anwendungsdaten nach fachlichen Kriterien auswählen. Einen Zeitraum, einen Buchungskreis oder eine Auswahl von Geschäftsobjekten können Sie in keinem Kopierprofil einstellen. Wer Anwendungsdaten braucht, kopiert die komplette Historie des Mandanten. Eine Teilkopie nach Zeitraum braucht ein zusätzliches Werkzeug, das die Abhängigkeiten zwischen Belegen auflöst. Sonst fehlen im Ziel Vorgängerbelege, Stammdaten oder offene Posten, und Tests scheitern an Datenlücken statt an Programmfehlern.

Warum am Ende die Datenmenge entscheidet

Alle Stellschrauben wirken auf zwei Dinge: wie schnell Daten bewegt werden und wie viel Arbeit drumherum anfällt. Parallelisierung verteilt die Arbeit auf mehr Prozesse. Die Datenmenge verringert sie nicht. Jede Zeile muss weiterhin gelesen, übertragen und geschrieben werden, im gefüllten Ziel vorher auch gelöscht.

Die Grenze setzt die Datenbank. Schon der Richtwert von zwei Prozessen je Datenbank-CPU zeigt das: Sind CPU, Speicher und Schreibleistung ausgelastet, bringen weitere Prozesse nichts mehr. Ab diesem Punkt wächst die Laufzeit wieder mit dem Volumen, und das Volumen wächst mit jedem Jahr Historie in der Produktion.

Dazu kommt, was nach der Kopie folgt. Der BDLS-Lauf durchsucht die gesamte kopierte Historie, und im Zielsystem belegt sie Hauptspeicher, fast so viel wie in der Produktion. Eine schnellere Kopie derselben Datenmenge löst also nur einen Teil des Problems.

Weniger kopieren statt schneller kopieren

Den größten Hebel hat, wer die Datenmenge selbst verkleinert. In der Produktion geht das über Archivierung und Housekeeping. Für die Kopie stellt sich die Frage, welche Daten im Ziel wirklich gebraucht werden. Hier setzt der Data Refresh Operator an.

• Zeitscheibe statt Historie: DRO kopiert einen Zeitraum, zum Beispiel die letzten 90 Tage, plus alle abhängigen Objekte aus älteren Jahren, aufgelöst bis zum Fixpunkt. Nachweisbar fehlt nichts, die übrigen Jahre bleiben in der Produktion.
• Export ab dem ersten Fund: Der Export beginnt, sobald DRO ein Objekt gefunden hat. Parallele Worker verarbeiten die Arbeitspakete.
• Pause und Resume: Läufe lassen sich auf Ebene atomarer Arbeitspakete anhalten und später fortsetzen, etwa wenn ein Wartungsfenster endet.
• Ausnahmelisten: Tabellen, die im Ziel niemand braucht, schließen Sie bis auf Tabellenebene aus.
• Kein BDLS danach: Logische Systemnamen ersetzt DRO beim Import, bevor die Daten in die Datenbank geschrieben werden.

3–5×

schneller als eine Vollkopie, in der Praxis

Praxiswert, keine Garantie: in der Praxis drei- bis fünfmal schneller als eine Vollkopie, je nach System, Zeitraum und Ausnahmelisten auch deutlich mehr. DRO läuft ab SAP S/4HANA 2023.

Kleinere Zielsysteme brauchen außerdem weniger Hauptspeicher. Wie viel, zeigt die Seite HANA-Speicher in QS, Test und Sandbox senken. DRO ersetzt die Mandantenkopie, nicht die Systemkopie.

Quellen

• SAP-Hilfe: Verwendung paralleler Prozesse (Mandantenkopie, SAP NetWeaver 7.3)
• SAP-Hilfe: Mandantenkopierer: Ressourcenbedarf, Laufzeit und Systemlast (SAP NetWeaver 7.3)
• SAP-Hilfe: Lokale Kopie: Mandanten innerhalb eines Systems kopieren (Experteneinstellungen)
• SAP Community: New Client Copy Tool (SAP-Blog zu den neuen Kopierwerkzeugen)
• SAP Community: How to Achieve Best Performance for Client Copies for SAP S/4HANA Projects (SAP-Blog)
• SAP-KBA 2163425: Recommendations for client copy performance improvement (SAP-Support-Portal, Anmeldung nötig)