Schneller produktiv

Feature | 23. Juni 2003 von admin 0

SAP R/3 Enterprise kam in einer für SAP-R/3-Systeme neuen Strategie auf den Markt, dem Ramp Up. Die Ramp-Up-Strategie löst das frühere Verfahren des First Customer Shipment (FCS) ab. Anders als ein FCS-Release ist ein Ramp-Up-Release für den produktiven Einsatz freigegeben. Entsprechend groß war die Resonanz auf SAP R/3 Enterprise. Während des Ramp-Up-Programms, das von Juli 2002 bis Januar 2003 dauerte, wurden die teilnehmenden Kunden intensiv von SAP betreut. Deren Rückmeldungen flossen in die weitere Entwicklung der Software ein. Inzwischen sind auch Kunden produktiv, die erst nach der Ramp-Up-Phase die Software erhalten und ihr Projekt eigenständig durchgeführt haben.

Zwei Optionen für den Release-Wechsel

Für den Wechsel auf SAP R/3 Enterprise ist eine durchschnittliche Projektlaufzeit von vier Monaten einzukalkulieren. Ein Knackpunkt bei einem Upgrade-Projekt ist die Ausfallzeit, also die Zeit, in der weder das alte noch das neue Release zur Verfügung steht. Beim Wechsel auf das Release SAP R/3 3.x betrug sie im Durchschnitt noch 15 Stunden. Die technische Ausfallzeit beim Release-Wechsel auf SAP R/3 4.x lag bei etwa zehn Stunden.
Für den Wechsel auf SAP R/3 Enterprise wird die neue Upgrade-Technologie “System Switch” der Integrations- und Applikationsplatform SAP NetWeaver genutzt. “System Switch” ist Bestandteil des Software Life Cycle Managements von SAP NetWeaver und wird mit dem SAP Web Application Server (SAP Web AS) 6.20 ausgeliefert. Die Technologie bietet zwei Optionen für einen Upgrade: Entweder “Ressource Minimized” für einen moderaten Verbrauch der Systemressourcen oder “Downtime Minimized”, mit der sich die Ausfallzeit minimieren lässt. Während die durchschnittliche Ausfallzeit bei einem Upgrade der Variante “Ressource Minimized” rund 16 Stunden betrug, lag sie bei “Downtime Minimized” bei nur sieben Stunden.

Das Upgrade beginnt schon in der produktiven Zeit

Die Auswahl “Downtime Minimized” erlaubt es, einige Phasen des Upgrades, die bislang die Ausfallzeit verlängert haben, in die produktive Zeit zu verschieben. Bei früheren Upgrades, die mit der so genannten Repository-Switch-Technologie durchgeführt wurden, verlängerte sich die Ausfallzeit unter anderem durch die Anzahl der eingebunden Support-Packages und Sprachen. Jetzt liegen diese Phasen, ebenso wie der Data-Dictionary-Abgleich (Transaktion SPDD) noch in der produktiven Zeit. Der Upgrade kann daher schon tagsüber beginnen, ohne dass die Anwender am System etwas davon merken.

Die “Schatteninstanz” macht den Unterschied

Schatteninstanz

Schatteninstanz

Dies ist möglich, weil zu Beginn des Upgrades in der produktiven Datenbank eine zweite Instanz des SAP Web AS aufgebaut wird. Dieses so genannte Schattensystem läuft bereits auf der Software-Version des Ziel-Release. Wichtige Objektbehandlungen, die bislang in die Ausfallzeit des Systems fielen, lassen sich nun parallel zum Produktivbetrieb auf dem inaktiven Schattensystem vornehmen. Bei der Installation der Schatteninstanz wird die SAP MCOD (Multiple Components in One Database) verwendet. Hierbei wird in derselben Datenbank-Instanz ein zweites Schema installiert, in der die Tabellen des SAP Web AS abgelegt werden. Die nebenstehende Grafik zeigt das Datenbanklayout während des Upgrades. Dabei werden die Tabellen der Schatteninstanz zusätzlich zu den Tabellen des Start-Release in die Datenbank geladen.
In die Schatteninstanz werden nur die Standard-User – DDIC, für Dictionary-Aufgaben, und SAP*, mit Vollberechtigung – kopiert. Der SPDD-Abgleich lässt sich nicht mit dem User DDIC vornehmen. Daher ist es notwendig, diesen User auf einen neuen Namen in der Transaktion SU01 zu kopieren. Da die Applikationstabellen in der Schatteninstanz nicht zugänglich sind, bleiben die Unternehmensdaten geschützt.
Der Zugriff auf die Schatteninstanz erfolgt ausschließlich mit dem neuen Kernel und den Werkzeugen des SAP Web AS 6.20. Es ist daher erforderlich, auf mindestens einem Client im Unternehmen den SAP GUI 6.20 zu installieren, damit sich der SPDD-Abgleich, der Dictionary-Abgleich also, durchführen lässt. Nach dem Uprade muss auf allen Clients, die mit SAP R/3 Enterprise arbeiten sollen, der SAP GUI 6.20 installiert sein. Da der SAP GUI 6.20 abwärts kompatibel ist, kann er bereits im Vorfeld des Upgrade-Projektes auf allen Clients installiert werden.

