Technische Umstellungen ohne Überraschungen

Feature | 9. Februar 2004 von admin 0

Zu viele Faktoren spielen eine Rolle, um generelle Aussagen über die Laufzeit des Releasewechsels auf SAP R/3 Enterprise zu treffen. Für die Zeitplanung ist die Größe der Datenbank nicht entscheidend. Ausschlaggebende Faktoren sind vielmehr die Anzahl der Mandanten, die installierten Sprachen, die Eigenentwicklungen, die in den Upgrade eingebundenen Support Packages und nicht zuletzt die Performance der eingesetzten Hardware. Ein Fallbeispiel: Bei einer Installation mit einer relativ kleinen Datenbank mit 22 GB, jedoch mit sieben Mandanten und acht installierten Sprachen, betrug die reine Ausfallzeit unter Einbindung aller verfügbaren Support Packages und installierten Add-Ons 19 Stunden. Nebenstehende Grafik zeigt auf Basis einer Menge von durchgeführten Releasewechsel-Projekten, wie unabhängig die tatsächlichen Ausfallzeiten im Verhältnis zu den Datenbankgrößen sind.

Ausfallzeit oder Hardware-Ressourcen minimieren

Laufzeitmatrix

Laufzeitmatrix

Die Auffassung, dass während eines Upgrades das System produktiv nicht zur Verfügung stehe, ist nur bedingt richtig. Denn ab SAP R/3 Enterprise besteht die Möglichkeit, im Upgrade-Verfahren ‚System Switch Upgrade’ und der Upgrade-Strategie ‚Downtime Minimized’ auf die so genannte Schatteninstanz zuzugreifen. Dort ist die komplette SAP-R/3-Umgebung des Zielsystems schon vor der Ausfallzeit verfügbar, um beispielsweise Repository-Objekte anzulegen oder kundenspezifische Anpassungen durchzuführen. Dieses Verfahren verkürzt die Ausfallzeit des Systems deutlich, benötigt allerdings nicht unwesentlichen Speicherplatz in der Datenbank.

Vorbereitungen

Ohne einen detaillierten Projektplan, in dem auch Notfallszenarien wie zum Beispiel das Rücksetzen des Upgrades auf das Ursprungsrelease eingeplant sind, ist ein Upgrade nicht möglich. Liegt der Projektplan vor, kann der Releasewechsel technisch vollzogen werden. Dabei ist unerlässlich, zunächst die aktuellen Hinweise, die den Releasewechsel betreffen, aus dem SAP Service Marketplace zu beachten. Zu jeder Plattform sind dort entsprechende Informationen verfügbar. Vor dem Projektstart ist das bestehende System in bestimmten Bereichen auf den neuesten Stand zu bringen. So muss im Quellsystem der aktuelle SPAM/SAINT-Update eingespielt werden. Je nach Ausgangsrelease sind bestimmte Support Package / LCP Stände herzustellen. Die Version der Plugins (PI, PI-A, ST-PI und so weiter) ist zu prüfen. Der Upgrade eines Systems mit Plugin ist nur möglich, wenn die Version des Plugin vom Quellrelease mit der des Zielrelease übereinstimmt. Zum Beispiel muss SAP R/3 Release 4.5B zunächst auf eine Plugin-Version hochgezogen werden, für die es in SAP R/3 Enterprise ein Äquivalent gibt, zum Beispiel entspricht 2003_1_45B der Version 2003_1_470.
Ein großer Teil der Vorbereitungen – und dies ist im Zeitplan unbedingt zu berücksichtigen – fällt an, um das Quellsystem für den Releasewechsel zu bereinigen. Beispielsweise sollten überflüssige Mandanten gelöscht und alte Datenbestände archiviert werden. Sämtliche Transporte sind frei zu geben. Ebenso ist unverzichtbar, alle eingebauten Hinweise zu bestätigen. Wie die Erfahrung lehrt, fällt hier die meiste Arbeit an. Eine Bereinigung ist notwendig, weil in der Praxis gerade auf Test- und Entwicklungssystemen Hinweise oft beiläufig und ohne weitere Bearbeitung eingebaut oder Transporte zwar erzeugt, aber nie explizit freigegeben werden.
Um einen Upgrade erfolgreich durchzuführen, muss genügend freier Platz im Dateisystem und in der Datenbank vorhanden sein. Je nach Datenbank sollten dies zwischen 25 und 30 GB sein. Es ist zu beachten, einen Festplattenbereich für die Kopien der kompletten CDs zu reservieren. Ebenso benötigt der so genannte Prepare etwa 300 MB in der Datenbank. Es handelt sich dabei um ein Programm, welches beim erstmaligen Start von der jeweiligen SAP-Kernel-CD auf dem System installiert wird. Ferner sind die Support Packages und Add-Ons nicht zu vergessen, die in den Upgrade eingebunden werden sollen.
Die in der Vorbereitungsphase durchgeführten Änderungen am System sind unbedingt genau zu dokumentieren. Das ist nötig, da diese vor dem Releasewechsel in gleicher Weise auch auf den nachgelagerten Systemen, dem Qualitätssicherungs- und Produktivsystem, vorzunehmen sind. In der Vorbereitung sollte man ferner genau prüfen, ob die verwendete Hardware optimiert werden kann. Hauptaugenmerk liegt hier auf CPU, wie dem Speicher und dem Sicherungsmedium. Gerade die Art des Sicherungsmediums wird oft vernachlässigt, obwohl beim Upgradelauf immerhin die Datenbank zwei Mal, vor der Isolierung und vor Produktivsetzung der Instanz, komplett zu sichern ist. Häufig wird auch das Frontend außer acht gelassen. SAP R/3 Enterprise erfordert einen SAP GUI der Version 6.20 oder höher, welcher aber wiederum bis SAP R/3 3.1 abwärtskompatibel ist. Deshalb muss ein Rollout des neuesten SAP GUI einer der ersten Schritte weit vor dem Upgrade auf SAP R/3 Enterprise sein.

