Von Chris Kohlsdorf, REALTECH AG
Datenbank Migrationen sind innerhalb der Gruppe der SAP Anwender ein hoch aktuelles Thema. Was veranlasst diese Kunden darüber nachzudenken, die bereits etablierten Datenbanksysteme anzulösen und damit verbunden neue Technologien einzuführen? Mit SAP NetWeaver und der SAP Enterprise SOA kommen auch in technologischer Hinsicht neue Herausforderungen auf SAP-Kunden zu. Eine zukünftig komplexer werdende Systemarchitektur bedingt, dass sich Kunden bereits heute damit beschäftigen ihre IT-Landschaften zu harmonisieren und zu konsolidieren. Die Datenbank-Migration ist dabei oft nur ein Teil eines groß angelegten Konsolidierungsprojektes, wenn auch ein entscheidender. Weitere Faktoren die einen Wechsel der Datenbank zur Folge haben sind eher betriebswirtschaftlicher Natur. Kostenfaktoren spielen hierbei die entscheidende Rolle. Nicht jedoch, wie man vermuten könnte, nur die reinen Lizenzkosten. Viel wichtiger ist inzwischen die Betrachtung der laufenden Kosten, die sich unter Anderem aus Wartung, Betrieb und Know-how Aufbau der operativen Einheiten zusammensetzen.
Anwenderunternehmen stellen sich berechtigterweise die Frage, welche die beste Datenbank für die eigene Applikation ist. Eine Frage, auf die keine pauschale Antwort gegeben werden kann. SAP Systeme sind zu spezifisch an die Anforderungen jedes einzelnen Unternehmens angepasst, das Datenaufkommen in den Systemen ist stark branchenabhängig, was zur Folge hat, dass nur Entscheidungshilfen gegeben werden können, jedoch keine allgemeingültigen Empfehlungen.
Der Zusammenhang zwischen Datenbank und Betriebssystem
SAP unterstützt für den Betrieb von SAP-Systemen eine Reihe verschiedener Datenbanken. Die Freigaben für den produktiven Einsatz erfolgen spezifisch nach SAP-Datenbank- und Betriebssystem-Release. Ein Aspekt, der bei der Auswahl einer Datenbank unter allen Umständen zu berücksichtigen ist, will man mit der Einführung eines neuen Datenbank-Systems nicht auch das Betriebssystem wechseln.
Während der Microsoft SQL Server das Betriebssystem von Microsoft voraussetzt werden beispielsweise IBM DB2 UDB, MaxDB und Oracle 10.2 von den Betriebssystemen Aix, HP-UX, Microsoft und Linux unterstützt (siehe Tabelle1: OS/DB Kombinationen).
Abgesehen von wenigen administrativen Funktionen in den Bereichen der Datenbanksicherheit und Datenbankpflege, spielen die mittlerweile sehr umfangreichen Feature-Listen der Datenbankhersteller für den Betrieb von SAP-Systemen eine eher untergeordnete Rolle. SAP greift nur auf eine geringe Anzahl von Funktionalitäten zurück. Mögliche Schnittstellen, Web-Fähigkeit, Data-Warehousing usw. nicht genutzt. Dies ist leicht nachvollziehbar, vor dem Hintergrund, dass sich die SAP nicht aus funktionalen Gründen auf eine Datenbank festlegen will. Darüber hinausgehende Features der einzelnen Anbieter, wie beispielsweise Datensicherung oder Hochverfügbarkeit ähneln sich zunehmend mit jedem neuen Datenbank-Release. Unterschiede lassen sich beinahe nur noch in der technischen Umsetzung finden.
Bei administrativen Funktionen und Funktionen zur Datensicherheit beharrte die SAP in Vergangenheit auf den Einsatz eigener Lösungen. Dies hat sich grundlegend geändert. Nicht zuletzt weil viele Kunden dies gefordert haben.
Welche Möglichkeiten gibt es für die Datensicherungen?
Generell wird zwischen zwei verschiedenen Arten der Datensicherung unterschieden: die Voll-Sicherung und die Delta-Sicherung (Incremental Backup).
Bei einer Voll-Sicherung wird die komplette Datenbank gesichert. Bei einer Delta-Sicherung wird nur die Differenz zwischen der letzten Voll-Sicherung und dem aktuellen Stand gesichert.
Die Voll-Sicherung kann sowohl in einer Online- als auch in einer Offline-Variante realisiert werden. Dabei ist unbedingt zu beachten, dass auch die Transaction- oder Redo-Logs gesichert werden. Diese werden benötigt, um den exakten Zeitpunkt der wiederhergestellten Daten für ein Disaster Recovery bestimmen zu können.
Bei einem Voll-Backup sichern Microsoft SQL, MaxDB und IBM DB2 UDB den tatsächlichen Inhalt der Datenbank, während Oracle die komplette Datenbank auf das Backup-System kopiert. Oracle Backups sind dadurch schneller durchzuführen als die der anderen Anbieter, mit dem Nachteil, dass unter Umständen mehr Speicherplatz vonnöten sein kann. Die speichersparende Vorgehensweise von beispielsweise Microsoft bedarf einer Strukturanalyse vor jedem Backup, was bei komplexen Systemen die Performance negativ beinträchtigen kann. Somit gilt auch hier abzuwägen, was für das jeweilige Anwender-Unternehmen wichtiger ist – Schnelligkeit oder die Schonung von Ressourcen.
Bei einem Incremental- oder Deltabackup wird der Unterschied zu der letzten Voll-Sicherung ermittelt. Diese Ermittlung kann sehr ressourcen- und zeitaufwendig sein, da zunächst die Änderungen zu dem letzten Backup ermittelt werden müssen. Dadurch kann sogar ein großer Teil des Zeitgewinnes wieder aufgezehrt werden, den diese Form des Backups verspricht. Bei großen Datenbanken bleibt dennoch der Vorteil der Platzeinsparung auf den Backup System. Während für Microsoft SQL, MaxDB und IBM DB2 UDB ohnehin die Backup Tools des Datenbank Herstellers hierfür genutzt werden, muss für Oracle das komplette Backupverfahren für Oracle RMAN konfiguriert sein. Aus der reinen Kopie der Datenfiles ist es nicht möglich ein Delta zu ermitteln. Für ein Desaster Recovery wird immer das letzte Voll-Backup und das letzte Incremental-Backup benötigt.
Welche Formen der Hochverfügbarkeit gibt es für die Datenbanken?
Das Thema der Hochverfügbarkeit ist in vielen Branchen, wie beispielsweise im Automotive Sektor ein sehr wichtiges Thema. Der konstante Ablauf der Unternehmensprozesse hängt vom sichergestellten Betrieb der IT-Prozesse ab. Ausfälle führen umgehend zu Einschränkungen in der Produktion und damit zu finanziellen Verlusten für das Unternehmen.
Unter Berücksichtigung dieser Situation empfiehlt es sich, bei der Auswahl einer Datenbank verstärkt darauf zu achten, ob der Betrieb einer „Standby-“ oder „Schattendatenbanken“ möglich ist. Die eigentliche Realisierung ist dank der fortgeschrittenen Technik keine große Herausforderung mehr.
Schattendatenbanken sind identische Kopien der produktiven Datenbank auf einer anderen Hardware. Diese Kopie wird dann über bestimmte Mechanismen mit den gleichen Daten aktualisiert wie die produktive Datenbank. Fällt die primäre Datenbank aus kann die Schattendatenbank den produktiven Betrieb beinahe unterbrechungsfrei übernehmen. Werden die Transaktionen asynchron verbucht spricht man von einer Standby-Datenbank. Erfolgen die Verbuchungen auf der Standby-Datenbank synchron wird auch von einer Hot Standby Lösung gesprochen.
Mit der Software Oracle Data Guard kann der Betrieb einer Standby-Datenbank für Oracle weitestgehend automatisiert werden. Mit dem Betrieb einer logischen Standby-Datenbank ermöglicht Oracle noch eine weitere Backup-Variante. Hier werden direkt SQL-Statements auf die Standby-Seite übertragen. Diese Instanz kann dann sogar im read-only Modus gestartet werden. So läßt sich ein eingeschränktes System für die Batchverarbeitung aufbauen, zur Reduzierung der Last auf der produktiven Datenbank.
MaxDB von MySQL kann sowohl für den Standby als auch den Hot-Standby-Betrieb konfiguriert werden. Bei beiden Konzepten verfügen die Datenbanken über einen eigenen Datenbereich. Im Standby-Betrieb werden die Logs vom Quellsystem auf die Schattendatenbank übertragen. Im Hot-Standby-Betrieb dagegen wird auf einen gemeinsamen Logbereich zugegriffen. Dies ermöglicht die Verbuchung von Transaktionen mit einer frei konfigurierbaren Verzögerung, ohne dass ein Log komplett abgeschlossen sein muss. Somit kann bei einem Ausfall der produktiven Datenbank der potenzielle Datenverlust drastisch verringert werden.
Beim Einsatz von IBM DB2 UDB 8.2 HADR werden die Log-Dateien lokal gehalten. Die Transaktionen werden über Protokolldateien übertragen und verbucht. Es wird zwischen der synchronen und asynchronen Datenübertragung unterschieden. Im synchronen Modus werden Transaktionen in der produktiven Instanz erst dann verbucht, wenn die Datei auch auf der Standby-Instanz geschrieben wurde. Dadurch wird die Synchronität beider Systeme garantiert. Die Übertragungszeit verzögert jedoch die Datenverbuchung und hat somit Einfluss auf die Datenbank-Performance. Im asynchronen Modus wird systemseitig nur die Übergabe der Protokolldatei an das Netzwerk überprüft. Dieser Modus hat keine Auswirkungen auf die Performance der Datenbanken.
DB2 und Oracle bieten darüber hinaus die Möglichkeit zwischen Master-Datenbank und Standby-Datenbank umschalten zu können. Die beiden Datenbanken tauschen lediglich die Rollen. Dies kann für zusätzliche Wartungsfenster genutzt werden, ohne die Onlinezeit der Anwendung zu beeinträchtigen. Dieser Wechsel bedingt keinerlei nachträglichen Aufwand wie beispielsweise für Rücksicherungen. Somit kann die System-Verfügbarkeit auch ohne Betriebssystem-Cluster erhöht werden.
Mit Version 2005 Microsoft SQL Server bietet auch die Microsoft eine Hot Standby-Lösung an. Äquivalent zu den anderen Datenbanken - wenn auch mit anderer Technologie - gibt es synchrone und asynchrone Transfer-Mechanismen. Für die vollautomatisierte Übernahme des „mirrors“ (Ersatzsystem) von dem „principal“ (Produktivsystem) muss allerdings noch ein so genannter „Witness Server“ konfiguriert werden, der dem Ersatzsystem den Ausfall des produktiven Systems bestätigt.
Auch für die IBM DB2/390 kann eine Hot Standby Lösung konfiguriert werden. Der asynchrone Standby Betrieb ist auch für IBM DB2 auf iseries möglich.
Für alle Konzepte gilt, je höher der Grad der Synchronität zwischen der Quelldatenbank und der Standby-Datenbank, desto größer der Einfluss auf die Transaktionslaufzeiten.
Hochverfügbarkeit durch Cluster-Integration
Auch eine Integration in die jeweiligen Clusterlösungen der Betriebssystem-Hersteller stellt heute kein unlösbares Problem mehr dar.
Die Datenbanken von MaxDB, Oracle und IBM DB2 UDB lassen sich ebenso auf einem Microsoft-Cluster betreiben, wie auch in Clusterlösungen von HP, IBM, Sun und SteelEye. Für Microsoft SQL-Server ist der Microsoft Cluster verfügbar.
Oracle sticht mit seiner eigenen Lösung, dem Real Application Cluster (RAC), gegenüber den anderen Datenbanken etwas hervor. Oracle RAC bietet die Möglichkeit, die Datenbank-Serversoftware selbst auf mehrere Server zu verteilen und somit die Datenbank hochverfügbar zu betreiben. Ein weiterer Nutzen der Oracle RAC Technologie ist die Lastverteilung des Datenbankbetriebs auf mehrere Server. Ein Vorteil, der erst durch das Cluster File System ermöglicht wird, das für jedes Betriebssystem separat bei SAP zertifiziert werden musste.
Einsatz in der Praxis: UNICODE und BW-Projekte
Wie verhalten sich die Datenbanken nun, wenn wir sie in der Praxis betrachten?
SAP UNICODE-Betrieb der Datenbanken
Während IBM DB2 UDB und Oracle intern mit einer UTF-8 Codepage operieren, steigt der Platzbedarf bei den mit UTF-16 operierenden Datenbanken deutlich höher an. Die Höhe des Zuwachses ist aber nicht zuletzt von der Art der Daten abhängig oder aus welchen Zeichen sie bestehen. MySQL arbeitet bereits an einer Umstellung auf eine UTF-8 Codepage um diesen Nachteil auszugleichen. Bei einer UNICODE-Migration eines bestehenden SAP-Systems kann für Oracle und DB2 UDB ein Reorganisationseffekt der Datenbanksegmente hinzukommen. Die beiden Datenbanken können nach dem Reimport der Daten sogar ein geringeres Volumen aufweisen als vor der Migration. Die Speicherlogik der anderen Datenbanken lässt das nicht zu. Lücken, die durch Archivierungen oder Löschung von Daten entstanden sind, werden von der Datenbank sofort wieder genutzt.
Bei SAP Business Warehouse (BW)-Systemen unter Microsoft SQL Server 2005 ist die Nutzung der Partitionierung von Fact- und PSA-Tabellen möglich. Die Ramp Up-Phase wird voraussichtlich bis Ende 2006 beendet sein. Die Möglichkeit der Tabellen-Partitionierung war bisher Oracle-Nutzern vorbehalten und bietet klare Performance-Vorteile. Das ist sicherlich ein Grund, warum viele sehr große BW-Systeme auf Oracle betrieben werden. Hiervon können auch BW 3.5 Installationen und nachfolgende Releases auf Microsoft SQL Server 2005 profitieren.
Die wahren Auswahlkriterien...
Erstaunlich ist, dass in der Vergangenheit die ausschlaggebenden Kriterien für die Auswahl einer Datenbank oft die vermutete Stabilität und der Marktanteil des Datenbank-Anbieters, also dessen Renommee waren. So finden wir häufig in Rechenzentren kleine SAP-Inseln mit 100 bis 200 SAP-Usern und einem jährlichen Datenwachstum zwischen fünf und dreißig GB, die aus einer Oracle- Datenbank auf einem kommerziellen Unix bestehen. Dies lässt darauf schließen, dass Lizenzkosten, Homogenität und Administrationsaufwand kein bedeutendes Kriterium bei der Wahl der Datenbank waren.
Dies hat sich in der Zwischenzeit geändert. Geringer Administrationsaufwand und die Lizenzkosten spielen heute bei der Auswahl der geeigneten Datenbank eine entscheidende Rolle. Dies wird dadurch bestärkt, dass Wartungs- und Administrationsaufwand einen größeren Faktor bei einer TCO Betrachung einnehmen als die Lizenzkosten.
Mit Microsoft SQL-Server und MaxDB stehen zwei Datenbanken zur Verfügung die diesem Trend bereits gefolgt sind.
Erfahrungen aus den Migrationsprojekten des Walldorfer Technologieberaters REALTECH belegen dies. Zum einen findet der System-Wechsel innerhalb der Microsoft-Welt - von Oracle auf Microsoft SQL Server - statt. Zum anderen ist bei den Migrationsprojekten ein Trend in Richtung MaxDB unter der Zielplattform Linux zu verzeichnen.
Kostenbetrachtung
Grundsätzlich gilt, dass Datenbank-Lizenzen pauschal über die SAP abgerechnet werden können. Der Aufschlag auf den Preis für den Anwendungswert beträgt etwa 3% für MaxDB, 8% für Microsoft SQL Server und DB2 UDB und jeweils 11% für Oracle und DB2 / OS390.
Für die Nutzung von Oracle RAC berechnet SAP nochmals einen Aufschlag von 3%* (Stand 1.9.2005 Quelle: Informationsblatt für SAP-Partnerunternehmen SAP-Software 2005).
Sind in der IT-Infrastruktur noch weitere unterschiedliche Datenbankanwendungen im Betrieb, werden oft auch die SAP Datenbanken direkt über den Datenbank-Hersteller lizenziert. Dies kann sogar kostengünstiger sein, hat aber den Nachteil der engeren Bindung an den Hersteller.
Fazit
Welche Datenbank nun die beste ist, hängt schlussendlich von mehreren Faktoren ab und resultiert aus den individuellen Anforderungen des Unternehmens.
Während für die Einen, geringer Administrationsaufwand und reduzierte Aufwendungen für den Betrieb die Hauptfaktoren sind, so kann dies bei einem anderen Unternehmen maximale Sicherheit bei maximaler Performance sein.
Unter dem Aspekt der Zukunftssicherheit kann nur empfohlen werden sensibel darauf zu achten, wie eng und kooperativ sich die Zusammenarbeit der SAP mit den entsprechenden Datenbankherstellern gestaltet. Die Partnerschaft der SAP mit Microsoft ist mit Sicherheit ein gutes Beispiel für eine funktionierende Zusammenarbeit, was nicht zuletzt durch gemeinsame Produktentwicklungen wie Duet bestätigt wird.