Die Oracle-Datenbank ist traditionell die meistgenutzte Plattform im SAP-Umfeld. Das liegt daran, dass diese Datenbank die erste war, die für SAP R/3 zur Verfügung stand, so dass sich die meisten SAP-Anwender auch in den Folgejahren für die Plattform entschieden haben.

Oracle ist zwar weiterhin Marktführer mit über 70 Prozent Anteil im deutschen Markt, IBM DB2 Universal Database und Microsoft SQL Server haben jedoch in den letzten Jahren deutlich hinzugewonnen.

Das Thema Datenbank und die eventuelle Migration beschäftigt die SAP-Anwender aber gerade in den letzten Monaten primär aus drei Gründen: An der eingesetzten Datenbank soll gespart werden; die Migration zu Mysap soll mit einem Wechsel der Datenbankversion verbunden werden; ein Umstieg auf Unicode steht bevor.

In puncto Kosten kann sich durchaus ein Vergleich von Alternativprodukten lohnen. Aus der SAP-Preiliste geht hervor, wieviel für Lizenzen für Oracle-Datenbanken, "DB2 UDB" von IBM, MySQLs "Max DB" und "SQL Server" von Microsoft, zu zahlen ist. Da sich diese Lizenzkosten ähnlich wie die für die SAP-Lösung selbst in der Folge auch in Wartungskosten niederschlagen, die ja prozentual auf den Softwareanschaffungswert bezahlt werden, hoffen manche Kunden, durch einen Umstieg sparen zu können. Auch SAP-Einsteiger setzen sich zunehmend mit dem Thema Datenbank auseinander und sehen diese nicht mehr nur als notwendige Softwarekomponente für den Betrieb von SAP-Produkten.

Die Begriffe SAP-Migration, OS/DB-Migration oder "Crossload" werden üblicherweise synonym für eine heterogene SAP-Systemkopie verwendet. Hierunter versteht man den Wechsel der Datenbanksoftware, des Betriebssystems oder eine Kombination aus beidem auf dem Datenbank-Server eines SAP-Systems. Um diesen Wechsel zu ermöglichen, hat SAP ein standardisiertes Verfahren etabliert und stellt Migrationswerkzeuge zur Verfügung.

Ausfallzeiten kurz halten

Beim traditionellen Verfahren "SAP R/3load" ist das Quellsystem während der gesamten Laufzeit des Datenexports und -imports nicht verfügbar. Eine inkrementelle Migration erlaubt, mit Teilen einer SAP-Datenbank im laufenden Betrieb umzuziehen und damit die Ausfallzeit zu verkürzen.

Im Gegensatz hierzu verwenden Systemverwalter eine homogene Systemkopie, um die Datenbank eines SAP-Systems - unter Beibehaltung der Datenbankplattform und des Betriebssystems - auf einen neuen Server zu übertragen. Dies kann über das R/3 load-Verfahren erfolgen, üblicherweise kommen hier aber einfachere Verfahren wie Datenbanksicherung und -wiederherstellung oder die Anbindung des Plattensubsystems an den neuen Server zum Einsatz.

Gemeinsame Migrationen von Betriebssystem und Datenbank können trotz des vielfach erprobten Umstellungsprozesses umfangreich und aufwändig sein - abhängig von Größe und Anzahl der betroffenen SAP-Landschaften.

Aus technischer Sicht kann eine Migration durch die Einstellung der SAP-Unterstützung für eine bestimmte Datenbank- oder Betriebssystem-Plattform (etwa Informix IDS, Reliant Unix, Tru64) notwendig werden. Anlass kann aber auch eine anderweitige geplante Veränderung innerhalb der Systemlandschaft sein.

Beispielsweise sind SAP-Release-Upgrades beziehungsweise der Umstieg auf Mysap ERP üblicherweise mit der Anschaffung einer neueren, leistungsfähigeren Hardware verbunden. Ist in diesem Zusammenhang ein Wechsel des Betriebssystems geplant, kann zeitgleich ein Datenbankwechsel in Betracht gezogen werden. Betriebssystem- und Datenbankumstellung können technisch in einem Schritt erfolgen. Durch das Kombinieren beider Schritte lässt sich Geld sparen.

Im Rahmen einer geplanten Umstellung auf Unicode-basierende SAP-Systeme sollten Anwender gleichzeitig den Wechsel der Datenbank- oder der Betriebssystemplattform in Betracht ziehen. Technisch wird für eine Unicode-Migration und eine OS/DB-Migration dasselbe Verfahren eingesetzt, die Umstellung kann also auf einen Schlag erfolgen.

Die Dauer der Migration hängt stark von der Zahl der betroffenen Systeme ab. Während die Umstellung eines einzelnen größeren Systems in der Regel innerhalb eines Wochenendes geschieht, erstreckt sich das gesamte Projekt oft über mehrere Monate.

Hat der Kunde sich für eine neue Plattform entschieden und die Verträge mit seinen Lieferanten und der SAP angepasst, erstellt er einen Projektplan für die Systemumstellung. Hierzu sind gute Kenntnisse sowohl der Quell- als auch der Zielplattform erforderlich.

Migration Check

Nach Überprüfung der Projektplanung versendet die SAP die erforderlichen Migrationswerkzeuge. Diese sind kostenlos. Jedoch können für den "SAP OS/DB Migration Check", sprich die Überprüfung der Projektplanung und eine zweimalige "Going-Live"-Sitzung auf dem migrierten System, Kosten anfallen, sofern dieser Service nicht durch den bestehenden Wartungsvertrag mit SAP abgedeckt ist.

