Mit RAC hat Oracle eine Technik entwickelt, die die Verteilung einer Datenbank auf mehrere locker gekoppelte Rechnersysteme (Cluster) auch in normalen Produktivumgebungen erlaubt. Das erst ermöglicht den Einsatz von Clustern zusammen mit der betriebswirtschaftlichen Standardlösung der SAP. Außer DB2 für S/390-Systeme ist bislang keine Cluster-Datenbank für die Zusammenarbeit mit R/3 zugelassen.
Traditionelle Datenbank-Cluster haben es nötig gemacht, eine Anwendung speziell für diese Architektur zu programmieren. Im Wesentlichen mussten die Zugriffe auf die Tabelleneinträge in der Datenbank sortiert erfolgen. Zufällige, gemischte Workloads haben jedoch die Kommunikation zwischen den Cluster-Knoten überlastet und so einen Performance-Einbruch ausgelöst. Nur DB2/390-Cluster in Parallel-Sysplex-Umgebungen zeigen dieses Phänomen nicht.
Die RAC-Technik hat dieses Problem nun ebenfalls nicht mehr. SD-Benchmarks mit R/3 4.6C und einem RAC-basierenden Oracle-9i-Cluster ergeben eine Skalierung mit dem Faktor 1,8, das heißt, bei der Hinzunahme eines zweiten Datenbank-Servers erhöht sich die Leistung um 80 Prozent. Auch beim Schritt von zwei auf vier Knoten skaliert das Gesamtsystem mit dem Faktor 1,8. Die entsprechenden Benchmarks sind bereits von der SAP zertifiziert und die Ergebnisse offiziell verfügbar.
Ausfallsicherheit wird preiswert
Der Vorteil eines RAC-basierenden Systems liegt allerdings weniger in der Lastverteilung selbst als im Verhalten des Systems im Fehlerfall. Eine Datenbank stellt heute in einer R/3-Installation einen Single Point of Failure dar: Fällt der Server aus, liegt das System brach. Aus diesem Grund werden häufig Hot-Standby-Rechner eingesetzt, die bei einem Ausfall einspringen. Der Nachteil: Diese Notfallrechner kosten viel Geld, ohne produktiv zu sein.
RAC umgeht das Problem elegant. Zum Beispiel können vier preiswerte Rechnersysteme gekoppelt und mit einer relativ geringen Last von vielleicht 60 Prozent gefahren werden. Wenn ein Knoten ausfällt, vermögen die anderen Rechner dessen Last leicht zu übernehmen, da sie dann immer noch mit nur 80 Prozent Last fahren.
Die Übernahme des Workloads durch die anderen Server erfolgt in der Regel in wenigen Sekunden. Unternehmen können also die Ausfallsicherheit kostengünstig stark erhöhen. Außerdem steigt die Flexibilität: Droht die Auslastung der Datenbank-Server an eine kritische Grenze zu stoßen, können leicht neue Server in die Umgebung eingebaut werden.
RAC für R/3 und Mysap ist noch nicht allgemein verfügbar. Hierfür fordert SAP zusätzliche Tests, insbesondere auch den Funktionsnachweis in einer Produktivumgebung. Der erste deutsche Pilotkunde, ABB, hat das Personalwesen von R/3 4.6C zusammen mit RAC aber bereits im Einsatz.
Zertifiziert wird als Erstes die Kombination Tru-64-Unix-Systeme (Alpha-Server) von Hewlett-Packard mit Oracle 9i, Version 9.2 RAC. An der Zertifizierung für AIX-basierende P-Series-Rechner von IBM wird ebenfalls gearbeitet. Die Verfügbarkeit hängt auch noch an der Freigabe der Datenbankversion 9.2, die noch nicht für alle Hardwarekombinationen zugelassen ist.
SAP für Tru-64-Systeme mit RAC können Kunden nach Auskunft von Oracle bereits bestellen. Die Freigabe für AIX- und Linux-Plattformen soll im Frühjahr 2003 folgen. Die Linux-Variante ist besonders bedeutsam, weil Linux-SMP-Systeme noch auf wenige CPUs beschränkt sind. Daher treibt eine gut skalierende Cluster-Lösung die Leistungsfähigkeit von Linux als Datenbank-Server deutlich nach oben. Windows, HP-UX und Solaris werden folgen.
Voraussetzung für den Einsatz von RAC ist das R/3-Kernel-Release 4.6D. Höhere Versionen des Web Application Server (WAS ab 6.20) werden unterstützt werden. Über eine Unterstützung älterer Versionen von R/3, zum Beispiel 3.1, ist noch nicht entschieden.