Wiederherstellung von Oracle-Instanzen richtig feinabstimmen

Oracle-Instanzen lassen sich nach einem unerwarteten Herunterfahren problemlos wiederherstellen. Das erfordert allerdings die richtige Abstimmung.

Image goes here

Matthew Morris

Nach einem unerwarteten Herunterfahren kommt es darauf an, Ihren Oracle-Server für den Produktivbetrieb schnell wiederherzustellen. Die Oracle-Architektur ist robust und verhindert den Verlust von bereits festgeschriebenen Transaktionen – außer bei einem Versagen von Speichermedien. In den meisten Fällen ist also garantiert, dass sich die Instanz wiederherstellen lässt. Als Datenbank-Administrator werden Sie aber daran interessiert sein, dass dies möglichst schnell erfolgt. Denn je früher eine Datenbank wieder online ist, desto eher ist Schluss damit, dass Nutzer anrufen, E-Mails schreiben oder vorbeikommen, um zu fragen, wann es endlich so weit ist. An dieser Stelle kommt die richtige Feinabstimmung der Instanz-Wiederherstellung ins Spiel.

Instanz- oder Crash-Wiederherstellung bezeichnet die automatische Anwendung von Einträgen im Redo-Protokoll auf Datenblöcke nach einem Absturz oder Systemversagen. Wenn eine Datenbank sauber beendet wird, wird ein Systemprüfpunkt angelegt, und sämtliche Änderungen im Instanz-Arbeitsspeicher, bei denen dies vorher noch nicht geschehen ist, werden auf der Festplatte gespeichert. Zu diesen Änderungen können auch schon festgeschriebene Transaktionen zählen, die aber noch nicht in den entsprechenden Dateien gespeichert sind. Bei Oracle werden alle Transaktionen synchron in den Puffer des Redo-Logs geschrieben, anschließend folgt die Speicherung in den Online-Logs. Die Redo-Logs können also sowohl festgeschriebene als auch nicht festgeschriebene Transaktionen enthalten. Wenn eine Datenbank dagegen mit der Option Abbrechen heruntergefahren wird, wenn eine einzelne Datenbank-Instanz abstürzt oder alle Instanzen eines Oracle Real Application Cluster, wird kein System-Prüfpunkt erstellt. Weil die Dateien dann nicht festgeschriebene Transaktionen enthalten können, ist beim nächsten Start eine Crash-Wiederherstellung nötig, um die Datenbank konsistent zu machen.

Instanz-Wiederherstellung bei Oracle spielt sich in zwei Schritten ab: zuerst Cache-Wiederherstellung, dann Transaktionswiederherstellung.

Während der Cache-Wiederherstellung (auch als „Rolling Forward“ bezeichnet) wendet Oracle alle festgeschriebenen und nicht festgeschriebenen Änderungen in den Redo-Logdateien auf die betroffenen Datenblöcke an. Die Menge der zu verwendenden Redo-Daten hängt dabei ab von der Häufigkeit von Änderungen in der Datenbank und dem Zeitabstand zwischen Systemprüfpunkten.

Die Transaktionswiederherstellung erfolgt, nachdem alle Änderungen aus den Redo-Logs in den Dateien berücksichtigt sind. Für jegliche zum Zeitpunkt des Absturzes noch nicht festgeschriebenen Transaktionen erfolgt ein Rollback: Die Datenbank verwendet Undo-Informationen, um diese Transaktionen rückgängig zu machen.

Hinsichtlich der Feinabstimmung von Instanz-Wiederherstellung bei Oracle ist der Aspekt der Cache-Recovery entscheidend. Wenn diese beendet ist, kann die Datenbank wieder geöffnet werden. Die Transaktionswiederherstellung kann dann erfolgen, ohne dass die System-Verfügbarkeit beeinträchtigt wird. Also macht alles, das die Cache-Wiederherstellung beschleunigt, die Datenbank schneller wieder verfügbar.

Instanz-Wiederherstellung bei Oracle mittels Prüfpunkten

Beim Anlegen eines Prüfpunktes speichert Oracle die höchste System Change Number (SCN), bis zu der bekannt ist, dass alle Datenblöcke in die Dateien geschrieben wurden. Bei einem Systemversagen ist diese Prüfpunkt-SCN der Ausgangspunkt für die Cache-Wiederherstellung – nur Redo-Einträge mit höheren SCNs müssen berücksichtigt werden. Wie lang die Instanz-Wiederherstellung dauert, hängt davon ab, wie viele Datenblöcke nach dem Prüfpunkt geändert wurden und wie viele Blöcke des Redo-Logs gelesen werden müssen, um diese Änderungen zu lokalisieren. Wenn die Datenbank häufiger Prüfpunkte anlegt, schreibt Oracle öfter „schmutzige“ (dirty) Puffer in die Dateien. Wenn nach einem Instanzversagen eine Cachewiederherstellung ansteht, müssen dann weniger Redo-Blöcke auf die Dateien angewendet werden. Allerdings kann die Performance einer Datenbank leiden, wenn es viele Prüfpunkte in einem System gibt, das häufig aktualisiert wird. Wahrscheinlich ist es auch keine gute Idee, zugunsten von schnellerer Wiederherstellung in Ausnahmefällen auf Performance während des normalen Betriebs zu verzichten.

Das Oracle-Feature Fast-Start Fault Recovery ist darauf ausgelegt, den Zeitaufwand für die Cache-Recovery zu verringern und besser vorhersagbar zu machen, ohne erhebliche Performance-Einbußen in Kauf zu nehmen. Dazu wird die Zahl der schmutzigen Puffer und der Redo-Einträge reduziert, die zwischen dem neusten Redo-Eintrag und dem jüngsten Prüfpunkt generiert werden.

Die übliche Prüfpunkt-Steuerung bei Oracle basiert auf Ereignissen und führt Massen-Schreibvorgänge aus, wenn ein Prüfpunkt entsteht. Mit der Fast-Start-Architektur dagegen gibt es inkrementelle Prüfpunkte. Jeder Database-Writer-Prozess schreibt regelmäßig Puffer auf die Festplatte, um die Prüfpunkt-Position nach vorn zu bringen. Dadurch ergeben sich weniger umfangreiche Prüfpunkte, mit denen sich die beim konventionellen Umgang mit Prüfpunkten üblichen I/O-Spitzen vermeiden lassen. Das Feature wird aktiviert, indem Sie die Initialisierungsparameter FAST_START_MTTR_TARGET auf einen Wert ungleich null setzen. Er gibt die Zahl der Sekunden (0 bis 3.600) an, die es dauern soll, um die Instanz zu starten und eine Cache-Recovery vorzunehmen. Oracle steuert die inkrementellen Prüfpunkte dann so, dass dieses Ziel möglichst erreicht wird.

Erfahren Sie mehr über Business-Software

- GOOGLE-ANZEIGEN

ComputerWeekly.de

Close