Database Reference
In-Depth Information
15.3
Serial Direct Path Reads
In diesem Abschnitt besprechen wir das Feature „serial direct path reads“ (SDPR), welches
in Oracle 11 eingeführt ist. Dieses Feature ändert das Verhalten bei seriellen Full Table
Scans (FTS) auf großen Tabellen. Vor Oracle 11 erfolgten solche FTS immer über den Buf-
fer Cache. Ab Oracle 11 kann Oracle dafür direkte Zugriffe (direct path reads) benutzen.
Es klingt sehr einfach, in der Tat ist dieses Feature aber ziemlich kompliziert. Ich versuche
hier, nicht zu sehr ins Detail zu gehen und auf der praktischen Schiene zu bleiben. In die-
sem Abschnitt sind also einige Einzelheiten des SDPR präsentiert, welche für die Praxis
von Interesse sind. Das Material dieses Abschnitts basiert auf Oracle 11.2.0.2 und 11.2.0.3.
Peter: „
Was genau verstehst Du unter den ‚seriellen' FTS?
“
Leonid: „
Eine Tabelle kann sowohl seriell als auch parallel bei FTS gelesen werden. Das
parallele Lesen der großen Tabellen benutzt direkte Zugriffe und geht an dem Buffer Cache
vorbei. Es war so zumindest vor Oracle 11g. Bei Oracle 11g kann das parallele Lesen der
großen Tabellen auch über den Buffer Cache erfolgen (s. im Abschn.
15.4
). Das Wort ‚seriell'
wird hier benutzt, um zu betonen, dass dabei keine parallelen Zugriffe gemeint sind.
“
P.: „
Kann dieses SDPR-Feature keine Performanz-Probleme verursachen? Was ist der
Grund für diese Änderung?
“
L.: „
Das direkte Lesen bei Full Scans ist sehr vorteilhaft für Exadata, weil Oracle dafür
Smart Scan einsetzt
[9]
. Bei konventionellen Systemen kann es u. U. einige Performanz-Pro-
bleme verursachen (Oracle benutzt denselben Programmcode für Exadata und für konven-
tionelle Systeme).
“
P.: „
Wie erkennt man solche Probleme?
“
L.: „
Wenn ein System bzw. ein Cursor viele Physical Reads bei den seriellen FTSs macht,
kann es durch das SDPR verursacht werden. In diesem Fall beobachtet man normalerweise
auch Wartezustände für ‚direct path read' und große Werte der jeweiligen Segment-Statistik
‚physical reads direkt'.
“
P.: „
Was kann man in so einem Fall unternehmen? Ist es möglich, SDPR auszuschalten?
“
L.: „
Ein großer Statistikwert ‚physical reads direct' ohne Beschwerden über die schlechte
Performanz ist eigentlich kein Problem. Es ist auch meistens sinnvoller, ein FTS auf einer gro-
ßen Tabelle mit direkten Zugriffen auszuführen. Wenn dabei ein Performanz-Problem ent-
steht, würde ich zunächst versuchen, dieses Problem mit konventionellen Methoden zu lösen.
“
P.: „
Meinst Du damit SQL-Tuning?
“
L.: „
Hauptsächlich ja. Man kann beispielsweise den FTS durch einen Index Range Scan in
dem jeweiligen Ausführungsplan ersetzen und somit das Problem lösen. Ich kann aber noch
ein weiteres Beispiel nennen. Bei der Analyse eines Systems mit sehr vielen direkten Zugrif-
fen habe ich einige Tabellen mit einer sehr hohen High Water Mark und mit relativ wenigen
Datensätzen entdeckt, für welche direkte Zugriffe bei FTS angewendet wurden. Das hat das
I/O sehr stark gestresst und ein Performanz-Problem verursacht. In solch einem Fall hilft die
jeweilige Tabellenreorganisation, welche die High Water Mark heruntersetzt.
“
P.: „
Kann man das SDPR deaktivieren, wenn diese Maßnahmen nicht helfen?
“
