Forum

Hallo Ulrich,

danke für deine Hinweise.

zu a)

Das sollte gehen, allerdings müssen wir alle Programme ändern, die in die Protokolltabelle schreiben. Außerdem würden diese Programme sich dann serialisieren, da ja alle eine EXCLUSIVE LOCK wollen. Das würde unsere Protokolltabelle zum Nadelöhr machen!

zu b) Verstehe ich nicht ganz. Die Programme wollen nur INSERT machen und ihre eigenen Aktivitäten protokollieren. Was sollen sie nach deinem Vorschlag mit Repeatable Read lesen?

Wir haben in der zwischenzeit ein Testszenarion aufgebaut.

Task 1 ==> 1000 mal INSERT von ROW1 + ROW2 + COMMIT die zu einer LUW gehören (Das ganze in einem ersten DSNTEP2-Job verpackt)

Task 2 ==> 1000 mal LOCK in SHARE MODE + INSERT CURRENT TIMESTAMP in Hilfstabelle + COMMIT (Das ganze in einem zweiten DSNTEP2-Job verpackt)

Beide Jobs parallel gestartet. Läuft ca. 10 Sekunden.

Danach suchen wir mit einem SQL nach Problem-Transaktionen bei denen

TS ROW1 < LOCK-TS (aus Hilfstabelle)
TS ROW2 > LOCK-TS (aus Hilfstabelle)
und ROW1 gehört zur gleichen Transaktion wie ROW2

Wir finden immer zwischen 8-20 fehlerhaften Fällen!

Jetzt haben wir testweise Task2 mal geändert:

statt CURRENT TIMESTAMP
machen wir jetzt
SELECT MAX(TS) + 1 MICROSECOND FROM XYZ
und INSERTen den in unsere Hilfstabelle.

Resultat: Keine Fehlerfälle mehr vorhanden.

Bei der Erklärung wird es (für uns) schwierig!

Entweder produziert unser Test nicht genügend Last und der Fehler ist nur unwahrscheinlicher geworden und tritt daher nicht mehr auf.

Oder wir haben die DB2-Aktivitäten, die hier im Detail ablaufen, immer noch nicht verstanden.

Warum tritt der Fehler nach eurer Meinung jetzt nicht mehr auf?

Gruß Klaus