SAP-Mandantenkopie: Anleitung & Kopierprofile

Was ist eine Mandantenkopie?

Ein SAP-System enthält einen oder mehrere Mandanten – fachlich getrennte Einheiten mit eigenen Anwendungsdaten, eigenem Customizing und eigenen Benutzern. Programme und das Repository teilen sich alle Mandanten eines Systems.

Eine Mandantenkopie (englisch: Client Copy) überträgt die mandantenabhängigen Daten eines Quellmandanten in einen Zielmandanten – im selben System oder in ein anderes. Typische Anlässe sind der regelmäßige Refresh von QS- und Testsystemen mit produktionsnahen Daten, neue Schulungsmandanten oder ein frischer Sandbox-Stand für ein Projekt.

Abzugrenzen ist die Systemkopie: Sie überträgt die gesamte Datenbank mit allen Mandanten und dem Repository. Wann welches Verfahren passt, zeigt unser Vergleich Systemkopie vs. Mandantenkopie.

Systemkopie

Überschreibt die ganze Datenbank

Mandantenkopie

Überschreibt einen Mandanten mit kompletter Historie

Mandantenkopie mit Zeitscheibe

Überschreibt einen Mandanten mit einem Zeitraum, z. B. 90 Tagen, plus abhängigen Objekten

Die Systemkopie ersetzt alles, die Mandantenkopie einen Mandanten mit der ganzen Historie, die Zeitscheibe nur den benötigten Zeitraum. Schematische Darstellung.

SAP-Mandantenkopie durchführen: Schritt für Schritt

Der Ablauf ist bei lokaler und Remote-Kopie weitgehend gleich. Die folgenden Schritte gelten für die neuen Werkzeuge ab S/4HANA 1909 ebenso wie für die klassischen Transaktionen. Wo sie sich unterscheiden, steht es dabei.

Umfang und Platz klären. Wie groß ist der Quellmandant, und reicht der Platz im Ziel? Ab SAP_BASIS 7.54 schätzt SCC_CLIENT_SIZE die Größe. Das Ergebnis ist eine Näherung, weil die HANA-Komprimierung nicht einfließt.
Zielmandanten anlegen. In SCC4 legen Sie den Zielmandanten mit Rolle und Änderungsoptionen an, falls er noch nicht existiert. Welche Felder es gibt, zeigt der Artikel SAP-Mandant anlegen in SCC4.
Bestehendes sichern. Beim Refresh eines vorhandenen Mandanten gehen dessen Daten verloren: Bei allen Profilen außer SAP_USER löscht die Kopie Customizing und Anwendungsdaten im Ziel. Benutzer und systemspezifische Einstellungen des Zielsystems sichern Sie deshalb vorher.
Benutzer informieren und Ruhe schaffen. Der Zielmandant ist während der Kopie gesperrt. Auch im Quellmandanten soll laut SAP nicht gearbeitet werden, weil sonst Inkonsistenzen entstehen können. Eine Systemnachricht über SM02 kündigt das Fenster an.
Werkzeug starten. SCCLN und SCC9N starten Sie aus einem unbeteiligten Mandanten, SAP empfiehlt zum Beispiel 000. Die klassischen Transaktionen SCCL und SCC9 laufen im Zielmandanten. Ein neuer Mandant hat dafür nur den Benutzer SAP*, dessen Anmeldung über den Profilparameter login/no_automatic_user_sapstar gesteuert wird.
Quelle und Kopierprofil wählen. Das Profil bestimmt, welche Datenarten übertragen werden (siehe Kopierprofile). Bei der Remote-Kopie wählen Sie zusätzlich die RFC-Verbindung zum Quellsystem.
Testlauf. Der Testmodus zeigt vorab, welche Tabellen mit wie vielen Daten betroffen sind und wo Probleme drohen. Bei einer Remote-Kopie fallen dabei auch Tabellen auf, deren Definitionen zwischen den Systemen abweichen.
Im Hintergrund starten. SAP empfiehlt, die Kopie als Hintergrundjob einzuplanen, damit sie nicht an Zeitlimits für Dialogprozesse scheitert. Parallele Prozesse verkürzen die Laufzeit. Wie viele sinnvoll sind, steht im Artikel Mandantenkopie beschleunigen.
Überwachen in SCC3. SCC3 zeigt Fortschritt, Tabellenstatistik und Fehler. Wie Sie die Protokolle lesen, erklärt der Artikel SCC3 und typische Fehler bei der Mandantenkopie.
Nacharbeiten. Erst nach den Nacharbeiten ist das Ziel wieder ein Testsystem (Checkliste weiter unten).

