Database Reference
In-Depth Information
Parameterwerte
parallel
_
servers
_
target
und
parallel
_
max
_
servers
sind. Ab Oracle
Release 11.2.0.2 wartet eine SQL-Anweisung auf das Warteereignis „resmgr:pq queued“,
wenn sie in der Warteschlange steht. In 11.2.0.1 gab es dafür 2 andere Warteereignisse:
„PX Queuing: statement queue“ für die erste SQL-Anweisung in dieser Warteschlange und
„enq: JX - SQL statement queue“ für die restlichen. SQL-Anweisungen, welche in der War-
teschlange stehen, kann man in der View V$SQL_MONITOR ermitteln (sie haben den
Status 'QUEUED').
Peter: „
Eine SQL-Anweisung kann sich ziemlich lange in der Warteschlange befinden.
Gibt es bei Oracle eine Möglichkeit, diese Wartezeit zu verkürzen?
“
Leonid: „
Mit dem Parameter
parallel
_
queue
_
timeout
vom Oracle Resource Manager
kann man die maximale Wartezeit festlegen
[9]
. Wenn ein Prozess länger wartet, wird er mit
dem Fehler ORA-07454 beendet. Du möchtest aber wissen, ob man einen wartenden Prozess
nach dem Ablauf einer bestimmten Zeit mit einem Herunterstufen des Parallelitätsgrades
ausführen kann. Solch eine Möglichkeit kenne ich nicht.
“
Das Feature In-Memory Parallel Execution ermöglicht das Lesen der großen Tabellen
über den Buffer Cache bei parallelen Ausführungen (die kleinen Tabellen, deren Größe
den Parameterwert
_
small
_
table
_
threshold
nicht übersteigt, werden ohnehin über den
Buffer Cache gelesen). Wenn ein System über einen großen Buffer Cache verfügt, kann
dieses Feature die Performanz von parallelen Operationen spürbar verbessern.
Diese beiden Features (Statement Queuing und In-Memory Parallel Execution) kann
man unabhängig vom ADOP-Verfahren aktivieren. Im Unterschied zu ADOP ist es dafür
nicht notwendig, die Prozedur
dbms
_
resource
_
manager
.
calibrate
_
io
auszuführen.
Das Aktivieren des Statement-Quieuing erfolgt bei der Parametereinstellung
_
par
-
allel
_
statement
_
queuing
=
true
. Für eine SQL-Anweisung kann man das mit dem Hint
STATEMENT_QUEUING erreichen. Die Parametereinstellung
_
parallel
_
statement
_
queuing
=
false
bzw. das Hint NO_STATEMENT_QUEUING deaktivieren dieses Feature.
P.: „
In welchen Situationen ist es sinnvoll, das Statement Queuing separat von ADOP zu
benutzen?
“
L.: „
Ich habe das einmal erfolgreich beim Tuning eines Systems eingesetzt, welches paral-
lele Operationen benutzt hat. Die parallelen Operationen wurden dort mit Hints gesteuert.
Außer den parallelen Hints hatten SQL-Anweisungen eine Menge anderer Hints. Bei ziem-
lich vielen SQL-Anweisungen wurde der Parallelitätsgrad heruntergestuft (dies konnte man
anhand der jeweiligen Datenbankstatistiken feststellen, z. B. ‚Parallel operations downgraded
to serial'), was die Performanz negativ beeinflusste. Unter diesen Umständen war es sinnvoll,
das Statement Queuing separat einzusetzen. Das hat eine deutliche Performanz-Verbesse-
rung gebracht.
“
Man aktiviert In-Memory Parallel Execution mit der Parametereinstellung
_
parallel
_
cluster
_
cache
_
policy
=
cached
und deaktiviert mit
_
parallel
_
cluster
_
cache
_
policy
=
adaptive
(
s. z. B. in [9]).
Zum Schluss dieses Abschnitts möchte ich demonstrieren, wie die Features Statement
Queuing und In-Memory Parallel Execution funktionieren. Die beiden Tests präsentieren
die Anwendung dieser Features separat von ADOP. In den beiden Tests ist dieselbe Tabelle
benutzt, welche folgendermaßen angelegt und mit Daten gefüllt wird.
