Montag, Mai 04, 2015

Ein Feature-Request: Actually Evaluated Rows

Vor ein paar Wochen habe ich im OTN-Forum an einer Diskussion teilgenommen, bei der sich einmal mehr gezeigt hat, dass die rowsource statistics in Oracles Trace-Instrumentierung zwar sehr viele wichtige Informationen liefern, aber doch ein paar interessante Angaben aussparen: die darin enthaltene A-Rows-Spalte (= actual rows) liefert die Anzahl der Datensätze, die als Ergebnis eines Schrittes an den folgenden Schritt im Ausführungsplan weitergegeben werden. Das ist natürlich sehr nützlich und gestattet durch den Vergleich von E-Rows (= estimated rows) und A-Rows die relevanten Fehler in der Kalkulation des Optimizers zu bestimmen (den Link auf Wolfgang Breitlings grundlegenden Artikel zum Thema spare ich mir diesmal). Allerdings gibt es Fälle, in denen nicht nur die Anzahl der Ergebnis-Sätze eine wichtige Information ist, sondern auch die Anzahl der Datensätze, die im Rahmen eines Schrittes betrachtet und dann gefiltert werden. Ein umfassendes Beispiel für einen solchen Fall hat Randolf Geist in seinem Artikel Combined ACCESS And FILTER Predicates - Excessive Throw-Away dargestellt (der das im OTN-Thread zugrunde liegende Problem modelliert): ein HASH JOIN erzeugt eine riesige - transiente - Menge von Datensätzen, die im gleichen Schritt gefiltert wird. Die zugehörige A-Rows-Angabe ist 1, aber der zwischenzeitlich erzeugte Suchraum umfasste 100M rows, was natürlich zu einer extremen CPU-Nutzung und einer langen Laufzeit führt.

Randolfs entsprechende Bemerkungen im OTN-Thread hatten mich dazu veranlasst, bei OTN in der Rubrik Database Ideas einen Vorschlag A second A-Row column for input rows in the traces zu formulieren, wobei diese zweite Spalte dann eher als AE-Rows (actually evaluated rows) zu bezeichnen wäre. Jonathan Lewis hat in einem Kommentar zur Idee darauf hingewiesen, dass im Fall die HASH JOINS eigentlich sogar zwei zusätzliche Werte interessant wären, weil hier aufgrund von Hash-Kollisionen unter Umständen sehr viel Arbeit bei der Ermittlung relevanter Matches anfallen kann, eher die ungefilterte Ergebnismenge des Joins erzeugt werden kann - ein passendes Beispiel dazu findet man in seinem Scratchpad. Sollte jemand a) der Meinung sein, dass diese Ergänzung nützlich wäre, b) einen OTN-Account besitzen und c) noch nicht abgestimmt haben, würde ich mich über Unterstützung dieser Idee freuen.

Keine Kommentare:

Kommentar veröffentlichen