Die Transaktionen im Überblick

Transaktion	Zweck	Wofür
`SCC4`	Mandantenverwaltung	Mandanten anlegen, Rolle (z. B. Test, Produktion) und Änderungsoptionen festlegen. Der Zielmandant muss hier existieren, bevor kopiert wird.
`SCCL`	Lokale Mandantenkopie	Kopiert einen Mandanten innerhalb desselben Systems, etwa um einen Schulungs- oder Testmandanten aufzubauen.
`SCC9`	Remote-Mandantenkopie	Kopiert einen Mandanten aus einem anderen System über eine RFC-Verbindung, typisch für den Refresh von QS aus der Produktion.
`SCCLN, SCC9N`	Neue lokale bzw. Remote-Kopie	Ab SAP_BASIS 7.54 (S/4HANA 1909): auf SAP HANA optimiert, Start aus einem unbeteiligten Mandanten, Testmodus und Aufgabenliste.
`SCC8`	Mandantenexport	Exportiert einen Mandanten in Transportdateien, die anschließend im Zielsystem importiert werden.
`SCC7`	Nachbearbeitung Mandantenimport	Schließt einen Mandantenimport ab, nachdem die Exportdateien im Zielsystem eingespielt wurden.
`SCC1`	Kopie gemäß Transportauftrag	Überträgt den Inhalt einzelner Transportaufträge zwischen Mandanten desselben Systems (neu: SCC1N).
`SCC5`	Mandant löschen	Entfernt einen Mandanten samt seiner mandantenabhängigen Daten.
`SCC3`	Protokollanalyse	Zeigt Status und Protokolle der Kopierläufe – die erste Anlaufstelle, wenn ein Lauf hängt oder abbricht.
`SCC_CLIENT_SIZE`	Größe schätzen	Ab SAP_BASIS 7.54: schätzt vor der Kopie, wie groß ein Mandant ist und wie viel Platz das Ziel braucht.

Welche Transaktionen zur Verfügung stehen, hängt vom Release-Stand Ihres Systems ab. Was die neuen Werkzeuge anders machen, beschreibt der Artikel Neue Mandantenkopie-Tools ab S/4HANA 1909.

Lokal, remote oder per Export?

Ausgangslage	Weg	Transaktionen
Quelle und Ziel liegen im selben System	Lokal	SCCL bzw. SCCLN
Ziel in einem anderen System, RFC-Verbindung vorhanden, gleicher Release- und Support-Package-Stand	Remote	SCC9 bzw. SCC9N
Keine direkte Verbindung, oder Export und Import sollen zu verschiedenen Zeiten laufen	Export und Import	SCC8, Import, SCC7

Lokal (SCCL, SCCLN) ist der einfachste Weg, solange Quelle und Ziel im selben System liegen.

Remote (SCC9, SCC9N) kopiert über eine RFC-Verbindung direkt aus einem anderen System. Quelle und Ziel sollten dabei auf demselben Release- und Support-Package-Stand sein, damit die Tabellenstrukturen übereinstimmen.

