Freitag, Juli 20, 2018

Semantik der Informationen im SQL Monitor

Mohamed Houri untersucht in einer kleinen Artikelserie die Semantik der Angaben des SQL Monitor:
  • ASH, SQL Monitor and Extended trace: untersucht die Angaben zur Fetch-Phase durch Vergleich mit den Aussagen von ASH und SQL Trace und stellt fest, dass diese Phase in der "Elapsed Time" Angabe des "Global Stats" Abschnitts nicht berücksichtigt wird. Eine plausiblere Aussage hinsichtlich der vollständigen Laufzeit liefert "Duration" im Abschnitt "Global Information", was bereits Nenad Noveljic in einem grundlegenden Artikel erläutert hatte.
  • SQL Monitor and parsing: betrachtet die Behandlung des Parsings und weist darauf hin, dass nur die Execution Phase im SQL Monitor berücksichtigt wird. Wiederum gilt, dass ein zeitaufwändiges Parsing nur über die "Duration" zu beobachten wäre.
Sollten weitere Artikel folgen, versuche ich, sie zu ergänzen - wobei meine Erfolgsquote bei der Umsetzung solcher Absichtserklärungen zuletzt deprimierend niedrig gewesen ist...

Dienstag, Juli 17, 2018

Optische Änderungen

Das Design von Webseiten ist, wie gelegentlichen Besuchern dieses Blogs klar sein dürfte, nicht meine Kernkompetenz. Da ich hier nur noch in Ausnahmefällen Code unterbringe, bin ich jetzt auf ein Blogger-Standard-Design gewechselt. Ich hoffe, die neue Variante stört das ästhetische Empfinden der Besucher zumindest nicht mehr als die vorherige.

Freitag, Juli 06, 2018

ORDER BY in CTEs garantiert keine Sortierung

Dass der einzige Weg, eine Sortierung für Oracle-Queries zu garantieren, die Ergänzung einer ORDER BY Klausel ist, gehört zu den Dingen auf die Tom Kyte regelmäßig hinzuweisen pflegte. In einem aktuellen Artikel zeigt Franck Pachot, dass man sich auch nicht darauf verlassen kann, dass die in einer CTE definierte Sortierung eine entsprechende Sortierung der rahmenden Query bedingt. Seit 12.2 können zur Materialisierung von CTEs "In-Memory Cursor Duration Temp Tables" verwendet werden (die im Exceution Plan mit einem Eintrag "LOAD AS SELECT (CURSOR DURATION MEMORY)" dargestellt werden), und diese Funktionalität kann die Sortierung ausschalten. Vermeiden kann man dieses Feature entweder durch seine Deaktivierung (_in_memory_cdt=off) oder durch Vermeidung der Materialisierung (inline), aber letztlich ist das Verhalten durchaus nicht unschlüssig, da die Sortierung auf globaler Query-Ebene eben nur durch ein dort definiertes ORDER BY garantiert wird.

Montag, Juli 02, 2018

Clustering Faktor und Index Rebuild

Jonathan Lewis liefert im Scratchpad einen interessanten Hinweis: wenn man für einen Index über dbms_stats.set_table_prefs einen geeigneten table_cached_blocks Wert setzt, um den Clustering Faktor plausibler zu gestalten, dann wirkt sich die Präferenz zwar auf folgende Aufrufe von dbms_stats aus, nicht aber auf ein "alter index ... rebuild". Nach einem Neuaufbau kann der Clustering Faktor somit zunächst massiv in die Irre führen, bis er von einer folgenden Statistikerfassung wieder korrigiert wird, was zu schwer nachvollziehbaren Effekten führen könnte.

Nachtrag 17.07.2017: mit Verweis auf den Scratchpad-Artikel hat Richard Foote einen weiteren Beitrag zum Thema geliefert, der das Verhalten mit eingängigen Beispielen erläutert.

Dienstag, Juni 12, 2018

dbms_random zur Generierung (ziemlich) eindeutiger Werte