Prepare

Ein Schwerpunkt der Vorbereitungen gilt dem Prepare. Dieses Upgrade-Werkzeug durchläuft verschiedene Module, welche wiederum verschiedene Phasen enthalten. Die Phasen werden ausführlich in der Upgrade-Dokumentation beschrieben. Die meisten laufen ohne Anwenderinteraktion ab. Im Modul Parameterinput wird unter anderem bestimmt, wie viele parallele Prozesse, also Batch- und Aktivierprozesse, für den Prepare verwendet werden sollen. Nachdem der Prepare in der Regel während der Produktivzeit erfolgt, sind hier bei leistungsstarken Systemen bis zu drei parallele Importprozesse sinnvoll; bei heutigen Multiprozessor-Systemen sind es maximal vier.
In der Phase UPLOAD_REQUEST können zuvor im zentralen Transportverzeichnis bereitgestellte Add-Ons und Support Packages geladen werden. Sie sind dann in der Phase BIND_PATCH als Vorauswahl zur Installation verfügbar. Grundsätzlich empfiehlt es sich, alle verfügbaren Support Packages in den Upgrade mit einzubinden. Werden keine Support Packages mit eingebunden, so erfolgt in der Phase BIND_PATCH die Anzeige des minimal einzubindenden Standes der Support Packages. In dieser Phase wird auch über den aktuellen SPAM / SAINT Update informiert, wenn er vorher im Transportverzeichnis bereitgestellt wurde. Nach Abschluss von Prepare ist unbedingt die Datei checks.log im Upgradeverzeichnis zu sichten. In dieser Datei stehen wichtige Meldungen, die für den weiteren Ablauf des Releasewechsel wichtig sind. Um nicht in Zeitdruck mit den durchzuführenden Maßnahmen zu geraten, sollte der Prepare möglichst zwei bis drei Wochen vor dem Upgrade eingeplant werden.

Durchführung Upgrade

Wenn die Vorbereitungen einschließlich Prepare abgeschlossen sind, kann der Upgrade gestartet werden. Wie oben erwähnt, muss mit dem Start des Upgrades nicht gleichzeitig der Produktivbetrieb ruhen. Wird die Upgrade-Variante ‚Downtime Minimized’ gewählt, so ist es möglich, den Produktivbetrieb bis zur Upgrade-Phase MODPROF_TRANS weiter zu fahren. Bei Variante ‚Downtime Minimized’ verringert sich die Zeit, in der das System nicht verfügbar ist, verlängert aber wesentlich die gesamte Laufzeit des Upgrade. Bei der Variante ‚Downtime Minimized’ ist auch entscheidend, dass der Archivierungs-Modus (Log-Modus) der Datenbank erst zu dem Zeitpunkt abzuschalten ist, wenn die Instanz isoliert wird (gilt nicht für OS400). Dies geschieht vor der Phase MODPROF_TRANS. Das Upgradeprogramm verlangt zu Beginn des Upgrades eine Auswahl, wann die Archivierung der Datenbank beendet sein soll. Bei der Variante ‚Resource Minimized’ kann schon vor der EU_IMPORT1 Phase die Archivierung ausgeschaltet werden.

Ablauf des Upgrade

Ablauf des Upgrade

Wenn keine Fehler auftreten, verläuft der Upgrade nach der Phase INITPUT weitestgehend ohne Benutzeraktion. Es wird aber immer wieder nach längeren Laufzeiten eine Benutzeraktion erwartet, so zum Beispiel beim Modifikationsabgleich, oder wenn die Sicherung durchgeführt werden muss. Wer sich nicht ständig vergewissern will, ob der Upgrade noch läuft, dem bietet das Upgrade-Tool die Funktion, eine Nachricht nach längerem Stillstand zu versenden. Um den Ablauf zu überwachen und zu analysieren, wird im Verzeichnis usrsapputlog jede Aktion in die Datei ‚r3up.log’ mitgeschrieben. Sollte während einer Phase ein Fehler auftreten, so meldet dies das Upgrade-Programm. Die ausführliche Fehlermeldung wird in eine Datei des Logverzeichnisses mit der Syntax <Phasenname>.elg geschrieben.

Nacharbeiten

Ist das Upgradeprogramm erfolgreich beendet, geht es an die Nacharbeiten. Die einzelnen Schritte sind in der Upgrade-Dokumentation erläutert, soweit sie sich auf SAP R/3 Enterprise beziehen. Zusätzlich sind alle Schnittstellen zu externen Programmen zu testen. Sind diese Nacharbeiten durchgeführt, sollten sämtliche betriebswirtschaftlichen Abläufe im System von den Keyusern getestet werden. Erst wenn dies zufriedenstellend erfolgt ist, kann der Releasewechsel auf SAP R/3 Enterprise abgeschlossen und dann der Releasewechsel an den nachfolgenden Systemen durchgeführt werden.

Markus Eberhard

Markus Eberhard

Tags: ,

Leave a Reply