Deadlocks in einer DB2-Datenbank

Durch das Anpassen der Datenbank zur Verringerung von Eingabe/Ausgabe-Konkurrenzbetrieb auf der Festplatte können Deadlocks vermindert werden. Es kann jedoch trotzdem vorkommen, dass der Aufruf der gespeicherten Prozedur new_edit_state die aufrufende Anwendung sperrt und alle anderen Benutzer der ArcSDE-Datenbank blockiert.

Stellen Sie sich ein Szenario vor, bei dem der gespeicherte Vorgang eine große Anzahl an Zeilensperren in der Tabelle "STATE_LINEAGES" erfordert, der Grenzwert für die maximale Anzahl an Sperren dadurch überschritten wird und die Eskalation auf eine exklusive Tabellensperre versucht wird. Leider beinhaltet die Abfrage der aufrufenden Anwendung bereits eine gemeinsame Sperre in der Tabelle "STATE_LINEAGES", daher führt dies zu einem Deadlock. Eine stark verzweigte State-Lineage führt zu einer großen Anzahl an Zeilensperren. Dies, zusammen mit einem niedrigen Wert für die Sperrlistengröße, führt mit Sicherheit zu Problemen. In Anbetracht der Behandlung von Sperr-Eskalationen sind auch andere Deadlock-Szenarien vorstellbar.

Das bedeutet letztendlich, dass Deadlocks, je nach Anwendung und Datenbankkonfiguration, nicht selten vorkommen. Beachten Sie nochmals, dass das Problem durch stark verzweigte State-Lineages verschärft werden kann.

IBM DB2 stellt erfreulicherweise Optimierungsparameter zur Verfügung, mit denen die Größe der Sperrliste (LOCKLIST), der Höchstprozentsatz an Sperren in einer Anwendung (MAXLOCKS), die Zeit, die eine Anforderung auf eine Sperre wartet (LOCKTIMEOUT), das Häufigkeitsintervall für die Erkennung von Deadlocks (DLCHKTIME) und das Deadlock-Rollback-Verhalten (DB2LOCK_TO_RB) gesteuert werden können.

Um die Kapazität der Sperrliste bzw. des Grenzwertes für die Sperr-Eskalation zu erhöhen, ändern Sie die Parameter "LOCKLIST" bzw. "MAXLOCKS".

Der Standardwert für LOCKLIST und MAXLOCKS in DB2 9 lautet AUTOMATIC. Dieser Wert aktiviert diese Parameter für die automatische Optimierung. So kann die DB2-Speicheroptimierung die Größe der Speicherressourcen unter verschiedenen Speicherkonsumenten dynamisch aufteilen. Die automatische Optimierung findet nur statt, wenn die automatische Optimierung des Speichers für die Datenbank aktiviert wird (SELF_TUNING_MEM=ON).

Außerdem können Sie die gleichzeitige Ausführung (Parallelität) verbessern, indem Sie Sperren vermeiden. Verwenden Sie dazu die Lock Deferral-Registrierungsvariablen DB2_EVALUNCOMMITED, DB2_SKIPDELETED und DB2_SKIPINSERTED von DB2. Die Registrierungsvariablen ermöglichen es, bei Suchen festgeschriebene Löschungen und Einfügungen zu überspringen.

Standardmäßig setzt ein Sperr-Timeout die Anforderungstransaktion zurück. Um dieses Verhalten so zu verändern, dass nur die Anweisung mit der Sperranforderung zurückgesetzt wird, ändern Sie "DB2LOCK_TO_RB" mit db2set "DB2LOCK_TO_RB=STATEMENT". Das Standardverhalten sollte allerdings für ArcSDE ausreichend sein.

Detaillierte Informationen zur Einstellung dieser Parameter finden Sie in der DB2-Dokumentation oder in den Tuning-Handbüchern. Im Folgenden finden Sie einen Überblick über die Verwendung dieser Parameter.

Erkennen von Sperrproblemen

Einige nützliche Werkzeuge zur Erkennung von Sperrproblemen sind nachstehend aufgeführt.

Parametereinstellungen für den Umgang mit Deadlocks

Um die Einstellungen der Sperrliste anzuzeigen, geben Sie den folgenden Befehl ein:

db2 get db cfg

Nachfolgend finden Sie ein Beispiel für die Informationen, die als Ergebnis der Ausgabe dieses Befehls zurückgegeben werden.

Max storage for lock list (4KB)		(LOCKLIST) = 50
Interval for checking deadlock (ms)	(DLCHKTIME) = 10000
Percent. of lock lists per application	(MAXLOCKS) = 22
Lock time out (sec)			(LOCKTIMEOUT) = -1
Max number of active applications	(MAXAPPLS) = AUTOMATIC

Details zum Festlegen dieser Parameter finden Sie im IBM DB2 Infocenter.


3/6/2012