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 new_edit_state-gespeicherte Vorgangsaufruf die aufrufende Anwendung sperrt und alle anderen Benutzer der Geodatabase blockiert.

Stellen Sie sich ein Szenario vor, bei dem die gespeicherte Prozedur 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. Auch in diesem Fall kann das Problem durch stark verzweigte State-Lineages verschärft werden.

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" 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. Das Standardverhalten sollte für Geodatabases in Db2 ausreichend sein.

Detaillierte Informationen zur Einstellung dieser Parameter finden Sie in der Db2-Dokumentation im IBM Knowledge Center.

Der folgende Abschnitt enthält einige Tipps zum Diagnostizieren von Deadlocks.

Diagnostizieren von Sperrproblemen

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

• Suchen Sie DB2-Anwendungs-IDs für ArcGIS-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)