Donnerstag, September 18, 2014

Buffer re-visits im Rahmen von Index Range Scans

Nichts Neues, aber ein schönes Beispiel für eines der zentralen Themen bei der Optimierung von Zugriffen in relationalen Datenbanken: Tanel Poder erläutert in seinem Artikel About index range scans, disk re-reads and how your new car can go 600 miles per hour!, warum die Ergänzung von Indizes für analytische Queries (mit Zugriff auf größere Datenmengen) in vielen Fällen keine besonders gute Idee ist: der Zugriff über den (sortierten) Index führt zum wiederholten Zugriff auf die (unsortierten) Tabellendaten - der gleiche data block wird unter Umständen wieder und wieder besucht, so dass das Volumen der gelesenen Daten letztlich das Volumen der Tabelle (und des Index) massiv übersteigt. Diese re-visit-Effekte werden sichtbar in den Trace-Files, die mit Hilfe der Events 10046 (also SQL Trace) und 10298 (ksfd i/o tracing) erzuegt wurden - letzteres enthält die blkno (also Blocknummer), die im Beispiel in einigen Fällen zehn Mal erscheint. Da diese erneuten Besuche (nach Buffer Cache Maßstäben) zeitlich weit auseinander liegen können, ergeben sich für viele re-visits physikalische Leseoperationen, weil die Daten durch folgende reads bereits wieder aus dem Cache verdrängt wurden. Mit Hilfe von (range scans auf) Indizes sind Massendatenoperationen oft nicht optimierbar, was den Herrn Poder zum - ein klein wenig reißerisch klingenden - Titel seines Artikels bringt: um dramatische Beschleunigungen für große Reporting-Fragestellungen zu erreichen, benötigt man andere Verfahren - und dabei denkt er an Exadata und die In-Memory-Option: also Strategien, die die relevanten Datenmengen reduzieren und dabei die Zugriffsstrategien grundsätzlich verändern.

Dienstag, September 16, 2014

Set to Join Konvertierung

Noch ein interessanter Hinweis von Franck Pachot auf eine Transformation, die der Optimizer bereits seit längerer Zeit beherrscht, die aber nur aktiv wird, wenn optimizer_feature_enabled auf 12.1.0.2.1 gesetzt wird - also auf eine Version, die es bisher noch gar nicht gibt. Per Hint (SET_TO_JOIN) kann man die Verwendung des Verfahrens aber bereits seit längerer Zeit aufrufen und erreicht damit, dass Set-Operationen wie MINUS oder INTERSECT in einen Join umgewandelt werden, was für geeignete Mengenverhältnisse durchaus interessant sein kann, insbesondere weil es potentiell kostspielige SORT UNIQUE Operationen vermeiden kann.

Freitag, September 12, 2014

COUNT_DISTINCT für postgres

Thomas Vondra erläutert in seinem Blog die selbst gebaute Funktion COUNT_DISTINCT, mit deren Hilfe sich COUNT(DISTINCT column) Operationen beschleunigen lassen, da sie auf eine (inhaltlich unnötige) Sortierung der Ergebnisse verzichtet. Ursprünglich verwendete er bei seiner Implementierung eine Hash Table, die inzwischen aber durch ein einfaches Array mit sortierten und unsortierten Elementen ersetzt wurde. Interessant finde ich dabei einerseits die großartigen Möglichkeiten der Erweiterbarkeit des postgres-Funktionsumfangs und andererseits die Tatsache, dass hier offenbar ein ähnlicher Lösungsweg gewählt wurde wie der, den Oracle (und andere) bei der Implementierung von HASH GROUP BY Operationen gewählt haben.

Nachtrag 18.09.2014: aktuell scheint der Link nirgendhin zu führen.

Vorteile des Zugriffs auf den In-Memory column store.

Maria Colgan erläutert im Rahmen ihrer Serie zur In-Memory-Option in Oracle 12.1.0.2 die spezifischen Vorteile, die ein TABLE ACCESS IN MEMORY FULL mit sich bringt:
  • der Zugriff beschränkt sich auf die relevanten Spalten - was bei der klassischen Zeilen-orientierten Speicherung natürlich nicht möglich wäre.
  • die IM-Daten liegen in komprimierter Form vor, weil sie beim Laden in den Speicher komprimiert werden.
  • unnötige Daten werden beim Lesen ausgeschlossen, was durch In-Memory Storage Indexes sichergestellt wird. Diese Indizes enthalten die minimalen und maximalen Werte, die in einer In-Memory Compression Unit (IMCU) gespeichert sind.
  • Optimierung des Zugriffs auf relevante IMCUs durch SIMD vector processing (Single Instruction processing Multiple Data values). Diese Strategie erlaubt (wie der Name andeutet) die gleichzeitige Verarbeitung mehrerer Spaltenwerte innerhalb einer einzigen CPU instruction.
Zur Analyse des Verhalten gibt es in v$statname allerhand neue IM scan % Statistiken, die man sich im Rahmen einer intensiveren Beschäftigung mit dem Thema genauer anschauen sollte.

Mittwoch, September 10, 2014

Tabellenzugriff über Index-Kombinationen

In seinem Blog hat Jonathan Lewis dieser Tage die Quizfrage gestellt, wieso es möglich ist, dass eine Query mit einer Einschränkung der Form:
where col1 between 1 and 3
durch eine Umwandlung der Bedingung in die folgende Form optimiert werden kann:
where col1 = 1 or col1 > 1 and col1 <= 3
Die Antwort lautet (natürlich): durch die Kombination mehrerer Zugriffsmöglichkeiten - im Beispiel, an das der Herr Lewis gedacht hatte, geht es um die Kombination von bitmap Indizes, aber theoretisch wäre auch eine Kombination von B*Tree-Indizes möglich.