STATSPACK und ich

[Corto -sX-]

Hi,

ich habe hier ein kleines Problem:

ich habe ein Datenbank monitoring in Auftrag gegeben, da ich nicht selbst der SYSDBA bin. die Betriebssicherheit leistet ein Dienstleister für uns, und darum bin ich "nur" DBA für die Daten, nicht für die Datenbank wenn ihr versteht was ich meine.

wir verwenden eine 11g R1 Standard Edition im RAC.

Nun bekam ich hunderte Seiten Statspack Reports, da wir ja auf Standard keine AWR einsetzen können...

Ich seh da nur bahnhof, mal von 2-3 dingen abgesehen. und ich hab keine ahnung wie ich daraus Sinnvolle Ableitungen zur Performance machen kann

kenn jemand ein paar faustregeln wie man diese reports aufbereitet?

[dr.dimitri]

kenn jemand ein paar faustregeln wie man diese reports aufbereitet?

Ja, die kannst direkt wegschmeißen, oder noch besser zurückschicken und das Geld dafür zurückverlangen.

Einen Statspackreport zu ziehen ist dann sinnvoll, wenn man ein konkretes Problem hat, und in einem bestimmten Zeitraum (15-20 Minuten nicht Stunden oder Tage) wissen möchte, was auf der DB genau los ist. Das ist dann auch deutlich überschaubarer (ca. 1-20 Seiten je nach Aktivität).

Sofern Du also kein konkretes Performanceproblem hast, würd ich auch keinen Statspackreport lesen - außer Du hast zuviel Zeit. Des weiteren würd ich bei den Admins mal nachfragen, was die sich dabei gedacht haben und dass sie sich die 100 Seiten sonst wo hinschieben können

Dim

PS: Über welchen Zeitraum ging denn der Report?

[Corto -sX-]

über 2-3 stunden die für uns interessant wären.

hab nun auch was rauslesen können, unsere cache treffer und solches Zeug. sieht alles gut aus.

Ja die reports sind wirklich nicht optimal, aber mehr geht bei einer standard edition leider nicht.

danke dennoch

[dr.dimitri]

über 2-3 stunden die für uns interessant wären.

Viel zu lange. 15-20 Minuten bei einem aussagekräftigem Workload reichen vollkommen.

unsere cache treffer und solches Zeug. sieht alles gut aus.

Die Buffer Cache Hit Ration ist relativ nichtssagend. Es gibt sogar ein kleines Tool, mit dem man sich seine Wunsch Hit ration selbst erzeugen kann. Über die Performance sagt das relativ wenig aus.

Interessanter sind die Top 5 Statements, ob es dort evtl. Verbesserungspotential gibt bzw. ob Dir bei den Top 5 Wait Events etwas seltsam vorkommt.

Dabei spielt es natürlich auch eine wichtige Rolle, wie die Datenbank verwendet wird. Ein OLAP System sieht anders aus als eine OLTP Instance.

Dim

[carstenj]

Hi,

Ja die reports sind wirklich nicht optimal, aber mehr geht bei einer standard edition leider nicht

auch ein AWR Report liefert in etwa die gleiche Daten, nur schöner aufbereitet.

Wenn euer "Dienstleister" nichts anders tut, als Statspack Reporte zu liefern, ist das schon etwas armselig. Was genau wollt ihr denn überhaupt tun? Die DB überwachen? Oder gibt es momentan ein akutes Problem? Wenn ihr die DB überwachen wollt, tut es auch ganz einfach Nagios mit entsprechenden Plugins, oder Hobbit. Man muss sich natürlich vorher überlegen, was überhaupt überwacht werden soll. Zu viele Daten sind manchmal genauso schlecht wie zu wenige.

Wie Dr. Dimtri schon sagte, Werte die auf der einen DB schlecht sind, können auf der anderen DB gut sein. Die Performanceanalyse ist etwas, was man wirklich können muss, da reicht es nicht, einzelne Werte im Blick zu haben.

[Corto -sX-]

Hi,

auch ein AWR Report liefert in etwa die gleiche Daten, nur schöner aufbereitet.

Leider ist es eine SE, da gibts kein AWR.

nagios hab ich bereits auf die DB angesetzt, aber wenn man da nicht wirklich weis was überwacht werden soll... naja, da schau ich eher nach den Basics wie Tablespace/User/hanging Sessions...

dennoch danke