Oracle 10g (Teil VI):

Automatic Workload Repository

Oracle hatte die Version 9i mit dem Schlagwort "EASY TO MANAGE" angekündigt. Das spiegelte sich in intern eingebauten Automatismen wider. Mit der Version 10g sind eine Vielzahl weiterer solcher Automatismen hinzugekommen. Wir beleuchten in diesem Artikel einen genauer: das Workload Repository.

Automatismen

Eine Vielzahl neuer Funktionalitäten, die alle unter dem Schlagwort "Automatic" subsummiert werden, sind in Oracle 9i und 10g eingeführt worden. Einige haben wir bereits im Rahmen dieser Artikelreihe vorgestellt.

Mit AWR und ADDM beschäftigen wir uns im Folgenden.

Überblick

Im Oracle Server wurde schon immer eine Vielzahl von Informationen gesammelt, die der Administrator über V$-Views ansehen und interpretieren konnte. Weiterhin stand das Werkzeug Statspack zur Verfügung mit dem diese Informationen auch gespeichert werden konnten. In Oracle 10g wird eine Reihe zusätzlicher Parameter gesammelt. In einem definierten Zyklus werden diese Daten nun über den neuen Hintergrundprozess MMON auf Platte in das Workload Repository geschrieben (siehe Abbildung 1).

Dieses Repository ist nun der erweiterte Nachfolger von Statspack.

Das AWR liegt im Tablespace SYSAUX (siehe ORDIX News 3/2004. Die hier gesammelten Daten sind über neue DBA-Views (dba_hist_...) ersichtlich. Die Komponente Automatic Database Diagnostic Monitor (ADDM) interpretiert diese Daten zyklisch und macht Vorschläge, die über Views (dba_advisor_...) oder über GRID Control ausgewertet werden können.

Über den init.ora Parameter statistics_level wird definiert, ob AWR genutzt werden soll oder nicht. Der Default für diesen Parameter ist TYPICAL. Wird der Wert auf BASIC gesetzt, sind alle Sammlungen eingestellt.

In-Memory Statistics

Aus fünf verschiedenen Klassen werden Daten in das AWR geschrieben.

• Time Model Statistics (v$sys_time_model, …)
• System Statistics (v$sysstat, …)
• OS Statistics (v$osstat, …)
• Wait Class Statistics (v$system_event, …)
• SQL Statistics (v$sql, …)

Diese Basisdaten repräsentieren Einzelsätze, die über Metriken (v$...metric) kumuliert interpretierbar sind.

Active Session History (ASH)

Relevante Daten der einzelnen Sessions werden in sehr kurzen Zyklen (teilweise ein Satz pro Sekunde) über die interne Komponente Active Session History (ASH) festgehalten.

ASH schreibt diese Daten in den so genannten ROLLING BUFFER. Diese Daten werden dann bei einem Snapshot durch den Prozess MMON mit in das AWR geschrieben. Ist der Rolling Buffer vor Ablauf des Zyklus voll, schreibt der zusätzliche Prozess MMNL vorzeitig die Daten aus dem Rolling Buffer in das Repository. Über die View v$active_session_history können die Daten im Rolling Buffer eingesehen werden. Abbildung 2 stellt diesen Ablauf noch einmal bildlich dar.

Snapshots

Snapshots werden standardmäßig jeweils zur vollen Stunde gezogen. Der Zyklus ist über die folgende Prozedur einstellbar:

dbms_workload_repository.modify_snapshot_settings

Diese Prozedur hat zwei relevante Parameter:

• Retention: Zeit in Tagen, die definiert, wie lange Snapshots im Repository verbleiben sollen.
• Interval: Zeit in Minuten, die definiert, in welchen Abständen Snapshots gezogen werden.

Der Default für Retention beträgt sieben Tage, für Interval eine Stunde. Die maximale Speicherdauer ist allerdings auch durch die Größe des Tablespaces SYSAUX limitiert. Sollen mehr Daten im Repository gespeichert werden, als im Tablespace Platz ist, so werden die ältesten Snapshots schon vor Ablauf der Retention Policy gelöscht.

Baseline

Möchte der Administrator Daten über die Retention hinaus festhalten, so kann eine Baseline gesetzt werden.

dbms_workload_repository.create_baseline

Hierüber werden eine Reihe von Snapshots im Repository fixiert, denn die Parameter sind start_snap_id und end_snap_id. Dieses Verfahren empfiehlt sich beispielsweise, wenn Daten von Monatsläufen im Nachhinein verglichen werden sollen.

Auswertung

Über das Skript awrinfo kann sich der Administrator einen Überblick über die momentane Situation im AWR verschaffen. Hier wird detailliert aufgeführt, welche Komponenten sich momentan im Repository befinden und wie viel Platz sie belegen. Diese Prozedur ist aus unserer Sicht wenig informativ.

Das Skript awrrpt führt die eigentliche Analyse durch. Es wird eine Auswertung über ein zu definierendes Intervall vorgenommen. Das Intervall wird durch zwei Snapshots gebildet. Über awrrpt wird ein Report generiert, den es dann zu interpretieren gilt. Wer in der Vergangenheit schon mit statspack gearbeitet hat (siehe ORDIX News 1/2002), für den ist die Interpretation des Reports nicht unbekannt. Der AWR-Report ähnelt dem alten Statspack-Report sehr stark, er ist nur durch einige neue Bereiche (z. B. OS-Statistik) erweitert worden.

Den AWR-Report kann man wahlweise als Text-Datei oder als HTML-Datei generieren. Die Ausgabe im HTML-Format ist sehr gelungen. In der Text-Ausgabe sind lange SQL-Statements nicht komplett zu sehen, im HTML-Format kann über einen Link zum kompletten Statement gesprungen werden.

Fazit

Wer schon immer Performance-Analysen mit statspack durchgeführt hat, für den bietet AWR wenig Neuland. Verbessert hat Oracle das automatische Löschen aus dem Repository sowie die Ausgabe im HTML-Format. Durch die stark erhöhte Sammelleidenschaft (ASH) wird allerdings auch der Ressourcenverbrauch erhöht.

Klaus Reimers (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen