Durch die Wiederherstellung nach einem Systemabsturz mit Hilfe des Befehls RESTART DATABASE oder des Konfigurationsparameters zur Aktivierung des automatischen Neustarts (autorestart) wird verhindert, daß die Datenbank in einem inkonsistenten oder unbrauchbaren Status verbleibt.
Unter den folgenden Themen finden Sie weitere Informationen:
Datenbankbefehle und Anwendungen können aus verschiedenen Gründen fehlschlagen. Ein Transaktionsfehler ist nicht der Fehler einer Datenbankaktion, der durch einen falschen Parameterwert, einen überschrittenen Grenzwert oder eine ROLLBACK-Operation aufgrund gegenseitiger Sperren verursacht wird. Es handelt sich vielmehr um einen schwerwiegenden Fehler bzw. eine Bedingung, die zur abnormalen Beendigung der Datenbank bzw. des Datenbankmanagers führt und eine Wiederherstellung der Datenbank erforderlich macht. Beispiele hierfür sind Ereignisse wie Stromausfall bei einer Maschine (der zum Absturz des Datenbankmanagers und der Datenbankpartitionen führt) oder ein Fehler bei einer COMMIT/ROLLBACK-Operation, die den Absturz der Datenbank verursacht, weil die Platte mit den Datenbankprotokollen voll ist und keine weiteren Protokolldateien zum Schreiben des COMMIT/ROLLBACK-Datensatzes zugeordnet werden können.
Tritt ein Stromausfall oder Anwendungsfehler auf, während Anwendungen oder Befehle für eine Datenbank ausgeführt werden, kann dies eine unmittelbare Beendigung oder Unterbrechung aller Datenbankaktivitäten zur Folge haben. Eine oder mehrere Anwendungen bzw. Befehle haben eventuell angefangen, mit den Daten in der Datenbank zu arbeiten, wurden jedoch nicht beendet. Zudem wurden einige festgeschriebene Arbeitseinheiten eventuell nicht auf die Platte geschrieben. Durch die teilweise beendeten (bzw. nicht geschriebenen) Arbeitseinheiten verbleibt die Datenbank in einem inkonsistenten, d. h. unbrauchbaren, Status.
Unter den folgenden Themen finden Sie weitere Informationen:
Sie müssen nur entscheiden, ob der Datenbankmanager nach einem Fehler für die unvollständigen Arbeitseinheiten automatisch eine ROLLBACK-Operation ausführen soll. Wenn Sie dies wünschen, müssen Sie dazu den Konfigurationsparameter für den automatischen Wiederanlauf (autorestart) aktivieren, indem Sie diesen auf "ON" (EIN) setzen. (Dies ist die Standardeinstellung.) Andernfalls sollten Sie den Befehl RESTART DATABASE eingeben, wenn ein Datenbankfehler auftritt.
Anmerkung: | Wurde der automatische Wiederanlauf aktiviert, wird nach einem Datenbankfehler automatisch ein Wiederanlauf eingeleitet. Diese Prozedur nimmt möglicherweise einige Zeit in Anspruch, so daß fälschlicherweise der Eindruck entstehen kann, daß die Datenbank blockiert oder nicht mehr auf Benutzereingaben reagiert. Der Wiederanlauf einer Datenbank wird in der Datei db2diag.log aufgezeichnet. Wenn Sie jederzeit über den aktuellen Systemstatus informiert sein und sichergehen wollen, daß die Datenbank auf Benutzereingaben reagiert, sollte die Funktion für den automatischen Wiederanlauf inaktiviert werden. |
Der automatische Neustart wird mit dem Datenbankkonfigurationsparameter autorestart aktiviert. Standardmäßig ist dieser Parameter so eingestellt, daß der automatische Neustart aktiviert ("on") ist. Weitere Informationen zu diesem Parameter finden Sie in Kapitel 32, Konfigurieren von DB2.
In der Regel ist eine Datenbankwiederherstellung sowohl auf dem ausgefallenen Datenbankpartitions-Server als auch auf jedem anderen Datenbankpartitions-Server erforderlich, der an derselben Transaktion oder Anwendung beteiligt war. Die Wiederherstellung der Datenbank auf dem ausgefallenen Datenbankpartitions-Server wird häufig als Wiederherstellung nach einem Systemabsturz bezeichnet. Die Wiederherstellung nach einem Systemabsturz erfolgt auf dem abgestürzten Datenbankpartitions-Server, nachdem die Ursache des Fehlers behoben wurde (z. B. die Stromversorgung wiederhergestellt wurde). Die Datenbankwiederherstellung auf den anderen (weiterhin aktiven) Datenbankpartitions-Servern erfolgt unmittelbar nach Feststellung des Fehlers. Bei diesem Prozeß, der manchmal als Wiederherstellung nach Datenbankpartitionsfehler bezeichnet wird, werden Ressourcen für die fehlgeschlagene Transaktion oder Anwendung transparent bereinigt.
Weitere Informationen finden Sie in den Abschnitten Wiederherstellung auf einem aktiven Datenbankpartitions-Server nach Transaktionsfehler und Wiederherstellung nach Transaktionsfehler auf dem ausgefallenen Datenbankpartitions-Server.
Die Diskussion des Protokolls zur zweiphasigen Festschreibung dient hier zur Einführung in die Wiederherstellung nach einem Systemabsturz in einem partitionierten Datenbanksystem. Weitere Informationen zum zweiphasigen Festschreiben finden Sie in Prozeß der zweiphasigen Festschreibung.
In einer partitionierten Datenbankumgebung ist der Datenbankpartitions-Server, auf dem die Anwendung übergeben wird, der Koordinatorknoten und der erste Agent, der für die Anwendung aktiv wird, der koordinierende Agent. Der koordinierende Agent ist für die Verteilung der Arbeit auf andere Datenbankpartitions-Server verantwortlich und protokolliert, welche an der Transaktion beteiligt sind. Wenn die Anwendung eine COMMIT-Operation für eine Transaktion ausführt, schreibt der koordinierende Agent die Transaktion mit Hilfe des Protokolls zur zweiphasigen Festschreibung fest. In der ersten Phase sendet der Koordinatorknoten eine PREPARE-Anforderung an alle anderen an der Transaktion beteiligten Datenbankpartitions-Server. Die Server antworten daraufhin wie folgt:
Wenn einer der Server mit "NO" antwortet, wird die Transaktion rückgängig gemacht. Andernfalls beginnt der Koordinatorknoten mit der zweiten Phase.
In der zweiten Phase schreibt der Koordinatorknoten einen COMMIT-Protokollsatz und sendet anschließend eine COMMIT-Anforderung an alle Server, mit "YES" geantwortet haben. Wenn alle anderen Datenbankpartitions-Server die COMMIT-Operation ausgeführt haben, senden sie eine Bestätigung der Festschreibung an den Koordinatorknoten. Die Transaktion ist abgeschlossen, wenn der Koordinatoragent von allen beteiligten Servern die COMMIT-Bestätigungen empfangen hat. Wenn dies der Fall ist, schreibt der koordinierende Agent einen FORGET-Protokollsatz.
Wenn ein Datenbankpartitions-Server feststellt, daß ein anderer Server abgestürzt ist, werden alle Arbeiten, an denen der ausgefallene Datenbankpartitions-Server beteiligt ist, gestoppt:
Im Abschnitt Beheben von Problemen bei der zweiphasigen Festschreibung finden Sie weitere Informationen zur Auflösung einer unbestätigten Transaktion.
Jeder Prozeß (wie z. B. ein Agent oder ein Detektor für gegenseitiges Sperren), der versucht, eine Anforderung an den ausgefallenen Server zu senden, wird informiert, daß er die Anforderung nicht senden kann.
Wenn der Fehler zu einer abnormalen Beendigung des Datenbankmanagers führte, können Sie, wenn der Prozessor wieder gestartet wird, den Befehl DB2START mit der Option RESTART ausführen, um den Datenbankmanager erneut zu starten. Wenn Sie den Prozessor nicht wieder starten können, können Sie den Befehl DB2START auch auf einem anderen Prozessor zum erneuten Starten des Datenbankmanagers verwenden. Weitere Informationen finden Sie in den Abschnitten zum Befehl START DATABASE MANAGER oder zur API im Handbuch Command Reference bzw. Administrative API Reference.
Durch eine abnormale Beendigung können Datenbankpartitionen auf dem Server in einem inkonsistenten Status verbleiben (d. h., daß sie nicht verwendbar sind). Um sie wieder verwendbar zu machen, muß eine Wiederherstellung nach einem Systemabsturz durchgeführt werden, damit sie wieder konsistent werden. Eine Wiederherstellung nach einem Systemabsturz kann auf einem Datenbankpartitions-Server wie folgt ausgelöst werden:
Bei der Wiederherstellung nach einem Systemabsturz werden die Protokollsätze in den aktiven Protokolldateien erneut angewandt, um sicherzustellen, daß die Ergebnisse aller vollständigen Transaktionen in der Datenbank vorhanden sind. Nachdem alle Änderungen wieder angewandt wurden, werden alle nicht festgeschriebenen Transaktionen außer unbestätigten Transaktionen lokal rückgängig gemacht. In einer partitionierten Datenbankumgebung gibt es zwei Arten unbestätigter Transaktionen:
Bei der Wiederherstellung nach einem Systemabsturz wird versucht, alle unbestätigten Transaktionen durch eine der folgenden Aktionen aufzulösen. Die durchgeführte Aktion ist davon abhängig, ob der Datenbankpartitions-Server der Koordinatorknoten für eine Anwendung war:
Es ist möglich, daß durch eine Wiederherstellung nach einem Systemabsturz nicht alle unbestätigten Transaktionen aufgelöst werden können (z. B., wenn einige der Datenbankpartitions-Server nicht verfügbar sind). In diesem Fall wird die SQL-Warnung SQL1061W zurückgegeben. Sie sollten beachten, daß unbestätigte Transaktionen Ressourcen wie Sperren und Speicherbereich für aktive Protokolle beanspruchen. Es ist möglich, daß ein Punkt erreicht wird, an dem keine Änderungen an der Datenbank mehr durchgeführt werden können, weil der Speicherbereich für die aktiven Protokolldateien durch unbestätigte Transaktionen belegt ist. Aus diesem Grund sollten Sie nach einer Wiederherstellung nach einem Systemabsturz feststellen, ob unbestätigte Transaktionen verblieben sind, und alle Datenbankpartitions-Server, die zur Auflösung der unbestätigten Transaktionen erforderlich sind, so schnell wie möglich wieder verfügbar zu machen.
Wenn einer oder mehrere Server, die zur Auflösung einer unbestätigten Transaktion benötigt werden, nicht rechtzeitig wieder verfügbar gemacht werden können, und der Zugriff auf Datenbankpartitionen auf anderen Servern erforderlich ist, können Sie die unbestätigte Transaktion durch eine heuristische Entscheidung manuell auflösen. Mit Hilfe des Befehls LIST INDOUBT TRANSACTIONS können Sie die unbestätigte Transaktion auf dem Server abfragen, festschreiben oder rückgängig machen. Weitere Informationen finden Sie in den Abschnitten zum Befehl LIST INDOUBT TRANSACTIONS bzw. zur API im Handbuch Command Reference bzw. Administrative API Reference.
Anmerkung: | Der Befehl LIST INDOUBT TRANSACTIONS wird auch für Transaktionen in einer
verteilten Transaktionsumgebung verwendet. Zur Unterscheidung zwischen
den beiden Arten unbestätigter Transaktionen enthält das Feld für die Quelle
("Originator") in der Ausgabe des Befehls LIST INDOUBT TRANSACTIONS eine
der folgenden Angaben:
|
Informationen zu verteilten Umgebungen finden Sie in Kapitel 9, Entwerfen verteilter Datenbanken und in Kapitel 10, Entwerfen für Transaktionsmanager.
Wenn ein Datenbankpartitions-Server ausfällt, empfängt die Anwendung normalerweise einen der folgenden SQLCODEs. Die Methode zur Erkennung, welcher Datenbankmanager ausgefallen ist, hängt vom empfangenen SQLCODE ab:
Welcher Datenbankpartitions-Server ausgefallen ist, kann in zwei Schritten festgestellt werden. Der SQL-Kommunikationsbereich, der zum SQLCODE SQL1229N gehört, enthält die Knotennummer des Servers, der den Fehler erkannte, in der sechsten Feldposition des Felds sqlerrd. (Die Knotennummer, die für den Server geschrieben wird, entspricht der Knotennummer in der Datei db2nodes.cfg.) Auf dem Datenbankpartitions-Server, der den Fehler feststellt, wird eine Nachricht, die die Knotennummer des ausgefallenen Servers angibt, in die Datei db2diag.log geschrieben.
Anmerkung: | Wenn mehrere logische Knoten auf einem Prozessor verwendet werden, kann der Ausfall eines logischen Knotens den Ausfall anderer logischer Knoten auf demselben Prozessor verursachen. |
In der Regel wird ein Datenbankpartitions-Server nach einem Ausfall wie folgt wieder verfügbar gemacht: