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.