Export und Import (SCC8, SCC7) entkoppeln Quelle und Ziel: Der Export erzeugt Dateien, die im Zielsystem importiert und mit SCC7 nachbearbeitet werden. Das ist sinnvoll, wenn keine direkte Verbindung besteht oder der Export zu einem anderen Zeitpunkt laufen soll als der Import. Für Produktivmandanten ist der Mandantentransport laut SAP-Leitfaden zur Systemkopie allerdings nicht vorgesehen, sondern für den Erstaufbau einer Systemlandschaft. Mehr dazu im Artikel System-Refresh oder Mandanten-Refresh?

Kopierprofile: was mitkommt

Kopierprofile legen fest, welche Datenarten übertragen werden. Wichtig vorab: Bei allen Profilen außer SAP_USER werden Customizing und Anwendungsdaten im Zielmandanten vor dem Kopieren gelöscht. Das ist laut SAP technisch unvermeidbar. Die allgemeinen Profile im Überblick:

SAP_ALL: Alle Mandantendaten außer Änderungsbelegen und lokalen Daten: Customizing, Anwendungsdaten und Benutzerstämme.
SAP_APPL: Wie SAP_ALL, aber ohne Benutzerstämme.
SAP_APX: Wie SAP_ALL, aber ohne Berechtigungsprofile und Rollen.
SAP_CUST: Mandantenabhängiges Customizing einschließlich Berechtigungsprofilen. Anwendungsdaten im Ziel werden gelöscht, die Benutzerstämme des Ziels bleiben erhalten.
SAP_CUSV: Wie SAP_CUST, zusätzlich mit Varianten.
SAP_UCUS: Wie SAP_CUST, zusätzlich mit Benutzerstämmen.
SAP_UCSV: Wie SAP_UCUS, zusätzlich mit Varianten.
SAP_USER: Benutzer, Rollen und Berechtigungsprofile. Als einziges Profil setzt es den Zielmandanten nicht zurück.
SAP_UONL: Benutzer ohne Berechtigungsprofile und Rollen.
SAP_PROF: Nur Berechtigungsprofile und Rollen.

Für Export und Remote-Kopie gibt es zusätzlich Profile, die mandantenübergreifendes Customizing mitnehmen (SAP_EXPA, SAP_EXPC, SAP_EXBC bzw. SAP_RMPA, SAP_RMPC, SAP_RMBC). Das Sonderprofil SAP_RECO ist nur dafür gedacht, einen versehentlich gelöschten Mandanten wiederherzustellen.

Welches Profil wofür? Für einen neuen Customizing- oder Schulungsmandanten reicht oft SAP_CUST oder SAP_UCUS. Für einen QS-Refresh mit Anwendungsdaten kommen SAP_ALL oder SAP_APPL in Frage. Wichtig ist, was Profile nicht können: Sie wählen Datenarten aus, aber keinen Zeitraum. Wer Anwendungsdaten kopiert, bekommt immer die komplette Historie – auch wenn für Tests nur die letzten Monate gebraucht werden.

Dauer und Platzbedarf einer Mandantenkopie

Die Laufzeit wächst mit dem Datenvolumen des Mandanten – und damit mit jedem Jahr Historie. Bei großen S/4HANA-Systemen binden Komplettkopien Systeme, Basis-Team und Fachbereiche oft tagelang. Parallele Prozesse verkürzen die Laufzeit, ändern aber nichts daran, dass die gesamte Historie bewegt wird. Für die Planung gilt: Die gesamte Laufzeit ist Ausfallzeit für den Zielmandanten, und im Quellmandanten sollte währenddessen nicht gearbeitet werden.

Hinzu kommt der Speicher: In SAP HANA liegt die kopierte Historie im Hauptspeicher. Jede Vollkopie in QS, Test oder Sandbox braucht dadurch fast so viel RAM wie die Produktion. Mehr zum HANA-Speicher in Non-Prod

Nacharbeiten nach der Kopie: Checkliste

Nach jeder Kopie aus der Produktion muss das Zielsystem wieder zum Testsystem werden. Ohne diese Schritte drohen echte Nachrichten an Kunden, Buchungen in Partnersystemen oder ungeschützte Personendaten.

