Sonntag, September 28, 2014

Analyse des Oracle Kernel Verhaltens mit SystemTab

Luca Canali beschäftigt sich in seinem Blog recht regelmäßig mit Hilfsmitteln, die es erlauben, das Verhalten des Oracle Servers im Zusammenspiel mit den OS-Komponenten zu untersuchen. Ein solches Hilfsmittel ist das tracing and probing tool SystemTab, das die Arbeitsweise des Linux-Kernels ausleuchtet. Im Artikel zeigt der Autor die Möglichkeiten der Verknüpfung von SystemTab mit dem Oracle Wait Interface und den X$-Strukturen:
These techniques aim to be useful as well as fun to learn for those keen into peeking under the hood of the technology and improve their effectiveness in troubleshooting and performance investigations.
Die Details nachzuerzählen, erspare ich mir und belasse es bei diesem Verweis, dem ich möglicherweise gelegentlich intensiver nachgehen könnte.

Montag, September 22, 2014

Attribut-Clustering mit 12.1.0.2

Richard Foote hat schon vor einigen Wochen eine kurze Einführung zum Feature Attribute Clustering geliefert, das in 12.1.0.2 verfügbar wurde. Dieses Feature ermöglicht die Angabe einer Clustering-Klausel im CREATE TABLE-Kommando, die eine (ungefähre) physikalische Clusterung der Tabellendaten nach dem Inhalt einer angegebenen Spalte (oder auch mehrerer Spalten) hervorruft. Eine Syntax-Variante dazu lautet etwa:
create table ...
clustering by linear order (col1)
Diese Klausel ruft beim Direct-Path Insert neuer Daten eine Sortierung hervor, die sicherstellt, dass die Daten am geeigneten Platz eingefügt werden - was natürlich einen Einfluss auf die Performance der Operation hat. Umgekehrt ist dafür dann der Clustering-Factor entsprechend sortierter Indizes niedriger, was sich dann wieder positiv auf entsprechende Index-Zugriffe auswirkt. Für conventional path DML wird das Feature nicht unterstützt (worauf Stefan Köhler in seinem Kommentar hinweist). Demnach scheinen hier OLTP-Systeme wohl nicht das vorgestellte Ziel zu sein.

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.