Wer wird der Loser bei -911 REASON 00C90088 ???
- Dieses Thema hat 2 Antworten und 1 Teilnehmer, und wurde zuletzt aktualisiert vor 15 Jahre, 10 Monaten von
Anonym.
-
AuthorPosts
-
29. November 2007 um 7:23 Uhr #2815
AnonymInaktivHallo zusammen,
ich habe eine Frage zu einer deadlock Situation.
Wir haben etliche -911, deren Ursache wir bereits kennen und die wir durch Änderung im Source-code abstellen werden.
Es geht um eine Tabelle, die Schlüssel verwaltet und über die alle Transaktionen die neue Schlüssel benötigen drüber müssen.Die Tabelle verwaltet den höchsten Schlüssel für Typ-A und Typ-B.
Transaktion 1 hat Schlüssel vom Typ-A angefordert und per UPDATE diesen Eintrag gesperrt. Jetzt wird ein Schlüssel vom Typ-B benötigt.
Transaktion 2 hat Schlüssel vom Typ-B angefordert und per UPDATE diesen Eintrag gesperrt. Jetzt wird ein Schlüssel vom Typ-A benötigt.
Im -911 ist immer die Page/Row mit Eintrag vom Typ-A die Resource, die im DB2-Master ausgewiesen wird.
Wir planen eine Änderung die bei allen Transaktionen immer dazu führt das erst alle Schlüssel vom Typ-A angefordert werden und dann alle Schlüssel vom Typ-B. Dadurch sollten sich nach unserer Hoffnung die Transaktionen auf dieser Nadelöhrtabelle serialisieren.
Jetzt aber zur Frage:
Warum ist immer Transaktion-2 der Verlierer in der Deadlock-Situation und nicht manchmal Transaktion-1?
Welche Regeln wendet DB2 an um den Verlierer und den Gewinner bei einer Deadlock-Situation auszuwählen?
Möglichkeiten die ich theoretisch sehe:
Derjenige der einen aufwendigen ROLLBACK bräuchte wird bevorteilt. (Zielsetzung weniger Arbeit beim Rollback und folgendem Restart)
Derjenige der höhere Priorität hat (Online gewinnt gegen Batch)
etc.
Welches Hintergrundwissen habt ihr?
Gibt es Informationen/Links im Internet zu demThema?
Gibt es offizielle Literatur dazu?Danke für eure Bemühungen im Voraus
Klaus Rottenbacher
29. November 2007 um 13:50 Uhr #3193
AnonymInaktivsoviel ich weiss, wird die UOW mit den meisten Locks gekicked.
( wenn es nämlich mehr als zwei Beteiligte gibt, ist damit die Chance am grössten, dass sich die Situation bereinigt )
2. Dezember 2007 um 22:48 Uhr #3442
AnonymInaktivHallo,
falls noch nicht bekannt, es steht im Chapter 18 – Planning for Concurrency des Aplication Programming und SQL Guide (http://www-306.ibm.com/software/data/db2/zos/v8books.html) einiges zu Locks etc.
Sonst fällt mir Row Level Locking ein, ist aber bestimmt schon bei dem TS eingeschaltet.Viele Gruesse
Juergen Jost
-
AuthorPosts
You must be logged in to reply to this topic.