Optimistisches Locking mit der ORA_ROWSCN

Da ich mir ziemlich sicher bin, gelegentlich wieder danach zu suchen, verlinke ich hier eine Artikelserie von Stew Ashton, die sich mit den Möglichkeiten beschäftigt, die die ORA_ROWSCN bietet, um Transaktionsprobleme zu vermeiden:

• Avoiding Lost Updates with ORA_ROWSCN: zeigt, dass die ORA_ROWSCN als Versionsnummer zur Vermeidung von "lost updates" dienen kann, wenn bestimmte Voraussetzungen erfüllt sind (die Tabelle muss mit rowdependencies erzeugt worden sein, um eine row-genaue Zuordnung der ORA_ROWSCN zu erlauben; das Verfahren funktioniert nicht mit IOTs; vor allem muss in der WHERE-Bedingung des Updates eine Referenzierung zusätzlicher Spalten erfolgen, um Effekte zu berücksichtigen, die beim automatischen internen Restart von Updates entstehen).
• Optimistic Locking: One SCN to rule them all: beschreibt eine API, mit der man Optimistisches Locking unterstützen kann.
• More on Optimistic Locking with ORA_ROWSCN: liefert ergänzende Informationen zum Verhalten des Verfahrens im Kontext der internen Update-Restarts.

Offensichtlich sind meine Kommentare zu den Artikeln nicht besonders erhellend: sie dienen tatsächlich nur dazu, die Links grob einzuordnen.

Lesekonsistenzprobleme mit PL/SQL und Result Cache

Jonathan Lewis hat sich in den letzten Wochen mit einigen Fällen beschäftigt, bei denen die Verwendung des Result Caches oder von mehreren SQL Queries innerhalb einer PL/SQL-Operation Probleme mit der Lesekonsistenz hervorrufen kann:

• Result Cache: liefert das Fazit "Do not mix the pl/sql result cache with database queries. The cache is public but (unlike the buffer cache) it is not guaranteed to give you read-consistency." Im zugehörigen Beispiel wird eine Temporary Table verwendet, für die der Result Cache laut Dokumentation nicht vorgesehen ist, aber die Probleme scheinen nicht auf diesen Fall begrenzt zu sein. Offenbar gibt es in diesem Zusammenhang eine ganze Reihe von Problemen und Bugs - einige entsprechende Fälle hat Sayan Malakshinov in seinem Kommentar verknüpft.
• Result Cache 2: behandelt ein Konsistenzproblem, das sich ergeben kann, wenn man PL/SQL-Funktionen in skalaren Subqueries verwendet. Das vorgestellte Beispiel ist ziemlich komplex und betrifft eine Reporting-Fragestellung und zu den möglichen Workarounds gehören die explizite Setzung einer Tabelle oder eines Tablespaces auf read-only, das Einfrieren der SCN für die Transaktion (read-only) und die Verwendung von deterministischen Funktionen. Ich spare mir die detailliertere Wiedergabe der Ausführungen, aber das Fazit lautet: "The moment you create a PL/SQL function that uses the result cache or deterministic option you have to ensure that nobody uses that function without ensuring that their code has handled the consistency threat properly. It’s too easy to forget, with the passing of time, that certain procedures have to be adopted when particular coding strategies are used."
• Read Consistency: befasst sich mit dem grundsätzlicheren Problem "Any time you execute more than one SQL statement in a PL/SQL procedure the results of executing that procedure may not be self-consistent unless you have explicitly locked your session SCN to a fixed value!!!!!", dass Jonathan Lewis mehrere Ausrufezeichen wert ist - und die sieht man bei ihm sonst sehr selten!! Oracles Standard-Konsistenz-Versprechen ist auf Statement-Ebene beschränkt: wer mehr Konsistenz benötigt - sei es innerhalb einer PL/SQL-Prozedur oder innerhalb eines Berichts auf Basis mehrerer SQL-Queries - muss das passende Isolation-Level wählen. Dazu gibt es ein Code-Beispiel, aber der Fall ist eigentlich auch ohne dieses ziemlich eindeutig.

Ich erhebe keinen Anspruch darauf, die Artikel halbwegs plausibel zusammengefasst zu haben - wie man sieht, habe ich mir sogar das Übersetzen der Kernpunkte weitgehend gespart: mir ging es nur darum die Links zu erfassen, um sie gelegentlich wiederfinden zu können.