Protokoll in SCC3 prüfen: Fehler, Warnungen und übersprungene Tabellen
Logische Systemnamen anpassen (BDLS), damit Belege nicht auf die Produktion verweisen
RFC-Verbindungen und Schnittstellen umstellen oder deaktivieren
Hintergrundjobs prüfen und produktive Jobs stoppen
Ausgabe sperren: Druck, E-Mail und EDI dürfen keine Kunden erreichen
Benutzer und Berechtigungen des Zielsystems wiederherstellen
Nummernkreise prüfen
Personenbezogene Daten maskieren, bevor Tester und Entwickler zugreifen
Benutzer informieren und das System freigeben

Viele Teams arbeiten diese Liste jedes Mal von Hand ab, oft am Wochenende. Wie der gesamte Ablauf automatisch laufen kann, zeigt unser Beispiel-Playbook. Warum allein der BDLS-Lauf bei großen Systemen Stunden dauert, lesen Sie im Artikel BDLS nach System- und Mandantenkopie.

Grenzen der Standard-Mandantenkopie

Die Standardwerkzeuge sind zuverlässig, aber für den regelmäßigen Refresh großer S/4HANA-Landschaften zu grob: Sie kopieren alles oder nichts, brauchen fast Produktions-Sizing im Ziel und überlassen Maskierung und Nacharbeiten separaten Werkzeugen und Checklisten.

Der Data Refresh Operator setzt genau hier an: Er kopiert eine Zeitscheibe – zum Beispiel die letzten 90 Tage – und ergänzt automatisch alle abhängigen Belege, bis nachweisbar nichts mehr fehlt. Logische Systemnamen ersetzt DRO schon beim Import, ein BDLS-Lauf entfällt. Maskierung und Playbooks für den Ablauf drumherum sind integriert.

Häufige Fragen zur SAP-Mandantenkopie

Wie lange dauert eine SAP-Mandantenkopie?

Das hängt vor allem vom Datenvolumen des Quellmandanten ab: Ein reiner Customizing-Mandant ist deutlich schneller kopiert als ein großer Produktivmandant mit Anwendungsdaten, der Systeme oft über Stunden bis Tage bindet. Einen Anhaltspunkt liefern der Testlauf und ab SAP_BASIS 7.54 die Transaktion SCC_CLIENT_SIZE. Welche Stellschrauben die Laufzeit verkürzen, beschreibt der Artikel Mandantenkopie beschleunigen.

Was ist der Unterschied zwischen Mandantenkopie und Systemkopie?

Die Mandantenkopie überträgt die mandantenabhängigen Daten eines einzelnen Mandanten. Die Systemkopie überträgt die gesamte Datenbank mit allen Mandanten, dem Repository und den mandantenübergreifenden Einstellungen. Details im Artikel SAP-Systemkopie.

Welches Kopierprofil nehme ich für einen QS-Refresh aus der Produktion?

Meist SAP_ALL oder SAP_APPL. Mit SAP_APPL bleiben die Benutzerstämme aus der Produktion außen vor. Die Benutzer des Zielsystems sichern viele Teams vorher separat, etwa per Export mit SAP_USER, und spielen sie nach der Kopie zurück.

Werden mandantenübergreifende Daten mitkopiert?

Mit den allgemeinen Profilen nicht: Repository und mandantenübergreifendes Customizing gehören zum System, nicht zum Mandanten. Für Export und Remote-Kopie gibt es eigene Profile mit mandantenübergreifendem Customizing (SAP_EX… bzw. SAP_RM…).

Kann man mit der Mandantenkopie nur einen Zeitraum kopieren?

Nein. Kopierprofile wählen Datenarten aus, keine Jahre. Wer Anwendungsdaten kopiert, bekommt die komplette Historie. Für Teilkopien nach Zeitraum braucht es zusätzliche Werkzeuge, zum Beispiel eine zeitscheiben-basierte Kopie wie den Data Refresh Operator.

SAP-Mandantenkopie: Anleitung, Transaktionen und Kopierprofile