Database Reference
In-Depth Information
Tuning selten gebraucht werden, lassen wir solche Statistiken im weiteren Text außer Be-
tracht.
Jede der Statistiken in der View V$STATNAME gehört zu einer Klasse (s. die Spalte
CLASS). Diese Statistiken sind zum größten Teil kumulativ. Leider gibt es bei Oracle kein
Kennzeichen für die kumulativen und für die absoluten Statistiken (im Unterschied zu
den Betriebssystemstatistiken). Das bereitet einige Schwierigkeiten beim Monitoring die-
ser Statistiken mit den SQL-Anweisungen. Dort bleibt uns nichts anderes übrig, als diese
beiden Statistikarten anhand der Namen voneinander zu unterscheiden.
Die systembezogenen gegenwärtigen Datenbankstatistiken werden in der View
V$SYSSTAT gepflegt. Die Statistiken für die einzelnen Sessions findet man in der View
V$SESSTAT. Die meisten Statistiken werden jeweils erst nach dem Beenden des entspre-
chenden User Call hochgezählt. Sie können das selber verifizieren, wenn Sie eine langlau-
fende SQL-Anweisung in einer Session starten und in einer anderen deren Statistiken aus
der View V$SESSTAT ermitteln (z. B. mit dem Skript sess_all_stats.sql).
Für die historischen Statistiken in AWR benutzt Oracle die View DBA_HIST_SYSSTAT.
Im Statspack-Repository werden sie in der Tabelle STATS$SYSSTAT abgespeichert. Es gibt
keine historischen Statistiken für die Sessions.
Die Datenbankstatistiken sind ziemlich gut in der Dokumentation von Oracle beschrie-
ben. Falls diese Informationen nicht ausreichend sind, kann man auch in MOS nachschla-
gen. Die Statistiken für Exadata sind in [9] sehr gut erläutert. Aus diesem Grund versuche
ich zu erklären, wie man einige Datenbankstatistiken beim Performance Tuning einsetzen
kann, statt die Datenbankstatistiken mehr oder weniger vollständig zu beschreiben.
Es ist sinnvoll, einige Statistiken in einem Routineverfahren zu prüfen. Bei dieser Rou-
tineprüfung überprüft man in der Regel immer dieselben Statistiken. Einerseits helfen sie,
einen Systemüberblick zu verschaffen. Andererseits sind sie häufig ein Hinweis auf ein
potentielles oder auf ein existierendes Performanz-Problem. Diese Routineprüfung kann
besonders vorteilhaft sein, wenn man es mit einem bis jetzt unbekannten System zu tun
hat. Die Anzahl der zu prüfenden Statistiken muss möglichst klein bleiben, damit man mit
den Routineprüfungen nicht übertreibt. Da ich mit sehr unterschiedlichen Systemen zu
tun habe, ist meine Statistikliste für die Routineprüfung ziemlich unspezifisch und kurz:
• „logonscurrent“-dieabsoluteStatistikfürdieaktuelleAnzahlderAnmeldungenauf
der Datenbank (sprich die Anzahl der Sessions). Ist diese Anzahl groß, kann man sich
für die möglichen Probleme mit der Konkurrenz um die Ressourcen vorbereiten. Es ist
auch wichtig, ob und wie stark diese Anzahl im Laufe der Zeit schwankt,
• „logonscumulative“-diekumulativeStatistikfürdieaktuelleAnzahlderAnmeldun-
gen auf der Datenbank. Die gegenwärtige Statistik in der View V$SYSTTAT liefert die
Anzahl der neuen Anmeldungen seit dem letzten Instanzstart und ist aus diesem Grund
nicht besonders informativ. Wenn man aber die historische Statistik ermittelt, bekommt
man somit die Anzahl der neuen Anmeldungen für einen bestimmten Zeitraum. Diese
Anzahl kann man auch ermitteln, wenn man das Monitoring dieser Statistik aus der
View V$SYSSTAT mittels SQL-Anweisungen einsetzt. Ist die Anzahl der neuen An-
Search WWH ::




Custom Search