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.
Keine Kommentare:
Kommentar veröffentlichen