Deadlocks

Ein Deadlock entsteht, wenn zwei Anwendungen Daten sperren, die die jeweils andere Anwendung benötigt. Daraufhin kommt es zu einer Situation, in der weder die eine noch die andere Anwendung ihre Ausführung fortsetzen kann.

In Abbildung 1werden beispielsweise zwei Anwendungen gleichzeitig ausgeführt: Anwendung A und Anwendung B. Die erste Transaktion für Anwendung A ist die Aktualisierung der ersten Zeile in Tabelle 1 und die zweite Transaktion die Aktualisierung der zweiten Zeile in Tabelle 2. Anwendung B aktualisiert zuerst die zweite Zeile in Tabelle 2 und dann die erste Zeile in Tabelle 1. Zum Zeitpunkt T1sperrt Anwendung A die erste Zeile in Tabelle 1. Gleichzeitig sperrt Anwendung B die zweite Zeile in Tabelle 2. Zum Zeitpunkt T2fordert Anwendung A eine Sperre für die zweite Zeile in Tabelle 2 an. Gleichzeitig versucht Anwendung B jedoch, die erste Zeile in Tabelle 1 zu sperren. Da Anwendung A ihre Sperre für die erste Zeile in Tabelle 1 erst freigibt, wenn sie eine Aktualisierung für die zweite Zeile in Tabelle 2 abschließen kann, und Anwendung B ihre Sperre für die zweite Zeile in Tabelle 2 erst freigibt, wenn sie eine Aktualisierung für die erste Zeile in Tabelle 1 abschließen kann, tritt ein Deadlock auf. Die Anwendungen warten, bis eine von ihnen ihre Sperre der Daten freigibt.

Abb. 1. Deadlock zwischen Anwendungen
Grafische Darstellung eines Deadlocks zwischen Transaktionen

Da Anwendungen Sperren für Daten, die sie benötigen, nicht von sich aus freigeben, ist ein Detektorprozess erforderlich, der Deadlocks auflöst. Der Deadlock-Detektor überwacht Informationen zu Agenten, die auf Sperren warten, und wird in Intervallen aktiv, die durch den Datenbankkonfigurationsparameter dlchktime angegeben werden.

Wenn der Deadlock-Detektor einen Deadlock ermittelt, definiert er einen der Prozesse im Deadlock nach dem Zufallsprinzip als ausgewählten Prozess, für den ein Rollback durchgeführt werden muss. Der ausgewählte Prozess wird aktiviert und gibt den SQLCODE -911 (SQLSTATE 40001) mit Ursachencode 2 an die aufrufende Anwendung zurück. Der Datenbankmanager macht nicht festgeschriebene Transaktionen aus dem ausgewählten Prozess automatisch rückgängig (ROLLBACK). Wenn die Rollback-Operation beendet ist, werden Sperren, die zu dem ausgewählten Prozess gehörten, freigegeben und die anderen am Deadlock beteiligten Prozesse können fortfahren.

Zur Gewährleistung einer guten Leistung müssen Sie einen geeigneten Wert für den Konfigurationsparameter dlchktime auswählen. Ein zu kurzes Intervall verursacht unnötigen Systemaufwand, ein zu langes Intervall lässt zu, dass Deadlocks eine Weile bestehen bleiben.

In einer Umgebung mit partitionierten Datenbanken wird der Wert für den Konfigurationsparameter dlchktime nur in der Katalogdatenbankpartition angewendet. Wenn eine hohe Zahl Deadlocks auftritt, erhöhen Sie den Wert des Parameters dlchktime, um den Wartezeiten für Sperren und Übertragungen Rechnung zu tragen.

Gehen Sie wie folgt vor, um Deadlocks zu vermeiden, wenn Anwendungen Daten lesen, die sie nachfolgend zu aktualisieren beabsichtigen:
  • Verwenden der Klausel FOR UPDATE bei der Ausführung einer SELECT-Anweisung. Diese Klausel stellt sicher, dass eine U-Sperre aktiviert wird, wenn ein Prozess versucht, Daten zu lesen, und sie lässt Zeilenblockung nicht zu. In einer partitionierten Tabelle werden jedoch alle qualifizierten Zeilen gesperrt, wenn die zu aktualisierenden Spalten den Partitionsschlüssel enthalten.
  • Verwenden der Klauseln WITH RR oder WITH RS und USE AND KEEP UPDATE LOCKS in Abfragen. Diese Klauseln stellen sicher, dass eine U-Sperre aktiviert wird, wenn ein Prozess versucht, Daten zu lesen, und sie lassen Zeilenblockung nicht zu.

In einem System föderierter Datenbanken ist es möglich, dass die von einer Anwendung angeforderten Daten aufgrund eines Deadlocks an einer Datenquelle nicht verfügbar sind. In diesem Fall stützt sich der Db2® -Server auf die Funktionen zur Behandlung von Deadlocks in der Datenquelle. Wenn Deadlocks in mehreren Datenquellen auftreten, ist der DB2-Server für die Auflösung der Deadlocks auf die Zeitlimitmechanismen der Datenquellen angewiesen.

Um weitere Informationen zu Deadlocks zu protokollieren, setzen Sie den Wert des Konfigurationsparameters diaglevel des Datenbankmanagers auf 4. Zu den protokollierten Informationen gehören der Name des gesperrten Objekts, der Sperrmodus und die Anwendung, die die Sperre hält. Der Name der aktuellen dynamischen SQL- und XQuery-Anweisung oder des statischen Pakets kann ebenfalls protokolliert werden.