Eine Systemkopie ist eine häufige Anforderung der Fachabteilung oder des Projekts. Ständig müssen Testsysteme aufgebaut und Produktivdaten gespiegelt werden. Viel Arbeit lässt sich sparen, wenn man bestimmte Daten aus dem Zielsystem vorher sichert. Hier steht, wie man das macht.
Benutzer retten
Die Menge an Benutzern eines Systems kann teilweise unanständige Ausmaße annehmen, in großen Konzernen sind 5-6 stellige Benutzeranzahlen (meist in den zentralen ERP Systemen) durchaus keine Seltenheit.
Die Aufgabe, diese User und ihre Rollen nach Spiegelung der Produktivdaten in die Testumgebung neu anzulegen und zu berechtigen, kann nur jemandem gefallen der sich unsterblich in die SU01 verliebt hat. Um auch den – durchaus praktischen – Umweg über CATT nicht überzustrapazieren, da ja eigentlich nur der alte Stand weiderhergestellt werden soll, kann man sich der Mandantenkopie-Tools bedienen.
Hierbei machen wir uns einen interessanten Umstand zunutze: Das Mandantenkopieprofil SAP_USER enthält den „Initialisieren“-Parameter nicht. Das bedeutet, ein mit SAP_USER exportierter Mandant überschreibt im Ziel keine Daten, außer die Benutzer- und Rolleninformationen (im Gegensatz zu anderen selektiven Profilen wie bspw. SAP_CUST).
Daher können wir vor der Systemkopie im Zielsystem einen SAP_USER Mandantenexport ins Filesystem legen, den wir nach der Kopie über die stms_import wieder in das System importieren. Der genaue Ablauf ist folgendermaßen:
- Prüfen des Filesystemplatzes im TRANS_DIR (siehe SE38 / RSPARAM)
Je nach Benutzeranzahl wenige MB bis zu einige hundert MB nötig.
- Prüfen der SCC4 im Quellmandanten
Der Mandant darf in der T000 nicht gegen Mandantenexport gesperrt sein, sonst lässt sich die SCC8 nicht aufrufen. Zu restriktiv wäre bspw. folgende Einstellung:
- Anfertigen des Mandantenexports
SCC8 – Mandantenkopierprofil SAP_USER – im Hintergrund einplanen. Der Job sollte für normale Mandanten nicht sehr lange laufen (<1h). Das Ziel des Transports ist im Idealfall ein virtuelles System, so können Sie die Mandantentransporte später manuell an die Importqueue anhängen.
Tipp : Für versierte Admins mit riesigen Mandanten ist der Report RSCCEXPT (erreichbar in der SCC8 über Bearbeiten / Experteneinstellungen) gedacht. Hier lassen sich bspw. parallele Prozesse konfigurieren und Ausschlusstabellen pflegen. Für den Haus-und-Hof-Gebrauch sollten die Standardeinstellungen in 90% der Fälle jedoch ausreichen.
So oder so gilt : klicken Sie nichts an, von dem Sie nicht genau wissen dass Sie es brauchen!
- Systemkopie umsetzen
Nachdem der Export-Job erfolgreich durchgelaufen ist (monitorbar unter SCC3 / Exporte) sollten Sie sich zunächst (falls nicht schon geschehen) den Transportnamen aufschreiben – SCC3 -> Exporte -> Quellmandant -> Kopierlauf -> unten rechts beginnend mit <SID>KT.
Der nächste Schritt des Blogs nimmt an, dass die geplante Systemkopie erfolgreich abgeschlossen wurde.
- Benutzer importieren und Nachbereitung
Hängen Sie nach Systemkopie den zuvor exportierten Transport (Name aus SCC3) in der stms_import über Zusätze -> Weitere Aufträge -> Anhängen an Ihre Importqueue und starten Sie den Import.
- Importnachbereitung
Starten Sie nach Abschluss des Imports im Zielmandanten die Transaktion SCC7, um die Nachbereitung anzustarten. Auch hier können Sie den Status über die SCC3 verfolgen. Sobald diese abgeschlossen ist, haben sie die Benutzerrettung erfolgreich hinter sich gebracht.
Herzlichen Glückwunsch! J
RFC Destinationen retten
Das Retten der RFC Destinationen erspart Ihnen das langwierige Anlegen der Verbindungsdaten und Beschreibungen. Was es Ihnen nicht ersparen kann (seit der Einführung von SECSTORE), ist das Nachtragen der Passworte in die einzelnen Verbindungseinträge, bzw. die Migration des sicheren Speichers im Anschluss.
Das hier beschriebene Vorgehen ist mit einem gewissen Risiko verbunden, da SAP Standardverfahren verlassen und direkt Änderungen in Datenbanktabellen vorgenommen werden. Nur erfahrene Adminstratoren sollten diese Tätigkeiten durchführen, sich vorher durch Backups absichern und außerdem vorher in unkritischen Umgebungen testen. Das hier beschriebene Vorgehen funktionierte bis einschließlich Release 7.01. 7.1 und 7.3 konnte ich bisher noch nicht testen, wohlgemerkt gibt es keine Funktionsgarantie, da SAP jederzeit über Hinweise oder Support Packages Funktion und Persistenz der RFCDES anpassen kann (siehe auch „Das Obligatorische“).
Die Daten für die RFC Verbindungen verstecken sich hauptsächlich in der Tabelle RFCDES, streuen aber mit Eigenschaften und Verknüpfungen auch in andere RFC-Tabellen. Das Export-Kommando sieht demnach folgendermaßen aus:
ora<sid>: exp <schemaname>/<schemapass> TABLES=RFCDES, RFCATTRIB, RFCCMC, RFCDOC, RFCSYSACL, RFCTRUST file=TABLES_RFC.dump log=TABLES_RFC.log compress=no
Wenn die Tabelle SAPR3.RFCDOC nicht existiert, so muss Sie dies nicht beunruhigen, der Export funktioniert trotzdem.
Nach Ende der Systemkopie folgt die Leerung der RFC Tabellen, und anschließend der Import der RFC Destinationen:
truncate table SAPR3.RFCDES;
truncate table SAPR3.RFCATTRIB;
truncate table SAPR3.RFCCMC;
truncate table SAPR3.RFCSYSACL;
truncate table SAPR3.RFCTRUST;
truncate table SAPR3.RFCDOC;
ora<sid> : imp <schemaname>/<schemapass> TABLES=RFCDES, RFCATTRIB, RFCCMC, RFCDOC, RFCSYSACL, RFCTRUST file=TABLES_RFC.dump ignore=yes
Anschließend können Sie mithilfe der Secure Storage Migration (SMP -> Schlüssel und Bestellungen -> Migrationsschlüssel -> Secure Storage Migration) einen Migrationsschlüssel beantragen und einspielen, oder Sie setzen in der SM59 die Passworte einfach neu.
Das Obligatorische
Diese Dokumentation ist eine Sammlung von Erfahrungswerten, und in keiner Form von den Produktherstellern (SAP, Oracle, ..) geprüft oder freigegeben worden. Es kann keine Haftung für Schäden übernommen werden, die aus dem (teilweisen oder vollständigen) Befolgen dieser Dokumentation entstehen.
Selbstverständlich freue ich mich über Fragen, Anmerkungen oder Ergänzungen.