Jonathan Lewis weist in seinem jüngsten Artikel darauf hin, dass man die Länge von Strings, die man per dbms_random.string('U', n) generiert, mit Bedacht wählen sollte: bereits ein relativ niedriger Wert für liefert eine sehr große Zahl unterschiedlicher Permutationen: für 6 Zeichen sind es bereits über 300 Millionen Kombinationen, so dass sich daraus für den im Artikel (und im zugrunde liegenden OTN-Fall) für eine 100M rows Tabelle ein Wert mit sehr seltenen Wiederholungen ergeben würde. Bei 8 Zeichen ist die Wahrscheinlichkeit der Wiederholung dann schon sehr gering. Umgekehrt ist die Erstellung kürzerer dbms_random-Strings weitaus günstiger: für 20 Zeichen ergeben sich im vorgestellten Beispiel 1m 55 sec, während der String mit 6 Zeichen (und mit per rpad() angehängtem beliebigen Zeichen) in 41 sec erzeugt werden konnte. Die Ursache für diesen Unterschied ist, dass Oracle jedes einzelne Zeichen durch die Zufallsfunktion erzeugt, so dass ein um Faktor 3 längerer String auch in etwa eine um Faktor 3 erhöhte CPU-Nutzung bedeutet. Wo kürzere Strings genügen, kann man dem System demnach einige Arbeit sparen.

Freitag, Juni 08, 2018

Neue Oracle VM Appliance

Nur damit ich es irgendwo verlinkt habe: Jeff Smith weist darauf hin, dass im OTN eine neue VM mit Oracle 12.2, SQL Developer 18.1, Oracle REST Data Services 18.1 etc. zur Verfügung steht.

Donnerstag, Mai 17, 2018

Index Skip Scan bei führender Spalte mit vielen unterschiedlichen Werten

Ja, ich habe schon weniger sperrige Titel für meine Einträge verwendet. Leider ist mir nichts Griffigeres eingefallen - und vor allem nichts, was dann noch zum Sachverhalt passen würde: Jonathan Lewis zeigt, dass der INDEX SKIP SCAN manchmal an Stellen auftreten kann, an denen man ihn nicht erwarten würde. Wo würde man ihn also erwarten? Dort, wo ein mehrspaltiger Index existiert, dessen führende Spalte (oder Spalten) wenige distinkte Werte enthält, so dass es für den Optimizer sinnvoll erscheint, den Index intern quasi in viele Sub-Indizes zerfallen zu lassen. In seinem Artikel liefert der Autor jetzt ein Beispiel mit einem Index, der auf zwei Spalten angelegt ist, die jeweils unique sind - so dass der skip scan hier recht seltsam erscheint. Ursache ist eine Änderung, die mit 11.2.0.2 eingeführt wurde: die I/O-Kosten eines INDEX SKIP SCAN sind seither auf die Anzahl der Leaf Blocks des Index beschränkt, was für einen relativ kleinen Index dann den skip scan interessanter macht als den Full Table Scan. Allerdings wäre der FTS in einem solchen Fall wahrscheinlich effizienter als der skip scan, da dieser den Index in sortierter Ordnung via single block I/O lesen muss, während jener bekanntlich multi block I/O verwenden kann. Noch günstiger wäre in einem solchen Fall die Kombination aus INDEX FAST FULL SCAN und folgendem Tabellenzugriff, aber dazu ist der Optimizer bisher noch nicht in der Lage. Viel Freude hat mir der INDEX SKIP SCAN noch nie gemacht, und diese Costing-Anpassung erklärt, warum man ihn auch an unerwarteten Orten antreffen kann.

Montag, Mai 14, 2018

Dynamische Linesize-Einstellung für sqlplus

Die Welt hat vielleicht nicht darauf gewartet, ich aber ganz gewiß: wie Laurent Schneider erläutert, gibt es mit Oracle 18.1 eine dynamische linesize für sqlplus. Diese orientiert sich an der Größe des Shell-Fensters. Hätte ich diese Option von 15 Jahren bekommen, hätte ich dadurch in Summe mehrere Wochen einsparen können, nehme ich an.