Computerwoche-Serie

SAP-Migration Teil 5: SAP-R/3-Umstieg mit wenig Systemstillstand

13.11.2007
Von Markus Koschnike
Maßnahmen und Tools helfen, die Ausfallzeit bei einer Migration auf ERP 6.0 kurz zu halten.

Wenn bei SAP-Anwendern eine ERP-Migration ansteht, möchten sie die Ausfallzeit (Downtime) möglichst einschränken. Die Dauer der technischen Migration hängt unmittelbar abhängig von der Datenbankgröße und der Leistungsfähigkeit der Hardware (CPU Leistung sowie Durchsatz der Plattensubsysteme) ab. Häufig ist es jedoch nicht möglich, die Kapazität der vorhandenen Server zu erweitern. Und insbesondere dann, wenn im Zuge des ERP-Systems auch die Hardware ausgetauscht wird, ist es auch nicht sinnvoll, noch in die oftmals veraltete Technik des Quellsystems zu investieren.

R3load

Das Standardverfahren zur SAP-Migration ist "R3load". Das vom SAP-Installationsprogramm Sapinst beziehungsweise R3setup gesteuerte Migrations-Tool exportiert den Datenbankinhalt des Quellsystems. Dieser wird anschließend manuell in das Zielsystem transferiert und dort importiert. Allerdings gestattet es das Verfahren nicht, die Stammdaten zu verbessern. Es eignet sich deshalb nur für Systeme mit relativ kleiner Datenbankgröße sowie geringen Verfügbarkeitsanforderungen.

Package Splitting

Etwas anders arbeitet "Package Splitting". Dieses Verfahren teilt die Tabellen der Quelldatenbank in Pakete ("Packages") auf und exportiert sie. Jeweils ein eigener R3load-Prozess verarbeitet ein Package. Diese Vorgänge können parallel laufen und somit die CPU besser auslasten. Die Bearbeitungszeit für die einzelnen Packages hängt vom Umfang der Tabellen ab und kann daher variieren. Unter Umständen verlangsamen umfangreiche Packages die Migration erheblich, da es von Vorteil ist, Packages gleich groß zu machen. Splitting-Tools von SAP sorgen für eine annähernde Gleichverteilung. Allerdings erfordern diese Werkzeuge eine Perl- beziehungsweise Java-Laufzeitumgebung. Beschleunigen lässt sich die Migration, wenn der Anwender die Bearbeitungsreihenfolge der Packages selbst festlegt. Das Package-Splitting-Verfahren bietet im Vergleich zum Standardverfahren bereits eine signifikante Verbesserung der Laufzeit. In fast allen Migrationen kommt es zum Einsatz.

Datenbankwerkzeuge

Die Datenbanksysteme Oracle und SAP (Max DB, vormals SAP DB) können die ERP-Datenbank mit Hilfe von integrierten Datenbankwerkzeugen ex- und importieren. Diese benötigen verglichen mit den herstellerunabhängigen SAP-Migrations-Tools weniger Zeit für die Umstellung. Allerdings erlauben es die datenbankspezifischen Programme nicht, das Datenbanksystem auszutauschen. Ferner ist es mit ihnen nicht möglich, den Datenbestand nach Unicode zu konvertieren.

Migration- und Distribution-Monitor

SAP stellt für die technischen Migration die Java-Tools "Migration Monitor" sowie "Distribution Monitor" zur Verfügung. Der Migration Monitor dient dazu, parallel Daten aus dem Quellsystem zu exportieren und in die Zieldatenbank zu importieren. Er bietet sich auch für ältere SAP-Releases und für die Unicode-Konvertierung an. Daher ist der SAP-Migrations-Monitor das meistgenutzte Tool für Laufzeitverbesserungen sowohl beim Wechsel des Betriebssystems beziehungsweise der Datenbank als auch bei Unicode-Konvertierungen.

Vor- und Nachteile der Optimierungsmethoden.

Verfahren

Unicode-Konvertierung

Aufwand

Zeitgewinn

Praktische Bedeutung

Sapinst

Ja

++

--

++

Package Splitting

Ja

++

-

++

Datenbank-Tools

Nein

++

+

O

Migration Monitor

Ja

+

+

+

Distribution Monitor

Ja

O

+

+

R3load Socket

Nein

+

+

O

Table Splitting

Ja

++

+

