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.

• Suchen Sie DB2-Anwendungs-IDs für SDE-Prozesse.

  SELECT  appl_id 
  FROM  TABLE(SNAPSHOT_APPL_INFO('SDE',-1)) 
  AS SNAPSHOT_APPL_INFO 
  WHERE appl_name LIKE 'gsrvr%'
  
  SELECT  appl_id,appl_name 
  FROM  TABLE(SNAPSHOT_APPL_INFO('SDE',-1)) 

• Verwenden Sie Snapshots für Sperr- und Anwendungsinformationen, z. B.:

  db2 get snapshot for locks on sde > all_locks.txt
  
  db2 get snapshot for locks for application applid
  '*LOCAL.DB2.00AB42215335' > app_locks.txt
  
  db2 get snapshot for application applid '*LOCAL.DB2.00AB42215335' > app_info.txt

  Eine schnelle Suche in der Snapshot-Ausgabe nach interessanten Elementen führt zu Folgendem:

  Application status = Lock-wait
   Locks held by application = 1254
   Number of SQL requests since last commit = 12
   Open local cursors = 1
   Most recent operation = Execute
  
   Object type	= Table
   Tablespace name	= USERSPACE1
   Table schema	= SDE
   Table name	= STATE_LINEAGES
   Mode = X
   Status	 = Converting
   Current mode = IX
   Lock escalation	= YES

• Wie bereits erwähnt, können stark verzweigte Lineages problematisch sein, da sie eine große Anzahl an Zeilensperren erfordern. Mit den folgenden SQL-Anweisungen kann eine schnelle Überprüfung der Lineage-Verzweigungen und der maximalen Lineage-Verzweigung erfolgen:

  SELECT COUNT (*) 
  FROM state_lineages 
  GROUP BY lineage_name
  
  SELECT MAX(a.depth) 
  FROM (SELECT COUNT (*) FROM state_lineages GROUP BY lineage_name) a(depth)

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.