AWR und Statspack - Performance Tuning fur Oracle-Datenbanken - page 200

L.: „ Das könnte man ( zumindest zum Teil ) mit dem Monitoring der aktiven Session in
der View V$SESSION tun. Gehen wir aber weiter. Das Statspack enthält keine Statistiken
für EXADATA ( z. B. für die Segmente ), was auch verständlich ist, weil lediglich das AWR
für EXADATA vorgesehen ist. Dort fehlen aber auch weitere Segmentstatistiken, wie z. B.
SPACE_ALLOCATED oder CHAIN_ROW_EXCESS. “
P.: „ Sind sie so wichtig? “
L.: „ Man kann sicherlich ohne diese Statistiken überleben. Sie können aber bei Perfor-
mance Tuning behilflich sein. Eines Tages musste ich eine Datenbank untersuchen, die sehr
viele Redo-Daten produzierte. Ich stellte fest, dass einige sehr große Tabellen dort komprimiert
waren. Dafür wurde BASIC COMPRESSION eingesetzt, weil die problematische Datenbank
von der Version 10.2 war. Ich vermutete, dass die meisten Redo-Daten bei den Datenände-
rungen mit UPDATEs auf den komprimierten Tabellen produziert wurden. Bei diesen Daten-
änderungen muss Oracle die Tabellenblöcke entkomprimieren, dabei entstehen zwangsläufig
viele Redo-Daten. Sehr große Werte der Segmentstatistik CHAIN_ROW_EXCESS halfen mir,
diese Hypothese zu bekräftigen. “
P.: „ Das verstehe ich nicht ganz. “
L.: „ Meine Überlegung war ganz einfach: Bei der Entkomprimierung der Tabellenblöcke
müssen viele Chained Rows entstehen “
P.: „ Wie ich sehe, ist das Statspack ziemlich mangelhaft. Ist es nicht besser, das AWR statt
des Statspack für Performance Tuning zu benutzen? “
L.: „ Ja, es ist besser. Einige Firmen haben aber keine Lizenz für AWR und sind aus diesem
Grund auf das Statspack angewiesen. Ich kenne einige große und komplexe Datenbanken, die
mit dem Statspack getunt werden. So schlecht ist das Statspack also auch nicht. “
Die AWR- und die Statspack-Reporte beinhalten selbstverständlich nicht alle Perfor-
manzstatistiken aus dem jeweiligen Repository, sondern lediglich einen Teil davon. Diese
Reporte reichen für eine grobe Performanzanalyse aus. In einigen Situationen genügt diese
Analyse für die Problemlösung. Oft muss man aber zusätzlich eine feinere Analyse mit
anderen Mitteln durchführen.
P.: „ Was fehlt in diesen Reporten für eine feine Analyse? “
L.: „ Einen Fall haben wir bereits oben besprochen: Für die Untersuchung der blockieren-
den Wartezustände in der Vergangenheit braucht man Informationen über die aktiven Ses-
sions aus der View DBA_HIST_ACTIVE_SESS_HISTORY, welche in diesen Reporten fehlen.
Wenn man AWR benutzt, kann man in dieser View zusätzlich nachforschen. Noch ein Bei-
spiel: In den Standard-Reporten ist es problematisch, SQL-Anweisungen für eine Warteklasse
zu ermitteln, weil sie ( mit der Ausnahme der Warteklasse ‚ User I/O ') dort nicht vorhanden
sind. Dafür kann man beispielsweise die Methoden aus dem Abschn. 17.2 benutzen. In den
Standard-Reporten gibt es keine Ausführungspläne für SQL-Anweisungen. Man muss sie ex-
tra ermitteln.“
P.: „ Können wir möglicherweise einen AWR- oder einen Statspack gemeinsam ‚überflie-
gen'? “
L.: „ Ich habe gerade einen AWR-Report. Mit diesem Report wollte ich eine Datenbank
überprüfen, die neulich gravierende Wartezustände für ‚library cache lock' hatte. Dieses