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.

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.