Database Reference
In-Depth Information
64/!DOWHUVHVVLRQVHWBVPDOOBWDEOHBWKUHVKROG
6HVVLRQZXUGHJHLQGHUW
64/!
64/!DOWHUV\VWHPIOXVKEXIIHUBFDFKH
6\VWHPZXUGHJHLQGHUW
64/!
64/!VHOHFWFRXQWIURPW
&2817
64/!
64/!VHOHFWQQDPHVYDOXHVWDWVYDOXHVWDWGHOWDIURPYP\VWDWVYVWDWQDPHQZKHUH
QQDPH SK\VLFDOUHDGVGLUHFWDQGQVWDWLVWLF VVWDWLVWLF
1$0('(/7$
SK\VLFDOUHDGVGLUHFW
L.:
„Beim Parameter
_
small
_
table
_
threshold
muss man aufpassen, weil dieser Parameter
auch das Verhalten von parallelen Operationen beeinflusst (s. im Abschn.
15.4
).
“
P.: „
Soweit ich weiß, ist dieser Parameter auch für den LRU-Algorithmus wichtig.
“
L.: „
Nein, Peter, das war der Fall bei den älteren Oracle Versionen.
“
P.: „
Bei den nicht dokumentierten Parametern habe ich immer ein ungutes Gefühl. Kann
man nicht, das SDPR mit üblichen Mitteln ausschalten? Beispielweise mit der Klausel CACHE
in der jeweiligen Tabellendefinition. Vielleicht ist es auch möglich, SDPR für einzelne SQL-
Anweisungen dediziert außer Kraft zu setzen?
“
L.: „
Ich muss Dich leider enttäuschen. Die Klausel CACHE hat keinen Einfluss auf SDPR.
Es hilft auch nicht, wenn man die Tabelle im Buffer Pool KEEP verwaltet. Ich kenne keine
brauchbare Methode für dedizierte Aktivierung und Deaktivierung von SDPR für einzelne
SQL-Anweisungen. Bei den nicht dokumentierten Parametern hast Du vollkommen Recht,
weil man nicht immer alle Konsequenzen der Verwendung vorhersehen kann.
“
P.: „
Was ist mit Fast Full Scans von Indicies? Werden dort auch direkte Zugriffe benutzt?
“
L.: „
Mit dem Skript test_case_dir_reads_ffs11202.sql kann man sich vergewissern, dass
direkte Zugriffe für sehr große Indices eingesetzt werden, wenn man dieses Skript auf einer
Datenbank mit dem Buffer Cache von 16 MB und der Blockgröße von 8192 ausführt. Unter
den sehr großen verstehen wir Indicies, die größer als das Fünffache von Buffer Cache bzw.
als der Parameterwert von
_
very
_
large
_
object
_
threshold
sind (mit dem Buffer Cache von
32 MB werden in diesem Test-Case keine direkten Zugriffe gemacht).
“
