Mittwoch, Mai 04, 2016

Wann ist ein Full Table Scan billiger als ein Index Fast Full Scan?

Und seit wann verwende ich in meinen Überschriften Fragezeichen? Fragen über Fragen. Aber eigentlich ist der Fall, den Jonathan Lewis in seinem aktuellen Blog-Artikel beschreibt, ebenso überschaubar wie erinnerungswürdig. Seine Fragen darin lauten: wieso werden die Kosten eines Full Table Scans auf einer Tabelle vom Optimizer als niedriger berechnet als die Kosten für den Index Fast Full Scan auf einem Index der Tabelle und warum ist der Index Fast Full Scan trotzdem effizienter in Hinblick auf die Laufzeit der Ausführung. Auf die Frage nach den Kosten gibt es eine wahrscheinliche und eine eher exotische Möglichkeit:
  • die eher exotische Variante wäre: Index und Tabelle wurden mit unterschiedlichen Blockgrößen angelegt. Da eigentlich niemand (außer vielleicht dem Herrn Burleson) ohne gute Gründe (z.B. den Einsatz von Transportablen Tablespaces) auf die Idee kommt, mehrere Blockgrößen in einer Datenbank zu verwenden, tritt der Fall wohl eher selten auf.
  • die wahrscheinlichere Erklärung ist: die Tabelle ist kleiner als der Index. Da ein Index Fast Full Scan (IFFS) tatsächlich ein Full Table Scan (FTS) des Index-Segments ist, basiert das Costing auf der Anzahl der Blocks im Segment. Wenn also die Tabelle kleiner ist als der Index, dann sind auch die Kosten des FTS niedriger als die des IFFS.
Im dem Artikel zugrunde liegenden OTN-Fall war tatsächlich die (aus meiner Sicht) wahrscheinlichere Variante Nr. 2 im Spiel: die Tabelle war kleiner als der Index. Grundsätzlich kann das leicht passieren, wenn eine Tabelle sehr schmal ist, da der Index ja immer noch zusätzlich zu den indizierten Spalten die rowid des Datensatzes enthält, aber im gegebenen Fall deuteten die Autotrace-Statistiken (consistent gets) nicht darauf hin, dass der Index größer war als die Tabelle. Die Ursache dafür war Compression, die für die Tabelle eingerichtet war, während der Index nicht komprimiert wurde - wobei natürlich auch noch zu berücksichtigen ist, dass die Index Compression technisch anders funktioniert als die Table Compression und unter jeweils anderen Voraussetzungen effektiv ist. Die Verwendung der Table Compression ist dann auch der Grund dafür, dass das Costing des Optimizers in diesem Fall den weniger effizienten Plan favorisiert: die Tabelle ist zwar geringfügig kleiner als der Index, aber das Entpacken der komprimierten Daten erfordert zusätzlichen CPU-Einsatz, so dass die Ausführung mit dem IFFS ein wenig schneller abläuft als die mit dem FTS. Interessant ist im Artikel auch, wie der Herr Lewis das Vorliegen der Table Compression und das Fehlen der Index Compression aus den Zahlen des zugehörigen CBO-Traces ermittelt, wobei das keine höhere Mathematik ist.

Keine Kommentare:

Kommentar veröffentlichen