View Full Version : Exception Handling bei Satzsperre in SQLRPGLE
Wobei der Select RRN ganz schön dauert, da hier grundsätzlich kein Index verwendet wird. Eine schnelle und vor allem gute Lösung ist das nicht.
Das Stimmt nicht, Indexe werden auch zur Ermittlung von RRN() verwendet.
Wenn du einen
select ... where rrn() = 1234
verwendest, kann SQL keinen Index verwenden, da es keinen Index über RRN gibt.
Schränkst du natürlich auf weitere Schlüssel ein, werden für diese natürlich Indizees verwendet.
Wenn du einen
select ... where rrn() = 1234
verwendest, kann SQL keinen Index verwenden, da es keinen Index über RRN gibt.
Schränkst du natürlich auf weitere Schlüssel ein, werden für diese natürlich Indizees verwendet.
Es ging ja in dem Beitrag davor darum, die relative Satznummer zu ermitteln und Du hattes geschrieben, es würde sehr lange dauern.
Die Ermittlung geht durch einen entsprechenden Index sehr schnell und ich denke, das der Zugriff bzw. die Auswahl über relative Satznummer auch sehr schnell geht.
Die von dabeda angegeben Methode mittels QDBRRCDL nutzt ich übrigens für Java, um auf der Java-Oberfläche den zu blockierenden Benutzer anzeigen zu können. Das geht sehr fix.
Dazum muss ich aber grundsätzlich den Schlüssel mit abfragen um einen Index zu benutzen.
@Baldur
Was ich mich allerdings frage, wieso der SELECT gesperrte Sätze nicht liest ?
Einen Fehler gibts eigentlich erst beim UPDATE/DELETE oder der gesperrte Satz wird einfach überlesen.
Wird ein Cursor definiert und ein Update oder Delete mit WHERE CURRENT OF, wird i.d.R. nur ein einziger ODP (open data path) verwendet. Damit muss die Sperre bereits beim Fetch und nicht erst beim Update erfolgen.
(... genau wie beim native I/O in Update Dateien)
Wird ein Cursor definiert und z.B. die relative Satz-Nr. oder der unique Key zurückgebracht und der anschließende Update entweder über die relative Satz-Nr. oder den unique Key gemacht, werden 2 ODPs generiert (und damit natürlich auch 2 FULL OPENS ausgeführt). In diesem Fall erfolgt die Satz-Sperre erst beim Update.
(... man liest mit native I/O die Input-Datei ein und macht den Update auf die (gleiche) Update-Datei)
Birgitta
... das hat mit den ODPs allenfalls mittelbar zu tun, sondern hängt davon ab welche Art von Sperre angefordert wird und welche Art von Sperre der Satz gegenwärtig hat. Das kann unter commit alles ein wenig anders aussehen...
D*B
@Baldur
Wird ein Cursor definiert und ein Update oder Delete mit WHERE CURRENT OF, wird i.d.R. nur ein einziger ODP (open data path) verwendet. Damit muss die Sperre bereits beim Fetch und nicht erst beim Update erfolgen.
(... genau wie beim native I/O in Update Dateien)
Wird ein Cursor definiert und z.B. die relative Satz-Nr. oder der unique Key zurückgebracht und der anschließende Update entweder über die relative Satz-Nr. oder den unique Key gemacht, werden 2 ODPs generiert (und damit natürlich auch 2 FULL OPENS ausgeführt). In diesem Fall erfolgt die Satz-Sperre erst beim Update.
(... man liest mit native I/O die Input-Datei ein und macht den Update auf die (gleiche) Update-Datei)
Birgitta
... das hat mit den ODPs allenfalls mittelbar zu tun, sondern hängt davon ab welche Art von Sperre angefordert wird und welche Art von Sperre der Satz gegenwärtig hat. Das kann unter commit alles ein wenig anders aussehen...
Kann ich mir eigentlich nicht vorstellen, vielleicht bei den hohen Commit Leveln, bei denen der READ/FETCH gelockt wird. Aber da stellt ich die Frage, ob der Satz beim Fetch überhaupt gelesen werden kann oder nicht. Bei den niederen Commit Leveln z.B. *UR (Uncommitted Read) oder *CS (Cursor Stability) funktioniert es genau so wie ich es beschrieben habe.
Es soll übrigens Leute geben, die grundsätzlich mit Journaling und Commitment Control arbeiten ;)
Birgitta
Birgitta
... das ist auch bei RLA unter Commit schon anders!
nach dem read (bei open for update) kann ein zweiter noch lesen, aber nicht mehr schreiben
- schreibt einer unter commit, hält er die Sperre bis zum Ende der Transaktion, jetzt kann ein zweiter schon nicht mehr lesen.
- unter Commit hängt das dann noch von der Commitstufe ab, da werden bei repeatable read bereits beim lesen schon Sperren gesetzt und gehalten, bei read committed werden gesperrte Sätze überlesen, bei read uncommited wird gewartet, bei serializable werden table locks gesetzt, die den open for update von rla schon wechselseitig ausschließen...
D*B
Kann ich mir eigentlich nicht vorstellen, vielleicht bei den hohen Commit Leveln, bei denen der READ/FETCH gelockt wird. Aber da stellt ich die Frage, ob der Satz beim Fetch überhaupt gelesen werden kann oder nicht. Bei den niederen Commit Leveln z.B. *UR (Uncommitted Read) oder *CS (Cursor Stability) funktioniert es genau so wie ich es beschrieben habe.
Es soll übrigens Leute geben, die grundsätzlich mit Journaling und Commitment Control arbeiten ;)
Birgitta
Birgitta