Eine immer wiederkehrende Anforderung im SAP-IT-Geschäft: homogene Systemkopien. Gerade die Spiegelung eines Produkitvsystems auf Test- oder Releasewechselsysteme wird sehr häufig benötigt, birgt aber auch Fallstricke und Gefahren. Dieser Blog soll einen Überblick verschaffen, worum es dabei geht.
Vorbereitung: Tools und Doku
Bevor Sie sich ans Werk machen, sollten Sie mindestens über Folgendes zu verfügen:
– grundlegende Kenntnisse in Administration und SAP Architektur
– mind. 3 Tage Zeit für diesen Job (beim 12. Durchlauf reicht auch 1 Tag)
– root-Zugriff auf die Zielrechner
– funktionierendes Backup oder ora<sid>-Zugriff auf die Quellrechner
Das A und O für alle Aktivitäten im SAP Umfeld: bitte die Dokumentation beachten (in der Fachwelt freundlich umschrieben mit dem wohlklingenden Akronym ‚RTFM’).
SAP bietet umfangreiche Informationsquellen, hauptsächlich bestehend aus der Online-SAP-Hilfe http://help.sap.com, dem SAP Hinweissystem http://service.sap.com/notes und den Dokumentationen auf http://service.sap.com/instguides. Für Fehlersuchen ist auch sdn.sap.com unglaublich hilfreich.
Mit den offiziellen Dokumentationen beginnend, finden wir für unser Vorhaben (hom syscopy, abap only, unix/oracle) die passende Doku hier: http://service.sap.com/instguides -> SAP Netweaver -> SAP Netweaver 7.0 (2004s) -> Installation -> „System Copy for SAP Systems Based on NW 7.0 SR2 ABAP“.
Anmerkung: Um allzu großer Trägheit vorzubeugen, änder SAP mit schöner Regelmäßigkeit die Dokumenationsstruktur, oft aufgrund von Umbauten im Produktportfolio. Lassen Sie sich also nicht entmutigen wenn der hier oder in Hinweisen beschriebene Weg zur richtigen Doku nicht mehr existiert, und suchen Sie im Zweifel immer erstmal nach Netweaver als Anwendungsplattform (bspw. 7.0 und 2004s im Fall von ERP6).
Im Guide selbst sind auch die zugehörigen Hinweise beschrieben. Ich empfehle dringend, diese zu überfliegen und die relevanten Passagen gesondert zu notieren, bspw.
970518 Hom./Het.System Copy SAP NetWeaver 7.0 (2004s) SR2
Für Systemkopien nur selten so ausschlaggebend, kann es bspw. bei Releasewechseln oder Support Package Implementierungen durchaus passieren, das die Hinweise innerhalb kurzer Zeit durch neue kritische Informationen ergänzt werden. Im schlimmsten Fall entscheiden solche Informationen über Erfolg oder Misserfolg des gesamten Vorhabens, und Kosten Sie möglicherweise einen kompletten Neuanfang.
Parallel zum Lesen der Dokumentation und der Hinweise kann man schon mal den Download der benötigten Tools und Installations-DVDs anstarten. Das wären für unser Vorhaben folgende:
Tools (falls nicht schon vorhanden):
– putty
– ein funktionierender X-Server
– WinSCP
SAP Installations-DVDs:
– Instmaster DVD
– Kernel DVD (passend zu eurer DB und OS Version)
– JAVA Components
– Oracle RDBMS DVD
– Oracle RDBMS Patchset (+ SBP)
– Oracle RDBMS Client
– + aktuellster Kernel-Stack aus http://service.sap.com/swdc -> Support Packages und Patches
Der Ablauf im Groben
- Quelldatenbank sichern
Natürlich muss das Quell-System in der einen oder anderen Form gesichert werden. Das kann über Backuplösungen (bspw. Networker), oder direkt per Filecopy vom Quellsystem erfolgen.
- Zieldaten prüfen und ggf. sichern
Möchten Sie Benutzerstämme, RFC-Destinationen oder ähnliches aus dem Zielsystem retten, um es später weiterzuverwenden, sollten Sie das in Ihren Aktivitätenplan aufnehmen
- CDs ablegen und Tools vorbereiten
Legen Sie die heruntergeladenen Installations-CDs auf den Zielrechner – Wartungsaktivitäten mit DVDs die woanders liegen (NFS / SAMBA) sind extra-pfui. Entpacken Sie diese lokal (sehr beliebt ist sapdata mit Link von /instcd) und berechtigen Sie sie entsprechend, damit der <sid>adm und der ora<sid> zugreifen darf.
- Starten des SAPINST und Vorbereiten der Installation
Etablieren Sie die X-Verbindung zu einem X-Server (Stichwort DISPLAY, xauth usw.) und starten Sie den SAPINST. Es folgt eine lange Litanei an Abfragen und Eingaben, die Sie entsprechend beantworten – beim ersten Mal interessant ist der sog. Solution Manager Key, den Sie nach Anlegen des Zielsystems in Ihrem SolMan SMSY erhalten.
Schwer zu korrigieren sind v.a. die Angaben Unicode/Non-Unicode (herauszufinden im Kernel des Quellsystems) und der Schema-Name / die Codepage der Quelldatenbank (beides im Environment des Quell-ora<sid> zu finden).
- RDBMS und Restore
Im Laufe der Installation folgt die Aufforderung, das RDBMS zu installieren. Nachdem das erledigt ist und die Patches alle implementiert wurden, wird mit SAPINST fortgefahren bis zur Restore-Aufforderung.
Nun spielen Sie mit dem Mittel Ihrer Wahl (brrestore, recover oder scp) die Datenbankfiles vom Quell-Rechner auf den Zielrechner (hier v.a. sapdata*, die Controlfiles und die DB-Profile der Quelldatenbank, ggf. noch die Redolog-Archive bei Online-Kopien).
Da man mit dem Restore einen eigenen Blog füllen könnte, nur kurz der Hinweis:
Nach der Kopie ist die Aufgabe, die Berechtigungen neu zu setzen / das Profil anzupassen, und 1 Mal unter altem Namen die DB hochzufahren (bei Recover mit open resetlogs). Anschließend wird die DB wieder heruntergefahren, es werden neue Controlfiles mit dem Zielnamen erzeugt, und anschließend unter neuem Namen hochgefahren. Dann noch PSAPTEMP prüfen und die OPS$-Einträge korrigieren, und schon geht’s weiter. Wenn das Release während der Kopie auf 11g umgesetzt wurde, sind hier natürlich weitere Arbeiten nötig.
Keine Sorge, es klingt schlimmer als es ist.
- Die Datenbank entschärfen
Achtung : an dieser Stelle ganz wichtig! Alle Anwendungs-Jobs ausplanen (TBTCO/TBTCS) und nach Abstimmung mit dem Auftraggeber alle RFC Destinationen invalidieren (RFCDES). Produktivkopien können sonst bösen Schaden anrichten, wenn Sie als zweites Produktivsystem mit aktiven Jobs oder Schnittstellen hochgefahren werden!!
SAPINST startet im Laufe der Zeit das SAP System, es bleibt also nach diesem Schritt keine Zeit mehr, diese Tätigkeiten nachzuholen.
- SAPINST fortfahren
SAPINST erwartet eigentlich, die DB selbst hochzufahren. Das ist bei Umbenennung und Recover aber ein bisschen umständlich, daher gehen wir davon aus die DB ist bereits unter neuem Namen online (wie in Schritt 6 beschrieben). Um SAPINST trotzdem etwas zu tun zu geben fahren wir die DB herunter und legen in das Protokoll-Verzeichnis ein File namens CONTROL.SQL mit dem Inhalt ‚startup’.
Anmerkung: diesen Schritt 7. konnte man früher (R3Setup, SAPINST bis ca. 2009) mal weglassen, weil der Kernel bereits installiert und alle notwendigen Umgebungsvariablen gesetzt waren. Das ist meiner Erfahrung nach nicht mehr so, heute muss bei leerem Zielsystem der SAPINST mindestens ein Mal vollständig beendet worden sein.
Sonst stehen Sie möglicherweise mit wiederhergestellter Datenbank, aber ohne Kernel / Umgebungsvariablen da. Die Nacharbeiten um das System dann zum Fliegen zu bewegen sind einigermaßen aufwändig, also bitte SAPINST beenden und das sapinst-instdir erst anschließend entfernen.
Die Nachbereitung
Die Datenbank ist wiederhergestellt, das System ist kopiert und online, SAPINST ist abgeschlossen. Nun können Sie nach Doku und Hinweisen alle anfallenden Nacharbeiten umsetzen. Unter anderem können das folgende sein (viele davon nur „bei Bedarf“):
– DB-Logging abschalten
– SAP-Systemprofile und DB-Profil (#1171650) prüfen und aktualisieren
– Lizenzen aufsetzen
– Datenbankjobs und SAP-Wartungsjobs wieder einplanen
– Transportwesen rücksetzen
– User und RFC Destinationen re-importieren, RFC Passworte umsetzen / neu setzen
– SM21 Syslog / ST22 Dumps / SM28 SICK prüfen
– BDLS, SM54, SM55, RZ04, RZ12, SM63
– SLD Anbindung RZ70
– SPAD Aufbereitungsserver
– SGEN
– Initial-Backup
– ..
Diese Liste ist nicht abschließend, bietet aber ein Stück weit Orientierung um welche Themen es geht. So gut wie alle Unternehmen haben auch Standardlisten mit Nacharbeiten, die branchenspezifische Tätigkeiten enthalten, oder Besonderheiten in der Infrastruktur berücksichtigen. Sollten Ihre Kollegen Ihnen versichern, so etwas gäbe es nicht, sollten Sie mal über einen Betriebs-Kuchen nachdenken..
Abschließend lässt sich sagen : so sehr „Commodity“ so eine Systemkopie auch sein mag, bleiben Sie wachsam, und stolpern Sie nicht über vergessene ‚Selbstverständlichkeiten’. Tun Sie sich und der Nachwelt einen Gefallen, dokumentieren Sie Ihre Arbeit und legen Sie die Dokumente zentral ab.
In diesem Sinne, alles Gute mit Ihrem neuen System (wieder eines, was Sie ab sofort betreuen dürfen ;).
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.
