Wissen · SAP Basis
Neue Mandantenkopie-Tools ab S/4HANA 1909: SCCLN, SCC9N und SCC1N
Mit SAP_BASIS 7.54, also SAP S/4HANA 1909, hat SAP die Werkzeuge für die Mandantenkopie neu gebaut. Aus SCCL wurde SCCLN, aus SCC9 wurde SCC9N, später kam SCC1N dazu. Hier lesen Sie, was sich geändert hat, was gleich geblieben ist und was mit den alten Transaktionen passiert.
Alte und neue Transaktionen im Überblick
Die neuen Werkzeuge sind keine überarbeitete Oberfläche, sondern eine Neuentwicklung auf einer gemeinsamen Architektur. SAP hat sie schrittweise ausgeliefert: die meisten Transaktionen mit SAP_BASIS 7.54 (S/4HANA 1909), weitere Funktionen mit SAP_BASIS 7.55 (S/4HANA 2020). Die Tabelle zeigt, welche Transaktion welche ablöst und ab welchem Stand sie verfügbar ist.
| Aufgabe | Bisher | Neu | Ab SAP_BASIS |
|---|---|---|---|
| Lokale Kopie | SCCL | SCCLN | 7.54 SP00 |
| Remote-Kopie | SCC9 | SCC9N | 7.54 SP01 |
| Mandant löschen | SCC5 | SCC5N | 7.54 SP00 |
| Mandantenexport | SCC8 | SCC8N | 7.54 SP02 |
| Nachbearbeitung Import | SCC7 | SCC7N | 7.54 SP02 |
| Kopie gemäß Transportauftrag | SCC1 | SCC1N | 7.55 SP01 |
| Protokolle (neu gestaltet) | SCC3 | SCC3 | 7.54 SP01 |
| Mandantengröße ermitteln | keine | SCC_CLIENT_SIZE | 7.54 SP00 |
| Mandanten vergleichen | keine | SCC_COMPARE | 7.54 SP03 |
Stände laut Übersicht eines SAP-Produktexperten in der SAP Community. Welche Transaktionen in Ihrem System zur Verfügung stehen, hängt vom Support-Package-Stand ab.
Die alten Transaktionen verschwinden nicht über Nacht. Die SAP-Hilfe beschreibt zum Beispiel weiterhin, wie Sie einen mit SCC8 exportierten Mandanten mit SCC7 nachbearbeiten. Ab SAP_BASIS 7.58, also S/4HANA 2023, stuft SAP die alten Kopierwerkzeuge aber als veraltet ein. Neue Abläufe, Runbooks und Automatisierungen sollten Sie deshalb auf die N-Transaktionen aufbauen. Allgemeine Informationen zu den neuen Werkzeugen bündelt SAP-Hinweis 2962811. Was jede Transaktion grundsätzlich leistet, steht in der Übersicht der Mandantenkopie-Transaktionen.
Was bei SCCLN und SCC9N neu ist
- Start aus einem dritten Mandanten: Die Kopie muss nicht mehr im Zielmandanten gestartet werden. SAP empfiehlt einen unbeteiligten Mandanten, zum Beispiel 000. Die Anmeldung als SAP* im leeren Zielmandanten und der Neustart des Systems dafür entfallen.
- Mandantensperre: Der Zielmandant ist während der Kopie immer gesperrt, der Quellmandant standardmäßig. Die Sperre gilt für SAP GUI und HTTP, nur RFC-Zugriffe bleiben möglich. Hintergrundjobs im gesperrten Quellmandanten fängt das Werkzeug ab. Wer schon angemeldet ist, wird aber nicht automatisch abgemeldet.
- Auf SAP HANA optimiert: Bei der lokalen Kopie bleiben die Daten in der Datenbank, statt über den Applikationsserver zu laufen. SAP nennt aus internen Tests eine bis zu zehnmal schnellere lokale und eine bis zu fünfmal schnellere Remote-Kopie.
- Große Tabellen aufteilen: Sehr große Tabellen werden in Pakete zerlegt und parallel kopiert. Das beschleunigt und verhindert, dass Speichergrenzen in HANA und ABAP überschritten werden. Als Richtwert nennt SAP zwei parallele Prozesse je Datenbank-CPU.
- Leere und unveränderte Tabellen überspringen: Ein Optimierer lässt Tabellen aus, die in allen Mandanten leer sind, und solche, die sich seit der letzten Kopie zwischen denselben Mandanten nicht geändert haben.
- Fehler tolerieren: Auf Wunsch läuft die Kopie bei einem fehlerhaften Exit oder einer fehlerhaften Tabelle bis zum Ende weiter. Die Exits laufen isoliert, und was fehlschlägt, steht im Protokoll.
- Testmodus und Aufgabenliste: Ein Testlauf zeigt Umfang und Probleme vorab. Gestartet wird direkt oder als Aufgabenliste im Hintergrund, auch über
STC01. - Neue Berechtigungen: Für Kopierläufe gibt es das Objekt
S_CLNT_CPY, für Exits, die per RFC in einem anderen System laufen,S_CLNT_EXI. Prüfen Sie Ihre Basis-Rollen darauf.
SCC9N starten Sie im Zielsystem, in einem anderen Mandanten als dem Zielmandanten. Das Werkzeug holt die Daten per RFC aus dem Quellsystem und vergleicht vorher die Tabellendefinitionen. Weichen sie ab, etwa wegen unterschiedlicher Release- oder Support-Package-Stände, schließt SCC9N die betroffenen Tabellen aus und kopiert den Rest. Mit der Option für inkompatible Tabellen lassen sie sich trotzdem kopieren. Dann nimmt das Werkzeug Datenverlust in Kauf, zum Beispiel wenn ein Feld im Ziel fehlt. Starten Sie eine Remote-Kopie deshalb zuerst im Testmodus. Welche Einstellungen die Laufzeit tatsächlich verkürzen, beschreibt der Artikel Mandantenkopie beschleunigen.
SCC1N: Kopie gemäß Transportauftrag
SCC1N löst SCC1 ab und ist seit dem Feature Pack 01 von S/4HANA 2020 verfügbar (SAP_BASIS 7.55 SP01). Die Transaktion kopiert Tabelleninhalte, die in Transportaufträgen aufgezeichnet sind, zwischen Mandanten desselben Systems, typischerweise Customizing aus dem Customizing-Mandanten in einen oder mehrere Testmandanten. Gegenüber SCC1 hat sich viel geändert:
- Mehrere Zielmandanten in einem Lauf, gestartet aus einem beliebigen Mandanten
- Mehrere Aufträge auf einmal, ausgewählt nach Auftrag, Typ, Transportziel, Benutzer, CTS-Projekt sowie Export- oder Importdatum
- Auch nicht freigegebene lokale Aufträge lassen sich kopieren, etwa um Customizing vor der Freigabe in einem Testmandanten zu prüfen
- Als Variante im Hintergrund einplanbar: Das gespeicherte Datum der letzten Ausführung verhindert, dass Aufträge vom Vortag erneut kopiert werden
- Jeder Lauf steht im Protokoll in SCC3
Achtung. Einträge im Zielmandanten werden gemäß den Schlüsseln im Transportauftrag überschrieben oder gelöscht. Prüfen Sie vor dem ersten echten Lauf im Testmodus, was SCC1N ändern würde.
SCC8N, SCC7N und Snapshots
Der Mandantentransport läuft mit den neuen Werkzeugen in drei Schritten: Export mit SCC8N, Import der Transportaufträge über STMS, Nachbearbeitung mit SCC7N. Die Nachbearbeitung kann SCC8N auf Wunsch automatisch anstoßen. Der Export selbst läuft asynchron weiter, auch wenn SCC8N schon beendet ist. Starten Sie in dieser Zeit kein anderes Kopierwerkzeug.
Mit SAP_BASIS 7.55 kamen Snapshots dazu. Statt Dateien im Transportverzeichnis zu schreiben, legt SCC8N den Mandanten als Snapshot in der Datenbank des Quellsystems ab. SCC7N holt ihn per RFC ins Zielsystem. Laut SAP ist das in den meisten Fällen schneller als der Weg über Transportaufträge. Snapshots eignen sich auch, um einen Testmandanten nach der Datenvorbereitung einzufrieren und später wiederherzustellen. Weil sie in der Datenbank liegen, sollten Sie alte Snapshots regelmäßig löschen.
Protokoll, Größe, Vergleich: neue Hilfswerkzeuge
Das Kopierprotokoll ist von Dateien auf Datenbanktabellen umgezogen. SCC3 zeigt es mit Registerkarten: laufende Prozesse, Mandantenübersicht, eine Zeitleiste aller Aktionen und je eine Registerkarte für lokale Kopien, Remote-Kopien, Löschungen, Exporte, Importe, Kopien per Transport und Vergleiche. Im Detail sehen Sie Tabellenstatistik, Exit-Meldungen und den Status jedes parallelen Pakets. Wie Sie ein solches Protokoll lesen und Abbrüche einordnen, zeigt der Artikel SCC3 und typische Fehler bei der Mandantenkopie.
Zwei Werkzeuge sind ganz neu. SCC_CLIENT_SIZE schätzt vor einer Kopie, wie groß ein Mandant oder eine Tabelle ist und wie viel Platz das Ziel braucht. Das Ergebnis ist eine Näherung, denn die HANA-Komprimierung fließt nicht ein. SCC_COMPARE vergleicht Mandanten oder Tabellen, lokal oder über RFC, per Prüfsumme oder Satz für Satz. Das hilft zum Beispiel nach einer Remote-Kopie, um Abweichungen im Customizing zu finden.
Was gleich geblieben ist
An den Grundlagen hat sich nichts geändert. Den Umfang einer Kopie steuern weiter Kopierprofile wie SAP_ALL, SAP_CUST oder SAP_USER (mehr dazu im Abschnitt Kopierprofile). Bei allen Profilen außer SAP_USER löscht das Werkzeug Customizing und Anwendungsdaten im Zielmandanten vor dem Kopieren. Das ist laut SAP technisch unvermeidbar. Auch die Nacharbeiten nach einer Kopie aus der Produktion bleiben dieselben.
Vor allem kennen auch die neuen Werkzeuge keinen Zeitraum. Ein Profil wählt Datenarten aus, keine Jahre. Wer Anwendungsdaten kopiert, bekommt die komplette Historie. SAP schreibt selbst, dass eine Mandantenkopie je nach Menge der Anwendungsdaten mehrere Stunden bis Tage dauern kann. Schnellere Technik verkürzt diese Zeit, die Datenmenge bleibt dieselbe.
Neue Werkzeuge, gleiche Datenmenge
SCCLN, SCC9N und SCC1N machen die Mandantenkopie schneller, stabiler und besser nachvollziehbar. An der Datenmenge ändern sie nichts: Jede Kopie mit Anwendungsdaten bringt die komplette Historie ins Zielsystem und damit in den HANA-Hauptspeicher von QS, Test oder Sandbox.
Der Data Refresh Operator kopiert stattdessen 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.
- 3–5×
- schneller als eine Vollkopie, in der Praxis
- –75 %
- HANA-RAM in Non-Prod
Laufzeit: Praxiswert, keine Garantie. Je nach System, Zeitraum und Ausnahmelisten kann der Vorteil auch deutlich größer sein. HANA-RAM: Richtwert aus Referenzszenarien. Die tatsächlichen Effekte hängen von Systemgröße, Historie und Refresh-Zyklen ab.
Wichtig für die Planung: Die neuen SAP-Werkzeuge gibt es ab S/4HANA 1909, DRO läuft ab SAP S/4HANA 2023. Auf S/4HANA 1909 bis 2022 bleiben SCCLN und SCC9N der Weg, mit voller Historie. Ab 2023 können Sie wählen. DRO ersetzt dabei die Mandantenkopie, nicht die Systemkopie.
Quellen
- SAP-Hilfe: New Client Copy Tool (Neuerungen in ABAP Platform 1909, englisch)
- SAP Community: New Client Copy Tool (Dominik Ofenloch, SAP, englisch)
- SAP-Hilfe: Lokale Kopie: Mandanten innerhalb eines Systems kopieren (SCCLN)
- SAP-Hilfe: Tabellendaten eines Transportauftrags kopieren (SCC1N)
- SAP-Hilfe: Kopierprofile (mit Hinweis zu den alten Werkzeugen ab SAP_BASIS 758)
- SAP Learning: Client Copy and Client Transport Tools (englisch)