Partitionierte Tabellen und direct path FTS

Über das in 11g eingeführte Feature der direct path reads für serial table scans hatte ich schon mehrfach gelesen, ohne mir viel dabei zu denken. Vor kurzem habe ich dann in Tanel Poders Hacking Session Video den Hinweis bekommen, dass die für die Entscheidung der run time engine, ob eine Tabelle für den direct path Zugriff in Betracht gezogen wird, relevante _small_table_threshold pro Segment definiert ist - also auch für die Partitionen einer partitionierten Tabelle. Trotzdem war ich heute zunächst überrascht, als ein einfaches SELECT COUNT(*) auf einer Heap-Tabelle mit 5.000.000 Sätzen (etwa 1 GB groß) in ca. 20 sec. ablief, während der Zugriff auf eine identisch gefüllte partitionierte Tabelle mehr als 40 sec. benötigte. Ein Vergleich der Statistiken in v$sesstat half meinem Gedächtnis dann auf die Sprünge:

NAME	TABLE_NO_PART	TABLE_PART
consistent gets	72298	74445
consistent gets - examination	0	819
consistent gets direct	72286	0
consistent gets from cache	12	74445
consistent gets from cache (fastpath)	12	71726
DB time	1699	5046
free buffer inspected	0	73410
free buffer requested	0	72568
physical reads	72286	72568
physical reads cache	0	72568
physical reads cache prefetch	0	70674
physical reads direct	72286	0
table scan blocks gotten	72286	72444
table scan rows gotten	5637076	5637107
table scans (direct read)	1	0
table scans (long tables)	1	0
table scans (short tables)	0	86

Die 86 table scans (short tables) gehören zu den Partitionen, während für die nicht partitionierte Tabelle ein table scan (long tables) erscheint - und dieser ruft dann consistent gets direct hervor, während die kleineren Partitionen über den Buffer Cache gelesen werden, was zumindest in diesem Fall deutlich langsamer ist. Die Entscheidung für den direct path Zugriff kann übrigens mit Hilfe des Parameters _serial_direct_read beeinflusst werden, der wie alle hidden parameter natürlich nur nach Rücksprache mit dem zuständigen Arzt oder Apotheker verwendet werden sollte.