Überwachen von Calls (Oracle)
Die Gesamtzahl der beim Oracle-Kernel eingegangenen Abfragen seit dem Starten der Datenbankinstanz wird aufgezeichnet. In einem viel genutzten Produktivsystem wird diese Zahl sehr hoch sein. Jede Verringerung der an den Kernel gesendeten Abfragen reduziert die Belastung des Datenbanksystems.
Der Datenbankmonitor zeigt unter Calls die folgenden Informationen an:
Commits
Commits gibt die Gesamtzahl der seit dem Starten der Datenbankinstanz mit Commit abgeschlossenen Transaktionen an.
Rollbacks
Rollbacks gibt die Gesamtzahl der seit dem Starten des Datenbanksystems zurückgerollten (rolled back) Transaktionen an. Rollbacks werden durch fehlerhafte Programme, gegenseitige Applikationssperren oder abnormale Anwendungsabbrüche ausgelöst. Wenn eine hohe Anzahl Rollbacks angezeigt ist, sollten Sie in der Datenbank-ALERT-Datei (Database Message Log (Oracle)) und den Trace-Dateien nach etwaigen Problemen suchen.
· Die ALERT-Datei und die Trace-Dateien der Oracle-Datenbank für die Oracle-Hintergrundprozesse befinden sich gewöhnlich in: /oracle/<SID>/saptrace/background
· Trace-Dateien für Oracle-Benutzerprozesse findet man in: /oracle/<SID>/saptrace/usertrace
Rekursive Abfragen (Recursive calls)
Rekursive Abfragen treten auf, wenn Oracle zusätzlich zu der SQL-Anweisung eines Benutzerprozesses selbst eine SQL-Anweisung ausgeben muß. Die häufigsten Gründe für rekursive Abrufe sind:
· Misses im Data Dictionary-Cache (Überwachen des Data Buffer (Oracle))
· Dynamische Speichererweiterung
· Ausführung von DDL-Anweisungen, erzwungene referentielle Integritätseinschränkungen, Verwendung von PL/SQL ausgelöst (weitere Informationen dazu finden Sie in der Oracle-Dokumentation)
Rekursive Abfragen können die Performance des Datenbanksystems beeinträchtigen und sollten daher möglichst selten vorkommen.
Das Recursive-Call-Verhältnis wird als Recursive calls/User calls berechnet. Wenn die Anzahl der Recursive calls größer ist als die Anzahl der User calls, sollten Sie eine detailliertere Untersuchung beginnen. Überprüfen Sie die Data Dictionary-Cache-Trefferrate und die durchschnittliche Parsing-Quote. Meist hilft eine Erhöhung von shared_pool_size (SHARED_POOL_SIZE (Oracle)). Stellen Sie sicher, daß der init<SID>.ora-Parameter row_cache_cursors (ROW_CACHE_CURSORS (Oracle)) mindestens auf dem von der SAP empfohlenen Minimum von 100 steht.
Zu einer dynamischen Speichererweiterung kommt es, wenn
ein Datenbankobjekt (Tabelle/Index) über den ihm zugewiesenen Platz hinaus
erweitert werden muß (d.h. ein neuer Extent zugewiesen wird). Es empfiehlt
sich daher immer, den ursprünglichen
Extent (Parameter INITIAL) und die folgenden neuen Extents (Parameter
NEXT) von Anfang an groß genug anzulegen, um eine solche dynamische
Extent-Zuordnung möglichst zu vermeiden. Ein Verändern des Speicherparameters
INITIAL für ein Objekt ist nur über eine Reorganisation möglich. Der Parameter
NEXT sollte regelmäßig mittels der BRCONNECT-Option -next
den SAP-Anforderungen angepaßt werden. Weitere Informationen finden Sie unter
Adapt Next Extents with
BRCONNECT.
Eine Tabellenreorganisation ist im allgemeinen nicht nötig, eine Indexreorganisation kann manchmal jedoch hilfreich sein.
Wie auch bei den Cache-Trefferraten ist der Wert für rekursive Abfragen direkt nach dem Starten der Datenbankinstanz recht hoch. Da der Data Dictionary-Cachespeicher zunächst leer ist, sind alle für das Laden der Informationen in den Arbeitsspeicher erforderlichen Abrufe rekursiv.
Parses
Parses zeigt, wie oft SQL-Anweisungen geparst wurden (Informationen zum Begriff des Parsens finden Sie in der Oracle-Dokumentation). Zur Berechnung der durchschnittlichen Parsing-Rate dividieren Sie Parses durch User calls. Liegt die Rate über 25%, könnte ein Problem mit dem Halten von Cursorn im Shared Cursor Cache (SQL Request (Shared SQL Area)) vorliegen. Überprüfen Sie die bei den statistischen Angaben zum Shared SQL-Bereich besprochenen Trefferraten (Überwachen des Shared Pool (Oracle)). Unter Umständen ist eine Erhöhung von shared_pool_size (SHARED_POOL_SIZE (Oracle)) erforderlich.
Reads / User calls
Der Wert Reads / User calls zeigt die Anzahl der Oracle-Blöcke an, die im Mittel aus dem Datenpuffer gelesen worden sind, um eine Anfrage (Call) an die Datenbank zu befriedigen. Ist dieser Wert größer als 30, so deutet dies auf teure SQL-Statements hin. Sie sollten daher eine Untersuchung der Shared SQL area beginnen.
Siehe auch:
Überwachen der Shared-SQL Area (Oracle)