Die manuelle Nacharbeit verringert sich

Um den Arbeitsspeicher und die CPU der Zentralinstanz nicht mit der zusätzlichen Schatteninstanz zu belasten, ist es möglich, einen weiteren Host anzugeben, auf dem diese installiert wird. Ein Blick in die Prozessliste der Zentralinstanz zeigt, dass die Schatteninstanz in Betrieb ist. Die meisten Phasen des Upgrades laufen nun auf dieser zweiten Instanz in der produktiven Phase. Dazu zählt das Einbinden von Support Packages für das Ziel-Release. Dies erlaubt es, bei einem Upgrade sofort auf den aktuellsten Stand der Support Packages zu gehen, ohne damit die Ausfallzeit zu verlängern oder die Support Packages nach dem Upgrade manuell einspielen zu müssen. In der produktiven Phase lässt sich auch das SPAM/SAINT Package – mit dem die Support Packages eingespielt werden – einbinden, so dass auch hier eine manuelle Nacharbeit entfällt. Weitere notwendige Nacharbeiten sind dem Upgradeleitfaden zu entnehmen.
Das alte System wird erst zur Upgradephase ModProfTrans produktiv heruntergefahren. Bis dahin lassen sich alle Applikationsserver weiterhin wie gewohnt betreiben und sämtliche Hintergrundjobs einplanen. Erst bei Bestätigung der ModProfTrans-Phase ist es erforderlich, alle Hintergrundjobs auszuplanen und die Zentralinstanz zu isolieren. Es empfiehlt sich nun, ein Voll-Backup durchzuführen. Damit lässt sich der Upgrade während der folgenden Upgrade-Phasen jederzeit zurückzusetzen. Zudem besteht die Möglichkeit, das Backup online während des gesamten Upgrades durchlaufen zu lassen. Allerdings ist ein Rollback mit Datenbankmitteln dann meist schwieriger, als das Backup zurückzuspielen.

Transporte einspielen

Nach der technischen Downtime ist der SPAU-Abgleich (Programm-Abgleich) durchzuführen. Um Zeit zu sparen, sollten nun die Transporte aus dem Testsystem eingespielt werden. Anschließend ist es notwendig, noch die Customizing-Transporte der Fachabteilungen einzuspielen. Je nach Anzahl und Umfang dieser Transporte dauert dies mehrere Stunden. Der Upgrade-Leitfaden führt weitere Nacharbeiten auf, die abzuarbeiten sind. Dazu gehören das Auffüllen der Sprachentabellen, die Generierung der ABAP-Programme oder das Löschen von nicht mehr benötigten Tablespaces. Das System läuft nun auf dem Release SAP R/3 Enterprise. Die reelle Ausfallzeit setzt sich also aus der technischen Downtime, den Nacharbeiten und dem Backup zusammen.
Zum Abschluss des Upgrades fehlt nun lediglich noch die Freigabe des Systems. Üblicherweise wird ein Systemtest durch die Key User durchgeführt. Nach erfolgreichem Test kann das System für die Endbenutzer freigegeben werden.

Meist ist keine neue Hardware notwendig

Ressourcenanforderungen

Ressourcenanforderungen

Viele Kunden fragen sich, welche Ressourcenanforderungen für SAP R/3 Enterprise gelten. Die nebenstehende Grafik veranschaulicht die notwendigen Ressourcen im Vergleich zu SAP R/3 3.1I. Der CPU-Mehrbedarf des Applikationsservers liegt beim Upgrade von Release SAP R/3 4.0b nach SAP R/3 Enterprise bei 43 Prozent. Ausgehend von SAP R/3 4.6C hingegen beträgt der zusätzliche CPU-Bedarf nur fünf Prozent. In den meisten Fällen ist es also möglich, die für SAP R/3 4.6C genutzte Hardware weiter zu betreiben. Damit fallen keine neuen Kosten für Hardware an.
Details zur Performance sind den SAP Notes 89305, 151508, 178616 und 323263 zu entnehmen.
Weitere Artikel zum Thema “ERP” in der Print-Ausgabe von SAP INFO.

Tim Steinmayr

Tags: ,

Leave a Reply