+

IMIG

Ja

--

++

--

Zero Downtime

Ja

-

++

-

Der Distribution Monitor verwendet mehrere Applikations-Server für die Migration, um Export- und Importvorgänge besser zu parallelisieren. Auf den Applikations-Servern läuft jeweils eine Instanz des Migration Monitors, die vom Distribution Monitor kontrolliert und gesteuert wird. Dieses Verfahren nutzt die verfügbare Datenbankkapazität bestmöglich aus und reduziert damit die Laufzeit für den Systemumstieg erheblich.

R3 Socket Connections

Beim Export und Import über "R3 Socket Connections" wird der Inhalt der Quelldatenbank nicht auf Disk exportiert, sondern direkt über eine Netzwerkverbindung an das Zielsystem gesendet und dort sofort importiert. Import und Export laufen demnach gleichzeitig ab. Voraussetzung ist jedoch eine zuverlässige Netzverbindung zwischen Quell- und Zielsystem. Mit diesem Verfahren ist allerdings keine Unicode-Konvertierung möglich, und es ist nur für Systeme vorgesehen, die mit dem Web Application Server 6.40 (WAS) arbeiten. Eine Migration über R3 Socket Connections eignet sich daher insbesondere dann, wenn es schwierig ist, zusätzlichen Speicherplatz für den Exportdump bereitzustellen.

Table Splitting

Beim Table Splitting handelt es sich um ein relativ junges Verfahren, das bis vor kurzem nur auf Anfrage zu bekommen war, inzwischen aber allgemein verfügbar ist. Es funktioniert ähnlich wie Package Splitting, jedoch teilt es keine Pakete neu auf, sondern Tabellen. Solche mit langer Laufzeit splittet die Routine in mehrere Blöcke auf, um diese anschließend in mehreren R3load-Prozessen parallel zu bearbeiten. Table Splitting migriert nur Systeme ab WAS 6.40, zudem leistet SAP bei Problemen mit dem Tool nur eingeschränkt Support. Jedoch verkürzt das Table-Splitting-Verfahren die Migration unter Umständen erheblich.

Minimized Downtime

Der Service "Minimized Downtime", früher auch als "Inkrementelle Migration" (IMIG) bekannt, wird heute nicht mehr als eigenständige technische Migrationsmethode angeboten. Der Dienst steht nur noch in Verbindung mit einem von SAP Consulting erbrachten Dienstleistungspaket zur Verfügung. Das Preismodell hängt dabei von der jeweiligen Datenbankgröße und der benötigten Downtime ab. Das aufwändige Verfahren ist für Datenbanken im Terabyte-Bereich und Systeme mit hohen Verfügbarkeitsanforderungen geeignet. Daher sollten Kunden bei großen Datenbanken alternativ eine Datenarchivierung in Betracht ziehen.

Zero Downtime

Bei einem "Zero Downtime"-Verfahren sind geschäfts- und produktionskritische Prozesse während der gesamten Migrationsphase weiter verfügbar, die Downtime beträgt nahezu null. Zu Beginn des Verfahrens erstellen SAP-Experten vor der geplanten Systemänderung zunächst eine Kopie des produktiven ERP-Systems. Die Anwender arbeiten mit dieser Kopie kontinuierlich weiter, während auf dem Ursprungssystem die Migration erfolgt. In dieser Zeit laufen Benutzertransaktionen und Daten gegen die Systemkopie. Der letzte Schritt besteht darin, die in der Zwischenzeit angefallenen Aktivitäten in das neue System aufzunehmen und die Benutzer in die neue ERP-Umgebung einzubinden.

Das Zero-Downtime-Konzept lässt sich individuell anpassen und unterstützt sowohl SAP-Standard- als auch kundenspezifische Transaktionen. Die Kunden definieren selbst die Geschäftsprozesse und Transaktionen, die während der Migration verfügbar bleiben. Projektkosten lassen sich reduzieren, wenn sich das Unternehmen auf die kritischen Geschäftsabläufe beschränkt. Dieses Verfahren eignet sich vor allem für Systeme mit hohen Verfügbarkeitsanforderungen, etwa für Industrieunternehmen mit einer Produktion im Schichtbetrieb. Der zeitliche und finanzielle Aufwand ist in erster Linie von der Zahl der benötigten Transaktionen während der Migration abhängig. (fn)