Database Reference
In-Depth Information
Tab. 6.1
Parameter für SQL Monitoring
Parameter
Vorgabewert
Kommentar
_sqlmon_binds_xml_format
Default
Format of column binds_xml in [G]
V$SQL_MONITOR
_sqlmon_max_plan
20
Maximum number of plans entry that can be
monitored. Defaults to 20 per CPU
_sqlmon_max_planlines
300
Number of plan lines beyond which a plan cannot
be monitored
_sqlmon_recycle_time
60
Minimum time (in s) to wait before a plan entry
can be recycled
_sqlmon_threshold
5
CPU/IO time threshold before a statement is
monitored. 0 is disabled
P.: „
Kann man diesen Parameter kleiner setzen, um SQL Monitoring für einen schnelleren
Cursor zu aktivieren?
“
L.: „
Keine gute Idee, Peter. Es ist wesentlich besser, das Hint MONITOR in diesem Fall zu
benutzen. Wenn Du die jeweilige SQL-Anweisung nicht ändern darfst, kannst Du das Hint
MONITOR als Hidden Hint einsetzen (s. im Abschn.
18.7.2
). Wenn diese schnelle SQL-An-
weisung sehr häufig ausgeführt wird, würde ich das SQL Monitoring nicht einsetzen. Man
könnte in diesem Fall das Hint
gather
_
plan
_
statistics
eventuell
benutzen, um die Lauf-
zeitstatistiken im Ausführungsplan für einen Cursor generieren zu lassen. Das kann das Mo-
nitoring des jeweiligen Cursors erübrigen.
“
Für die Cursor, welche parallel ausgeführt werden, wird SQL Monitoring sofort an-
gewendet.
Um die maximale Anzahl der Cursor in der View V$SQL_MONITOR zu ermitteln,
muss man den Parameterwert von
_
sqlmon
_
max
_
plan
mit der Anzahl der CPUs multipli-
zieren. Das folgende Beispiel von einem produktiven System illustriert das.
SQL> show parameter cpu
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
cpu_count integer 32
parallel_threads_per_cpu integer 2
resource_manager_cpu_allocation integer 32
SQL> select count(*) from v$sql_monitor;
COUNT(*)
----------
640
Ein Cursor bleibt stillschweigend mindestens 60 Sekunden lang in der View V$SQL_MO-
NITOR stehen (s. oben den Parameter
_
sqlmon
_
recycle
_
time
). Danach kann er daraus
entfernt werden.
