Drei Jahre hat Oracle an Cache Fusion gearbeitet. Für die neue Cluster-Technologie hat der Softwarehersteller traditionelle Ansätze verworfen und den Mechanismus für die Datensynchronisation neu gestaltet. Das Ergebnis: Wenn die Technologie hält, was Oracle verspricht, dann skalieren Datenbank-Cluster auch dann sehr gut, wenn es zu gemischten Workloads kommt. Diese treten typischerweise dann auf, wenn der Cluster dazu verwendet wird, eine einzelne Anwendung für mehr Benutzer zugänglich zu machen, zum Beispiel eine Verfügbarkeitsprüfung für Produkte auf mehreren Websites.
"Cache Fusion ist eine sehr bedeutende Neuerung für die Oracle-Datenbank", ordnet Günter Stürner, Datenbankexperte bei Oracle, die Technologie ein. Der neue Ansatz basiert darauf, die Caches der verschiedenen Datenbankknoten untereinander zu synchronisieren statt wie bisher über die Festplatten. In einer traditionellen Cluster-Umgebung greifen mehrere Server-Systeme auf ein gemeinsames Festplatten-Array zu. Solange die Daten nicht aktualisiert werden, können sie diese gemeinsam nutzen. Verändert ein Knoten einen bestimmten Datensatz, so reserviert er den entsprechenden Datenbankblock für sich (Lock) und speichert den neuen Inhalt im lokalen Hauptspeicher, dem Cache. Die Verwaltung des verteilten Lockings übernimmt bei Oracle der Lock-Manager DLM.
Will nun ein anderer Knoten auf diesen Block zugreifen, schreibt der Knoten, der die Daten reserviert hat, zunächst die aktualisierte Version auf die Platte zurück. Erst dann können die anderen Knoten im Cluster die entsprechenden Daten (von der Platte) lesen. Durch die damit verbundenen relativ langsamen I/O-Prozesse ist dieser Ablauf langwierig. Wenn es regelmäßig zu solchen "Konflikten" kommt, sinkt die Arbeitsgeschwindigkeit dramatisch.
So arbeitet auch Oracles bisherige Cluster-Technologie, die den Namen "Oracle Parallel Server" (OPS) trägt. Allerdings funktioniert sie nur unzureichend, weiß Henrik Klagges, freier Analyst in München: "Bis heute arbeitet der DLM nur mit zwei bis drei Knoten im Cluster zufriedenstellend."
Cache Fusion geht einen anderen Weg. "Statt über die Festplatte synchronisieren sich die Knoten direkt untereinander", erklärt Stürner. Will ein Knoten auf Daten zugreifen, auf die ein anderer Knoten einen Lock hat, so erhält er den entsprechenden Datenbankblock direkt von diesem, ohne dass die Daten auf der Festplatte aktualisiert werden. In modernen Cluster-Umgebungen mit Hochgeschwindigkeitsverbindungen geht das in der Regel sehr schnell.
"Der kritische Punkt bei einem solchen Ansatz ist der Kommunikationsmechanismus", stellt Stürner klar. Er muss schnell sein. Zwei Punkte sind hierfür von großer Bedeutung: Es dürfen nur wenige Nachrichten bei der Datenaktualisierung ausgetauscht und Anfragen müssen schnell bearbeitet werden. Oracle wird zeigen müssen, dass es einen Kommunikationsmechanismus entwickelt hat, der auch bei vielen Knoten performant arbeitet.
Ein zweites Problem ist der Locking-Mechanismus. Moderne Datenbanken reservieren Datensätze nicht auf Block-, sondern auf Zeilenebene (Row-Level-Locking). Je kleiner die blockierte Einheit, desto mehr Zugriffe können parallel auf eine Datenbank erfolgen. Auch bei Real Application Clusters erfolgt das Locking auf Zeilenebene. Tatsächlich sperrt aber nur der Knoten, der einen Datensatz aktualisiert, diesen auf Zeilenebene. Gegenüber anderen Knoten wird ein Block als in Bearbeitung markiert - aber nicht gelockt. Will ein anderer Knoten Daten aus diesem Bereich verwenden, fällt Kommunikationsaufwand an. Das ist ebenfalls eine Performance-Bremse.
Die neue Technologie bringt also die ein oder andere Unsicherheit mit sich. Daher rät Henrik Klagges den meisten Anwendern von der Cluster-Technologie ab: "OPS und damit auch Cache Fusion sind etwas für Spezialanwender, die absolute Hochverfügbarkeit brauchen und sich die aufwändige Administration eines Clusters zutrauen."
Solche Anforderungen ergeben sich unter anderem bei unternehmenskritischen Programmen wie SAPs R/3. Diese läuft bisher nur mit der normalen Datenbank, zum Beispiel Oracle 8i, zusammen, nicht mit OPS. Der Grund ist die schlechte Skalierbarkeit, deren Urache eben genau in dem gemischten Workload liegt, den eine solche Konfiguration mit sich bringt. Die eigentliche R/3-Anwendung, zum Beispiel eine Finanzbuchhaltung, kann nämlich auf mehrere Rechnersysteme verteilt werden. Diese Applikations-Server greifen aber durcheinander auf beliebige Datensätze zu - und verursachen eine permanente Synchronisation der Caches im Cluster. Mit Real Application Clusters sollte dieses Problem überwunden sein.
Durch Cache Fusion wird auch die Ausfallsicherheit verbessert, da die Störung eines Knotens schnell durch die anderen Rechner im Verbund kompensiert werden kann. Schon nach wenigen Sekunden werden die Benutzerprozesse auf die anderen Knoten verlagert, so dass zumindest lesend wieder auf die Datensätze zugegriffen werden kann.
Hochverfügbarkeit ist in Web-Umgebungen von großer Bedeutung. Auch andere Web-Anforderungen erfüllt der Real Application Cluster, wie gute Skalierbarkeit. Damit passt sich die Technologie in Oracles Strategie ein, die auch die Verbindung von Datenbank und Anwendungs-Server sowie spezielle Caching-Verfahren für Web-Server umfasst. "Wir glauben, 9i ist die komplette Software-Infrastruktur für das Internet", bringt Chuck Rozwat, Oracles Executive Vice President für Server-Technologien, den Ansatz auf den Punkt.
Weitere Neuerungen
- Ein "Personalization" genanntes Zusatzprogramm analysiert die aktuellen und vergangenen Datenanfragen eines Benutzers und prognostiziert, welche Daten als nächstes abgerufen werden könnten. Diese werden dann schon proaktiv von der Datenbank angefordert.
- "Single-sign-on" authentifiziert Benutzer über mehrere Oracle-Datenbanken und -Anwendungen hinweg.
- Mit "Fast-start" führt Oracle zeitbasiertes Recovery ein. Der Administrator kann spezifizieren, wie lang ein Recovery nach einem Systemausfall höchstens dauern darf, bis die Anwender wieder Zugriff auf die Datenbank haben.
- Menschlichen Fehlern beugt "Flashback Query" vor. Mit dieser Funktion lässt sich der Zustand des Datenbanksystems in der Vergangenheit einsehen und gegebenenfalls der Datenstand zu der Zeit wiederherstellen. Damit können Fehler ungeschehen gemacht werden.
- Um geplante Stillstandzeitzeiten zu reduzieren, können eine Reihe von Wartungsarbeiten vorgenommen werden, ohne die Datenbank herunterzufahren. Hierzu gehören das Ändern von Tabellenstrukturen sowie die Erstellung und Reorganisation von Indices.
Besonders sensible Daten können auch in den Datenbanktabellen verschlüsselt abgelegt werden. Diese sind dann auch für Datenbankadministratoren nicht mehr lesbar.BU: Wie zwei Cluster-Knoten sich synchronisieren
Bei Cache Fusion synchronisieren sich zwei Knoten in einem Datenbank-Cluster unter Umgehung der Festplatte. Das Problem der Synchronisation tritt dann auf, wenn ein Knoten (Server 2) auf Daten zugreifen will, die von einem anderen Knoten (Server 1) geändert worden sind. Traditionell werden in einem solchen Fall die Daten auf der Festplatte aktualisiert. Bei Oracle 9i erhält Server 2 die Daten dagegen direkt von Server 1. Quelle: CW