RAC Features Teil II:

Recovery mit Oracle RAC 9i „Fast Reconfiguration"

In der letzten Ausgabe der ORDIX News haben wir RAC und die neue Cache Fusion Architektur vorgestellt. In diesem Artikel werden die Vorteile der neuen Architektur auf das Thema Recovery ausgeweitet. Durch die einfachere Verwaltung der Ressourcen und Sperren durch RAC wird das Instance Recovery wesentlich schneller.

Ein Problem ist, dass der Ausfall einer Instance dazu führt, dass die überlebende Instance eine Reconfiguration durchführen muss, um die Ressourcen der ausgefallenen Instance sauber zu übernehmen bzw. zu beenden. Das kann bei 8i recht lange dauern und mit „lange" ist hier unter Umständen ein ca. 20-minütiger „Hänger" der überlebenden Instance gemeint. Für eine Hochverfügbarkeitskonfiguration schon eine sehr „unpässliche" Zeit.

Durch die neue Architektur und auch einige neue Mechanismen bei RAC wird diese Zeit stark verkürzt, was unter dem Aspekt der Hochverfügbarkeit besonders interessant ist.

Reconfiguration bei einer 8i OPS Datenbank

Für OPS werden explizit Ressourcen und Locks konfiguriert, um offene Transaktionen entsprechend zu verwalten. Eine Reconfiguration dieser Ressourcen findet statt, wenn eine Instance

• in das Cluster mit aufgenommen wird
• aus dem Cluster herausgeht
• ein Knoten des Clusters heruntergefahren wird.

Wie erwähnt, führt der Ausfall einer Instance dazu, dass alle „open global locks/ressources" der ausgefallenen Instance gelöscht werden und auf die überlebenden Instances verteilt werden (ein sogenanntes „lock remastering").

In dieser Zeit können auf den überlebenden Instances keine Transaktionen durchgeführt werden, da die Datenbank im „eingefrorenen" Zustand ist (freeze_db_for_fast_instance_recovery = true).

Die entsprechende Zeit für eine solche Reconfiguration hängt von der Größe der Instance ab, d. h. wie viele SW- und HW-Ressourcen genutzt wurden, wie viel SGA konfiguriert wurde, etc. Somit dauert die Reconfiguration-Zeit bei einer DB mit einer SGA von ca. 1GB, lm_ress = 245638, lm_locks = 258235 schon mal 20 Minuten, so dass die überlebende Instance für die Applikation in der Zeit hängt.

Die „lm_"-Parameter wurden hier schon auf die Optimierung der Recoveryzeit angepasst (im Sinne von „heruntergesetzt"). Nebenbei sei bemerkt, dass die Nutzung von „fixed locks" die Zeiten noch mehr verlängert.

Fast Reconfiguration unter RAC - Unter 9i soll dies nun schneller gehen!

Zum einen gibt es ein 2 Phasen Recovery für das Instance Recovery, das die Redologs entsprechend durcharbeitet. Hierdurch können Distributed Lock Management und Recovery parallelisiert werden.

Betrachtet man zum anderen die RAC-Architektur, so wurde durch die Parallelisierung einiger Prozesse eine entsprechende Grundlage für die Verbesserung geschaffen. Allein der Wegfall der fixen Sperren („fixed locks") beschleunigt den Vorgang der Reconfiguration, da diese nicht mehr explizit allokiert werden müssen.

Des weiteren wurde das Remastering aller locks und Ressourcen auf die überlebenden Instances abgeschafft und stattdessen ein sogenanntes „lazy remastering" genutzt. Hier werden nur die Ressourcen der ausgefallenen Instance und die minimal notwendigen Ressourcen der überlebenden Instance während der Reconfiguration aufgeräumt.

Mit diesem Konzept behalten die Instances die meisten Ressourcen während der Reconfiguration, was in den vorhergehenden Versionen von Oracle nicht der Fall war. Bislang wurden alle Ressourcen aller Instances gelöscht.

Aufgrund dieses Konzeptes können viele Prozesse die Arbeit wieder aufnehmen, während die Reconfiguration läuft, da ihre Ressourcen und Sperren nicht gelöscht wurden.

Vereinfachung der Reconfiguration und des Recoveries

Während der Laufzeit entscheidet RAC für eine Sperre oder Ressource, welcher Knoten sie recovert. Dies wird abhängig von der Zugriffshäufigkeit der Knoten auf die Ressource gemacht.

2 Phasen Recovery

Durch die mit Version 9 eingeführten „Past images" in den Remote Buffer Caches (vgl. Artikel "RAC Features Teil I", ORDIX News 2/2002), wurde auch das Recovery optimiert.

Des weiteren wird das Recovery nicht mehr von einem expliziten Prozess durchgeführt, sondern durch den SMON Prozess einer überlebenden Instance.

Was geschieht nun beim Ausfall einer Instance?

• Der Ausfall wird zunächst vom Cluster Manager festgestellt. Lokale SQLs auf den überlebenden Instances sind noch möglich.
• Die Reconfiguration startet und alle Sperren der gestorbenen Instance werden „remastered". Die Redo-Threads der gestorbenen Instance werden das erste Mal vom SMON gelesen (Phase 1) und die Recovery Sets werden gebildet. SQL's sind nicht möglich.
• Der SMON Prozess fordert die Sperren an, die er zum Recovery der Blöcke braucht, die er im ersten Leselauf gefunden hat.
• Die Sperren werden zugeteilt und der zweite Leselauf der Redos startet (Phase 2). Die notwendigen Ressourcen (GCS Ressourcen, PI-Blöcke) werden allokiert und verfügbar, sobald sie (blockweise) recovered wurden.
• Der SMON bringt die Redos entsprechend der SCN zusammen, um zunächst die richtige Reihenfolge der Änderungen sicherzustellen. Der SMON findet auch die BWR's in den Redos, um Einträge zu löschen, die für das Recovery nicht mehr gebraucht werden, da sie bereits auf die Platte geschrieben wurden. Ergebnis des ersten Redo Leselaufs ist ein Recovery Set, das nur die von der gestorbenen Instance modifizierten Blöcke beinhaltet.
• Die Einträge in der Recovery Liste werden durch die SCN sortiert, um die Reihenfolge der angeforderten Instance-Sperren für das Recovery festzulegen. Der SMON informiert nun die Master Instances der entsprechenden Sperr-Elemente, so dass diese jeden Block der Recovery Liste und die zugehörigen Sperren für das Recovery übernehmen.
• Danach hat die "Recovery Instance" Sperren auf jeden Block des Recovery Sets. Solange das Recovery nicht fertig ist, haben andere Instances keinen Zugriff auf diese Sperren. Nun startet der zweite Leselauf über die Redos und die Redo Zuweisung beginnt. Die Redoeinträge werden wieder entsprechend der SCN zusammengefügt und die Einträge werden den Datafiles zugeordnet. Der Lauf wird zweimal durchgeführt. Blockweise werden die Rollforwards bzw. Rollbacks durchgeführt und die Blöcke werden anschließend freigegeben.

Vor allem das 2 Phasen Konzept wirkt sich auch bei einem 2-Knoten RAC auf die Performance des Instance Recoveries aus. Die oben genannten Architekturvorteile (Zuweisung der Ressourcen auf die Knoten, die sie am meisten genutzt haben) wirken sich natürlich eher auf Cluster aus, die mehr als 2 Knoten besitzen.

Christoph Lafeld (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen