Performance-Voodoo entzaubert – Analyse von STATSPACK-Reports

07.
Dezember
2021
Veröffentlicht von: Katja Werner

STATSPACK-Reports sind seit Oracle Urzeiten das Mittel der Wahl, um die Performance-Engpässe einer Datenbank identifizieren zu können. Trotzdem tun sich sowohl Neulinge im Gebiet der Oracle Datenbanken als auch langjährig tätige Datenbankadministratoren und Datenbankadministratorinnen immer wieder mal schwer mit der Interpretation von STATSPACK-Reports. Das ist verständlich, denn die dort gesammelten Daten sind schlichtweg erschlagend in ihrer Fülle. Aber – eigentlich ist es leicht, so einen Report auszuwerten. Und genau das möchte der vorliegende Monatstipp an Hand eines Praxisbeispiels vermitteln.

An dieser Stelle auch ein großes DANKE an einen unserer Kunden, der uns die vorliegenden STATSPACK-Reports für diesen Monatstipp freundlicherweise zur Verfügung stellte.

Anmerkung: Vor vielen Jahren kamen für Nutzer der Enterprise Edition mit der Option Diagnostic-Pack AWR-Reports dazu. Die Auswertung von AWR-Reports unterscheidet sich im Grundsatz nicht von der von STATSPACK-Reports.

 

Installation von STATSPACK

Die Installation von STATSPACK im Grundsatz:

  1. Separaten Tablespace anlegen (dies ist zumindest empfohlen, damit bestehende Tablespaces nicht durch die STATSPACK-Daten „zugemüllt“ werden)

  2. Das Skript $ORACLE_HOME/rdbms/admin/spcreate.sql ausführen – hier wird der STATSPACK-User sowie die benötigten STATSPACK-Tabellen/Objekte angelegt

  3. Wenn gewünscht: Job implementieren, der in regelmäßigem Abstand STATSPACK-Snapshots erstellt bzw. auch wieder aufräumt, damit der Tablespace nicht vollläuft.

Ab Version 11 und höher empfiehlt es sich, als STATSPACK-User noch folgende Anpassung vorzunehmen:

insert into stats$idle_event
  select name from v$event_name where wait_class='Idle'
  minus
  select event from stats$idle_event;
commit;


Erstellung von STATSPACK-Reports

Ein STATSPACK-Report erfasst immer den Zeitraum zwischen zwei Snapshots. Die Erstellung von Statspack-Snapshots erfolgt mit dem Befehl:

execute statspack.snap;

Es können Parameter, wie zum Beispiel das Snapshot-Level, mit angegeben werden. An dieser Stelle vertiefen wir dies jedoch nicht weiter.

Der Statspackk-Report wird mit dem Befehl $ORACLE_HOME/rdbms/admin/spreport.sql erzeugt.

Wesentlich bei der Erstellung von Reports bzw. bereits beim Ziehen der Snapshots ist der gewählte Zeitraum. Dieser Zeitraum muss repräsentativ sein. Möchte man zum Beispiel wissen, wie die Performance der Datenbank während eines nächtlichen Joblaufs ist, dann sollte man die Snapshots möglichst kurz vor Beginn und kurz nach Ende des Jobs erzeugen. Ein weiteres Beispiel: Berichten Anwender über Performance-Engpässe, die ca. 15 Minuten andauern, so muss man auch die Reports dazu in etwa über diesen Zeitraum erstellen, denn bei Reports über einen Zeitraum von mehreren Stunden wäre der Performance-Engpass gar nicht mehr erkennbar.

Es empfiehlt sich weiterhin, STATSPACK-Reports in Zeiten guter Performance zu erstellen und aufzubewahren. Damit hat man eine Vergleichsmöglichkeit für Zeiten schlechter Performance und kann anhand des Vergleichs der Reports-Engpässe leichter identifizieren.

Interpretation von STATSPACK-Reports

Wie analysiere und interpretiere ich nun einen STATSPACK-Report? Zuerst einmal gibt es aus Sicht der Autorin drei Grundsätze zu beachten:

  1. Die Übersicht bewahren:
    STATSPACK-Reports haben immer dieselbe Gliederung: einen Übersichtsteil, die verschiedensten Statistiken im Detail (wovon in der Regel die SQL Statistiken immer die wichtigsten für den Einstieg in die Analyse sind) sowie die init.ora-Parameter am Ende.
  2. Die Zahlen niemals sofort in gut/schlecht bewerten:
    Die Statistiken sind zu Beginn „erschlagend“. Es empfiehlt sich, gerade am Anfang die entscheidenden Stellen des Reports erst nur einmal anzuschauen und „wirken“ zu lassen. Stellen, wo Performance-Probleme vermutet werden, sollte man sich merken, aber noch nicht zu tief analysieren. Stattdessen wird der Report bis unten überflogen. Dann hat man das Gesamtbild und verliert sich nicht in vermeintlichen Engpässen, die letztlich vielleicht doch nicht entscheidend sind, aber viel Zeit in der Analyse gekostet haben. Nachdem der Report einmal grob an den wichtigsten Stellen durchgeschaut wurde, betrachtet man die auffälligen Punkte in einem zweiten Schritt genauer und „drillt“ so immer detaillierter rein.
  3. Dort tunen, wo die höchsten Waits sind. Es nützt nichts, die letzte Millisekunde rauszuholen, wenn an anderer Ecke Minuten unnütz verloren werden.

Wie sieht das am Beispiel aus der Praxis aus? Dazu werfen wir einen Blick in den STATSPACK-Report orcl_20211117_1256_1306.lst. Für diesen Monatstipp wurde der Report anonymisiert, die Statistiken wurden jedoch 1:1 übernommen, so dass er uns gut als Beispiel dienen kann.

Hintergrund für diese STATSPACK-Report-Analyse war die Klage eines Kunden, dass ein bestimmter Job seit einiger Zeit sehr lange lief. Da dieser Job isoliert gestartet werden konnte, konnten wir direkt vor Jobbeginn einen STATSPACK-Snapshot ziehen und direkt danach einen zweiten. Außer dem betroffenen Job war auf der Datenbank keine Last – optimale Bedingungen also, um diesen Job mit Hilfe des STATSPACK-Reports zu analysieren. Los gehts also:


Übersicht

Im obersten Teil des STATSPACK-Reports finden wir allgemeine Angaben:

           719897685 orcl               1 10-Okt-21 19:26 11.2.0.3.0  NO

Host Name             Platform                CPUs Cores Sockets   Memory (G)
~~~~ ---------------- ---------------------- ----- ----- ------- ------------
     host01             Linux x86 64-bit          16     8       2         47.1

Snapshot       Snap Id     Snap Time      Sessions Curs/Sess Comment
~~~~~~~~    ---------- ------------------ -------- --------- ------------------
Begin Snap:          2 17-Nov-21 12:56:34      484       2.4
  End Snap:          3 17-Nov-21 13:06:22      497       2.4
   Elapsed:       9.80 (mins) Av Act Sess:       0.9
   DB time:       8.40 (mins)      DB CPU:       8.34 (mins)

Die Instance heißt orcl, wurde am 10.10.2021 um 19:26 gestartet, hat das Oracle-Release 11.2.0.3 und es ist eine Single Instance (RAC=NO). Clusterwaits fallen hier also schonmal nicht als Problem an.

Der Hostname ist host01, es ist ein Linuxsystem, 64 bit und es gibt 16 CPUs. Diese Zahl merken wir uns im Hinterkopf. Der Memory der Maschine beträgt 47,1 Gigabyte.

Der STATSPACK-Report geht über den Zeitraum von 12:56:34 bis 13:06:22 Uhr am 17.11.2021. Das sind 9,80 Minuten (Elapsed: 9,80 (mins).

Die DB time der Datenbank beträgt 8,40 Minuten (=DB time). Die DB time umfasst alle non idle Waits plus die CPU time. Idle Waits – wenn zum Beispiel auf eine Eingabe durch den Client gewartet wird (sqlnet message from client) zählen nicht zur DB time. Generell steht die Datenbank also nicht sehr unter Last, denn der Zeitraum für den Report umfasst 9,80 Minuten (siehe oben: Elapsed) bei einer DB time von 8,4 Minuten. Bei hoher Last könnte die DB time viel höher ausfallen – allein 16 CPUs, die über den Zeitraum von 9,80 Minuten beschäftigt wären, ergäben eine theoretisch mögliche DB time von 156,8 Minuten. Dazu könnten auch noch erhebliche Wartezeiten beim Lesen/Schreiben kommen.

Von der DB time entfallen 8,34 Minuten auf die CPU (DB CPU). Auf andere Waits – erfahrungsgemäß sind das meist I/O-Waits – entfallen hier also nur 0,06 Minuten. Die Datenbank scheint somit kein Problem beim Lesen oder Schreiben zu haben. Vielmehr ist die CPU Haupt“verbraucher“ der Performance. Rein rechnerisch ist über den Report-Zeitraum eine CPU fast voll beschäftigt (8,34 von 9,8 Minuten). Es könnten auch mehrere CPUs (wir haben schließlich 16) über jeweils einen kürzeren Zeitraum in Anspruch genommen worden sein. Dann wären die 8,34 Minuten die Summe aus den Waits aller CPUs.

Eine festzuhaltende Idee ist an dieser Stelle: Wenn wir den CPU-Verbrauch der Datenbank senken, könnten wir viel Performance gewinnen.

Eine weitere zu klärende Vermutung: Hat hier evtl. ein Prozess nicht schneller arbeiten können, weil er eine CPU bis fast zum Anschlag beschäftigt hat?

Diese beiden Punkte halten wir hier nur fest, wir vertiefen sie erst später.

Wir lesen weiter. Das Load Profile:

Load Profile              Per Second    Per Transaction    Per Exec    Per Call
~~~~~~~~~~~~      ------------------  ----------------- ----------- -----------
      DB time(s):                0.9                0.2        0.01        0.00
       DB CPU(s):                0.9                0.2        0.01        0.00
       Redo size:           60,597.8           13,335.2
   Logical reads:           40,744.1            8,966.1
   Block changes:              321.4               70.7
  Physical reads:           18,311.2            4,029.6
 Physical writes:               14.7                3.2
      User calls:              174.4               38.4
          Parses:               13.8                3.0
     Hard parses:                0.9                0.2
W/A MB processed:                2.2                0.5
          Logons:                0.2                0.0
        Executes:              164.3               36.2
       Rollbacks:                0.1                0.0
    Transactions:                4.5

Das Load Profile sollte immer mit angesehen werden, denn es ist ein wichtiger Indikator dafür, wieviel auf der Datenbank passiert. Interessant ist unter anderem, wieviel Last gemittelt pro Transaktion besteht. Lohnend ist auch immer ein Blick auf das Verhältnis von Executes zu Rollbacks. Insbesondere beim Vergleich von STATSPACK-Reports kann mit Hilfe des Load Profiles Aussagen darüber gemacht werden, ob zu einem der beiden Zeiträume generell mehr auf der Datenbank los war, so dass entsprechende Performance-Engpässe damit erklärt werden könnten. Block changes, Reads und Writes ergeben meist nur im Vergleich zu einem anderen STATSPACK-Report eine sinnvolle Interpretationsmöglichkeit in Bezug darauf, ob die Werte hoch/normal/niedrig sind.

Das Load Profile des vorliegenden STATSPACK-Reports ist nicht allzu interessant. Es bestätigt, dass die generelle Last auf der Datenbank nicht allzu hoch ist. 0,9 Sekunden DB time wurden pro Sekunde benötigt. Im diesem Wert von 0,9 finden wir übrigens die DB time von 8,4 Minuten für eine Elapsed time von 9,8 Minuten aus dem obersten Teil des STATSPACK-Reports wieder –  auf Sekundenbasis umgerechnet.

Nun kommen wir zur wichtigsten Sektion des STATSPACK-Reports beim Performance-Tuning – den Top 5 Timed Events:

Top 5 Timed Events                                                    Avg %Total
~~~~~~~~~~~~~~~~~~                                                   wait   Call
Event                                            Waits    Time (s)   (ms)   Time
----------------------------------------- ------------ ----------- ------ ------
CPU time                                                       490          94.4
direct path read                               347,790          20      0    3.8
log file parallel write                          3,163           2      1     .5
SQL*Net message from dblink                        159           2     11     .3
db file async I/O submit                           144           1      9     .2
          -------------------------------------------------------------

Hier sehen wir, welche Wait Events am meisten Zeit kosteten. Dies ist der Ausgangspunkt dafür, in welche detaillierten Statistiken wir dann weiter vordringen. In unserem Fall hat im gewählten Zeitraum die Datenbank 94,4 Prozent der Zeit auf CPU gewartet. Wenn wir tunen wollen, müssen wir am sinnvollsten hier ansetzen, da wir hier am meisten Zeit einsparen könnten. Sehr oft stehen an oberster Stelle der „Top 5 Timed Events“ auch Events wie „db file scattered read“ oder „db file sequential read“ – in so einem Fall würden wir eher in Richtung lese-/schreibintensive SQLs suchen, um die Performance zu steigern.

Die Abschnitte „Instance CPU“, „Virtual Memory Paging“ und „Memory Statistics“ überfliegen wir kurz:

Instance CPU
~~~~~~~~~~~~                                       % Time (seconds)
                                            -------- --------------
                     Host: Total time (s):                  9,458.9
                  Host: Busy CPU time (s):                    544.8
                   % of time Host is Busy:       5.8
             Instance: Total CPU time (s):                    504.9
          % of Busy CPU used for Instance:      92.7
        Instance: Total Database time (s):                    514.9
  %DB time waiting for CPU (Resource Mgr):       0.0

Virtual Memory Paging
~~~~~~~~~~~~~~~~~~~~~
                     KB paged out per sec:              .1
                     KB paged  in per sec:              .0

Memory Statistics                       Begin          End
~~~~~~~~~~~~~~~~~                ------------ ------------
                  Host Mem (MB):     48,258.1     48,258.1
                   SGA use (MB):      4,077.7      4,077.7
                   PGA use (MB):      1,315.3      1,338.4
    % Host Mem used for SGA+PGA:         11.2         11.2
          -------------------------------------------------------------

Der Host steht mit 5,8 Prozenz kaum unter Last. Hier gibt es in unserem Beispiel nicht allzu viel Neues. Außer vielleicht eine Bestätigung, dass es außer unserer Instance so gut wie keine weiteren CPU-„Verbraucher“ auf dem Host gibt („% of Busy CPU used for Instance“ ist 92,7). Paging gibt es nicht, die SGA ist stabil bei ca. 4 Gigabyte und die PGA fast stabil mit ca. 1,3 GB.

Wir beschließen den Überblick mit einem kurzen Blick auf den Abschnitt „Time Model System Stats“:

Time Model System Stats  DB/Inst:ORCL/orcl  Snaps: 2-3
-> Ordered by % of DB time desc, Statistic name

Statistic                                       Time (s) % DB time
----------------------------------- -------------------- ---------
DB CPU                                             500.4      99.3
sql execute elapsed time                           489.6      97.2
parse time elapsed                                   9.9       2.0
hard parse elapsed time                              9.2       1.8
PL/SQL execution elapsed time                        1.8        .4
hard parse (sharing criteria) elaps                  0.8        .2
connection management call elapsed                   0.2        .0
PL/SQL compilation elapsed time                      0.2        .0
sequence load elapsed time                           0.1        .0
failed parse elapsed time                            0.0        .0
repeated bind elapsed time                           0.0        .0
hard parse (bind mismatch) elapsed                   0.0        .0
inbound PL/SQL rpc elapsed time                      0.0        .0
DB time                                            503.9
background elapsed time                             11.0
background cpu time                                  4.4
          -------------------------------------------------------------

Auch hier müssen wir uns in diesem Fall nicht lange aufhalten. Unsere bisherige Sicht passt – DB CPU wird viel verbraucht.

Damit haben wir einen ersten Überblick über Datenbank und Host. Wir haben erkannt, dass am ehesten Tuningpotenzial beim CPU-Verbrauch besteht. Nun schauen wir uns die einzelnen Statistiken genauer an.


Detaillierte Statistiken

Die Statistiken sind der Hauptteil des STATSPACK-Reports – ein Schatz an Zahlen. Statistiken gibt es über alles Mögliche – Wait Events, SQL Statistics, IO Statistiken, Segment Statistiken, Resource Limits und noch viel mehr. Der Trick ist, gezielt die Abschnitte anzusehen, die uns beim Performance-Tuning weiterhelfen. Dies sind in allererster Linie die SQL Statistics. Sie enthalten Informationen über die Performance der Top-SQL-Statements und das ist es schließlich, was wir tunen wollen. Also beginnen wir genau hier. Im Falle von I/O-Problemen könnte es auch weiter zu den Segment Statistics gehen – Statistiken über Plattenzugriffszeiten. Auch die anderen Abschnitte sind spannend, aber sollten eher dann angesehen werden, wenn wir hier Probleme vermuten oder andere Recherchen uns nicht weiterhelfen.

In unserem Beispiel springen wir also zu den SQL Statistics. Hier sind die Top-SQL erfasst – sortiert nach unterschiedlichen Kriterien. Kriterien, nach denen separat SQLs aufgeschlüsselt werden, sind:

  • SQL ordered by CPU
  • SQL ordered by Elapsed time
  • SQL ordered by Gets (► hier sind Bufferzugriffe gemeint)
  • SQL ordered by Reads (► hier sind Lesezugriffe von Platte gemeint)
  • SQL ordered by Executions
  • SQL ordered by Parse Calls
  • SQL ordered by Sharable Memory
  • SQL ordered by Version Count

Die gleichen SQLs tauchen häufig in mehreren Kategorien auf. In unserem Beispiel suchen wir nach SQLs mit hoher CPU time, damit wir hier mit dem Tuning ansetzen können. Also gehen wir in die Kategorie „SQL ordered by CPU“.

SQL ordered by CPU  DB/Inst:ORCL/orcl  Snaps: 2-3
-> Total DB CPU (s):             500
-> Captured SQL accounts for  192.1% of Total DB CPU
-> SQL reported below exceeded  1.0% of Total DB CPU

    CPU                  CPU per             Elapsd                     Old
  Time (s)   Executions  Exec (s)  %Total   Time (s)    Buffer Gets  Hash Value
---------- ------------ ---------- ------ ---------- --------------- ----------
    234.26            1     234.26   46.8     234.99          16,600 2703649183
Module: CHOOSE
begin doit.sumup; end;

    234.06          430       0.54   46.8     234.73           3,239 3154799086
Module: CHOOSE
UPDATE SCOTT.TEIL SET BESTAND = NVL(BESTAND,0) + :B2 WHERE
NR = :B1 AND TEIL = 1

    118.04          275       0.43   23.6     118.34             310  813881784
Module: PROTOC
INSERT INTO SCOTT.UEB(ORACLE_USER,USERNAME,PROGRAMM,DATU
M,CODE,NR,BESTAND) SELECT SUBSTR(ORACLE_USERNAME,1,20),SUBSTR(U
SERNAME,1,20),SUBSTR(PROGRAMM,1,60),SYSDATE,3, :B2 ,:B1 FROM
VUEBERSICHT WHERE SESSIONID = USERENV('SESSIONID')

    117.64          275       0.43   23.5     117.98             334 3439230104
Module: PROTOC
INSERT INTO SCOTT.UEB(ORACLE_USER,USERNAME,PROGRAMM,DATU
M,CODE,NR,BESTAND) SELECT SUBSTR(ORACLE_USERNAME,1,20),SUBSTR(U
SERNAME,1,20),SUBSTR(PROGRAMM,1,60),SYSDATE,2, :B2 ,:B1 FROM
VUEBERSICHT WHERE SESSIONID = USERENV('SESSIONID')

     69.64          121       0.58   13.9      69.95             726 3830797661
Module: CHOOSE
select to_char(MaxCompileTime,'DD.MM.YYYY HH24:Mi:SS') ,to_char(
MaxLib,'DD.MM.YYYY HH24:Mi:SS') ,decode(:b0,(-1),0,nvl(Sign
((to_date(:b1:b2,'DD.MM.YYYY HH24:Mi:SS')-MaxCompileTime)),1)) ,
decode(:b3,(-1),0,nvl(Sign((to_date(:b4:b5,'DD.MM.YYYY HH24:Mi:S


Wir lesen:

Total DB CPU (s): 500 Das entspricht 8,33 Minuten und ist somit nah dran an den 8,4 Minuten DB CPU aus der Übersicht oben. Die Differenz ist vermutlich auf Rundungsfehler zurückzuführen.

Captured SQL accounts for 192,1% of Total DB CPU Moment mal. 192,1%? – Wie kann denn das sein?! – Die Erklärung ist, dass Oracle hier auch Prozeduren aufführt, für die es die CPU protokolliert. Das SQL, was innerhalb dieses PL/SQL ausgeführt wird, wird jedoch ebenfalls erfasst mit der verbrauchten CPU – hier wird also doppelt gezählt, so dass die 192,1 % nicht wirklich ernst zu nehmen sind.

SQL reported below exceeded  1.0% of Total DB CPU Im STATSPACK-Report sind alle Statements enthalten, die mehr als 1% der Gesamt DB CPU verbraucht haben.

Nun folgen die einzelnen Statements, in absteigender Reihenfolge nach der CPU time sortiert. Das Statement mit dem höchsten Wert an CPU time ist ein PL/SQL: begin doit.sumup; end; . Es wurde im erfassten Zeitraum einmal ausgeführt und benötigte für diese Ausführung 234,26 Sekunden der CPU. Dies sind 46,8 Prozent des gesamten Verbrauchs und das Statement lief über 234,99 Sekunden (Elapsed time). Es hat somit fast die gesamte Laufzeit allein die CPU „beschäftigt“. Zusätzlich bekommen wir noch die Information, dass dieses Statement 16.600 Zugriffe auf Blöcke (Buffer Gets) ausführte. Das Old Hash Value ist eine ID, mit deren Hilfe man mehr Informationen über das Statement selbst aus den STATSPACK-Tabellen herausfiltern könnte. Darauf gehen wir hier jedoch nicht weiter ein. Wenn wir tunen möchten – sollten wir uns zuallererst Statements, die innerhalb dieses PL/SQL ausgeführt werden, genauer ansehen. Es ist wahrscheinlich, dass das folgende SQLs das ist, was zum selben Modul gehört. Eine endgültige Bestätigung kann man jedoch nur im Gespräch mit dem Entwickler oder durch die Code-Analyse des Packages erhalten.

Sehen wir uns nun das Statement mit der zweithöchsten CPU time an: UPDATE SCOTT.TEIL SET BESTAND = NVL(BESTAND,0) + :B2 WHERE NR = :B1 AND TEIL = 1 – dieses SQL verbrauchte 234,06 Sekunden CPU. Es wurde 430-mal ausgeführt und pro Ausführung benötigte es 0,54 Sekunden CPU. In Summe sind das (wieder) 46,8 % der gesamten CPU time. Diese Werte deuten darauf hin, dass dieses UDATE innerhalb des obenstehenden Packages ausgeführt werden.

Das dritte und vierte Statement ähneln sich. Beide Statements werden 275 mal ausgeführt – sie scheinen irgendwie zusammen zu hängen. Die CPU time beträgt jeweils 118,04 Sekunden – das ist ganz ordentlich. Der CPU-Verbrauch entsteht hier durch die Verwendung von Funktionen wie SUBSTR bzw. das Abfragen von SYSDATE.

Soweit zum Lesen des Reports für „SQL ordered by CPU“:

Bei der Analyse der Statements zusammen mit dem Kunden bestätigte sich, dass das PL/SQL an oberster Stelle und das UPDATE-Statement zusammen gehörten. Hier gab es keinerlei Tuningpotential.

Beim Betrachten des dritten und vierten Statements und auf Nachfrage, ob es sein muss, dass ein ähnliches Statement zweimal läuft, ergaben sich zwei Erkenntnisse:

  1. Diese Statements rühren aus einem Trigger, der vor und nach der Änderung eines Datensatzes Sessioninformationen mitprotokolliert. Dafür wurde über mehrere Ecken die View V$SESSION in hoher Frequenz abgefragt inklusive einiger Funktionen (SUBSTR, SYSDATE). Damit war der erste Ansatzpunkt für das SQL-Tuning gefunden: das Ermitteln der Sessioninformationen wurde so angepasst, dass der SYS_CONTEXT anstelle der View genutzt wurde. Mit dieser Änderung sank der CPU-Verbrauch extrem herunter – so weit, dass die beiden Statements nicht mehr in dem nachfolgenden STATSPACK-Report auftauchten.
  2. Eine weitere Möglichkeit für Performance-Verbesserungen wäre, den geänderten Datensatz nur einmal zu historisieren und nicht vor UND nach jeder Änderung

Beim Durchsehen des STATSPACK-Reports wurde auch die Vermutung bestätigt, dass es ein Job war, der eine CPU mehr oder wenig durchgehend nutzte. Diese Information ist jedoch aufgrund des Statement-Tunings und deutlich niedrigerer CPU-Nutzung nicht mehr von Belang.


init.ora

Der letzte Abschnitt in STATSPACK-Reports ist eine Übersicht über die gesetzten init.ora-Parameter. Ein kurzer Blick hierher lohnt sich für den Überblick, wenn man die Instance (noch) nicht kennt – eine Situation, in der man sich als externer Consultant häufig befindet. Manchmal sind Parameter gesetzt, die das Verhalten des Oracle Optimizers beeinflussen oder andere auffällige Werte, die auf bestimmte Charakteristika der Datenbank hinweisen. Diese Informationen runden das bis hierher aus der STATSPACK-Report-Analyse gewonnene Bild ab.

Im vorliegenden Beispiel gibt es keine besonderen init.ora-Parameter.


Fazit

Die Analyse von STATSPACK-Reports ist gar nicht schwer, wenn man den Überblick behält, den richtigen Einstieg findet, einen Fahrplan hat und sich nicht in den Daten verliert. Wichtig ist es, den Report für einen aussagekräftigen Zeitpunkt zu erstellen sowie möglichst Vergleichsreports zu haben, um Performance-Engpässen leichter auf die Spur zu kommen.

Sollten Sie hierzu weitere Fragen oder Beratungsbedarf haben, wenden Sie sich gern an uns.

Jede Menge Know-how für Sie!

In unserer Know-How Datenbank finden Sie mehr als 300 ausführliche Beiträge zu den Oracle-Themen wie DBA, SQL, PL/SQL, APEX und vielem mehr.
Hier erhalten Sie Antworten auf Ihre Fragen.