Ü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.

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:

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 SAPDBA-Option -next den SAP-Anforderungen angepaßt werden ( Kommandooption -next).

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)

SQL Request (Shared SQL Area)