Im Anschluss vollzieht der Anwender die erste Testmigration und wiederholt dies so oft, bis die anvisierte Laufzeit der Umstellung - in der Regel ein Wochenende - erreicht wird.

Das nun migrierte System sollte der Kunde intensiv testen. Hierbei sind die Fachabteilungen zur Überprüfung von Funktionen, Schnittstellen zu anderen Systemen und Perfomance genauso einzubeziehen wie das Rechenzentrum. Systemadministratoren sollten eine Backup-Strategie entwickeln, die Einbindung in ein Hochverfügbarkeitskonzept etablieren sowie die allgemeine Bedienbar- keit und das Monitoring der Systeme testen. Auch die SAP validiert in einer Going-Live-Sitzung das testweise migrierte System.

Quellsystem bleibt aktiv

Wurden alle Tests erfolgreich abgeschlossen, kann die finale Migration erfolgen. Das Quellsystem bleibt bestehen, während das Zielsystem auf einer neuen Hardwareplattform aufgesetzt wird. Somit kann der Anwender bei etwaigem Scheitern der Systemumstellung problemlos auf dem alten System weiterarbeiten.

Vier bis sechs Wochen nach einer erfolgreichen Umstellung gibt die SAP in einer erneuten Going-Live-Systemüberprüfung wichtige Empfehlungen für das neue System, und zwar Datenbank-, Betriebssystem- und SAP-Parameter.

Schon vor und während der Migration sollten sich Systemadministratoren mit der neuen Umgebung vertraut machen, um einen reibungslosen Übergang zu gewährleisten. In Frage kommen hier plattformspezifische Schulungen der SAP, des Datenbank- oder des Betriebssystem-Herstellers sowie eine längerfristige begleitende Unterstützung durch einen Basisberater. Erfahrungsgemäß erwerben Administratoren im Datenbank- oder Betriebssystem-Umfeld das notwendige Grundwissen innerhalb weniger Wochen, während der Aufbau von Expertenwissen längere Zeit in Anspruch nimmt.

Technisch ist eine Migration mit drei grundsätzlich unterschiedlichen Verfahren möglich: dem R/3load-Verfahren, einer inkrementellen Migration sowie einer Umstellung mit datenbankspezifischen Funktionen.

Drei Verfahren für den Wechsel

Bei R3load wird das komplette Quellsystem mittels von SAP zur Verfügung gestellten Werkzeugen vollständig in ein von Datenbank und Betriebssystem unabhängiges Format exportiert. Mit Hilfe dieses Exports kann das Zielsystem aufgebaut werden. Die Vorgehensweise des Imports ähnelt stark einer SAP-Neuinstallation. Anstatt des von SAP ausgelieferten DB-Exports werden aber die eigenen Firmendaten in die Datenbank geladen.

Export und Import müssen in der Regel innerhalb eines festen Zeitraums erfolgen, üblicherweise innerhalb eines Wochenendes - das Quellsystem muss aus Gründen der Datenkonsistenz während der Umstellung komplett offline sein. Wenige große Tabellen bestimmen erfahrungsgemäß die Gesamtlaufzeit der Migration, hier setzen verschiedene Optimierungsverfahren an.

Liegt der Engpass bei der Exportgeschwindigkeit, so können kritische Tabellen üblicherweise unsortiert entladen werden. Dies kann den Export signifikant beschleunigen - allerdings ist dann in vielen Fällen eine spätere Reorganisation der betroffenen Tabellen im Zielsystem notwenig. Export- und Importprozesse lassen sich von einem sequenziellen auf ein paralleles Verfahren umstellen, sprich eine Tabelle muss nicht mehr komplett entladen werden, bevor sie in das Zielsystem geladen wird, sondern der Export ist über das Netzwerk direkt mit einem Import gekoppelt. Hierdurch lassen sich einzelne Tabellen um bis zu 50 Prozent schneller in das Zielsystem transferieren.

Liegt der Engpass beim Ladevorgang, existieren je nach Datenbank plattformspezifische Optimierungen. Im Beispiel IBM DB2 UDB haben Entwickler der SAP und der IBM gemeinsam eine Möglichkeit geschaffen, SAP-Daten mittels des Tools "DB2 Load" zu laden. Dies führt gegenüber den sonst üblichen einzelnen Insert-Operationen zu Laufzeitverbesserungen.

Inkrementeller Umstieg

Müssen Anwender große Systeme umstellen und gleichzeitig die Offline-Zeiten verkürzen, sollten sie eine inkrementelle Migration in Betracht ziehen. Hierbei werden kritische große Tabellen - welche im herkömmlichen Verfahren üblicherweise die Gesamtlaufzeit einer Migration bestimmen - während des produktiven Betriebs entladen. Daten aus diesen Tabellen lassen sich sukzessive in ein initial installiertes SAP-Zielsystem übertragen. Da sich die Inhalte der Tabellen im Quellsystem ständig ändern und somit im Zielsystem Inkonsistenzen aufweisen, werden alle Datenänderungen in speziellen Tabellen des produktiven Systems mitprotokolliert und Schritt für Schritt im Zielsystem nachgezogen.

In einem zweiten Projektabschnitt schaltet man das Quellsystem offline, alle noch anstehenden Änderungen aus den Protokolltabellen werden ins Zielsystem transferiert und die nicht inkrementell übertragenen Tabellen mittels R3load migriert.

Je nach der eingesetzten Datenbanksoftware können spezielle, von SAP unterstützte Verfahren zur Anwendung kommen, etwa für eine Betriebssystemumstellung. Sind die Datenbanksicherungen beispielsweise zwischen verschiedenen Unix-Derivaten kompatibel, lässt sich ein Wechsel des Betriebssystems mit deutlich vermindertem Aufwand realisieren.