Oracle 10g (Teil V):

dbms_stats - Trau keiner Statistik, die du nicht selbst ...

Dieser berühmte Spruch ist auch unter Datenbankadministratoren sehr verbreitet. Viele Anhänger des regelbasierten Optimizers oder des traditionellen Befehls ANALYZE TABLE wehren sich nach wie vor - selten mit guten Argumenten - das von Oracle empfohlene Paket zu verwenden. Mit der Version 10g liefert Oracle einige zusätzliche schlagkräftige Argumente für den Umstieg auf den kostenbasierten Optimizer. Lassen Sie die guten, alten Zeiten hinter sich und lösen Sie mit etwas Aufwand auch schwierige Statistikprobleme.

Übersicht

Mit der Grid Version ihres Datenbank Management Systems liefert Oracle im Wesentlichen vier neue Funktionalitäten, welche im Zuge dieses Artikels näher beleuchtet werden.

Die erste Erweiterung ermöglicht es, Objekte bezüglich ihrer Statistiken zu sperren und zu entsperren.

Die zweite Erweiterung stellt die Wiederherstellung von Statistiken aus der Vergangenheit zur Verfügung.

Weiterhin gibt es neue Prozeduren zum Sammeln der Statistiken für das Data Dictionary und erstmalig auch für die sogenannten fixed objects. Die automatisierten Features runden diesen Beitrag ab.

Sperren, Entsperren und das dbms_stats Paradoxon

Im Prinzip ist es nur dann sinnvoll, Statistiken zu sammeln, wenn aufgrund neuer Statistiken ein besserer/anderer Ausführungsplan für die wichtigsten SQL Befehle entsteht. Andererseits können gerade aus veränderten Statistiken schlechte Ausführungspläne resultieren. Dies ist das sogenannte „dbms_stats Paradoxon“ von Dave Ensors: „It is only save to gather statistics when to do so will make no difference.“

Mit Oracle 10g ist es nun möglich, Statistiken für einzelne Objekte zu „sperren“. Weder die Aktualisierung noch das Löschen der zugehörigen Statistiken ist danach möglich. Lediglich mit der neuen Option FORCE kann bei einigen Prozeduren diese Sperre durchbrochen werden. Die Abbildung 1 veranschaulicht ein Szenario, in welchem auf der Tabelle C die Statistiken unverändert bleiben sollen.

Die Statistiken der Tabelle C im Schema SCOTT werden mit der Prozedur lock_table_stats (‘SCOTT‘, ‘C‘ ) (siehe Punkt 1 in Abbildung 1) gesperrt .

Wird nun das Schema SCOTT mit dem Befehl gather_schema_stats(‘SCOTT‘, ... ) (siehe Punkt 2 in Abbildung 1) analysiert, überspringt die Prozedur die Tabelle C.

Auch die explizite Ausführung von

gather_table_stats(‘SCOTT‘,‘C‘, ...) (siehe Punkt 3 in Abbildung 1) scheitert.

Lediglich über die Option FORCE, z. B. mit import_column_stats(..., force=>true) (siehe Punkt 4 in Abbildung 1) lässt sich die Sperre durchbrechen.

Über den Befehl unlock_table_stats (‘SCOTT‘, ‘C‘ ) (siehe Punkt 5 in Abbildung 1) wird die Sperre wieder aufgehoben.

Historisierung von Statistiken

Sollten sich nach dem Sammeln neuer Statistiken Ausführungspläne verschlechtern, so ist guter Rat meist teuer.

Bereits mit der Version 9 konnten Statistiken mit Hilfe des Pakets dbms_stats in der sogenannten stattab Tabelle gesichert und wiederhergestellt werden. Dies musste vom DBA aber explizit implementiert werden.

Ab 10g sichert Oracle automatisch alle Statistiken vor dem Überschreiben. Mit den Re­store Prozeduren lassen sich dann diese gesicherten Statistiken für die folgenden Objekte wiederherstellen:

• Tabellen
• Gesamtes Schema
• Gesamte Datenbank
• Fixed Objects
• Data Dictionary
• System Statistiken

Sollen beispielsweise die Statistiken der Tabelle SCOTT.EMP von gestern wiederhergestellt werden, so kann dies mit folgendem Befehl erfolgen:

DBMS_STATS.RESTORE_TABLE_STATS ( 'SCOTT‘, 'EMP‘, systimestamp - 1 )

Die Abbildung 2 veranschaulicht dieses Szenario noch mal in Zusammenhang mit der Option FORCE.

Weitere hilfreiche Funktionen im Zusammenhang mit historisierten Statistiken sind get_stats_history_availability zur Rückgabe der ältesten verfügbaren Statistiken und get_stats_history_retention zur Ausgabe der Anzahl an Sicherungen.

Über die Prozedur alter_stats_history_retention(n) lässt sich die History Retention einstellen. n nimmt dabei einen der folgenden Werte ein:

• 0 - keine Historie
• 1 - unendlich, Statistiken werden nie gelöscht
• m - Anzahl Tage, 2 bis maximal 365000
• NULL - Default Anzahl an Tagen

Sammeln - nicht nur - aus Leidenschaft

Bereits in der Version 9 war die Erhebung von Statistiken für die Schemata SYS und SYSTEM erlaubt. Für Oracle 10g ist diese Aufgabe jetzt zur Pflicht geworden. Die folgende Prozedur sammelt alle benötigten Informationen:

DBMS_STATS.GATHER_DICTIONARY_STATS

Völlig neu dagegen ist die Möglichkeit, Statistiken für die sogenannten Fixed Objects zu sammeln. Hierbei handelt es sich im Wesentlichen um Speicherstrukturen im Shared Pool, welche über v$ Views sichtbar sind. Bis zum Redaktionsschluss haben wir damit noch nicht ausreichend gearbeitet, um Ihnen zuverlässige Informationen zu liefern. Die Prozedur heißt:

GATHER_FIXED_OBJECTS_STATS

Automatisierung

Neben der Historie gibt es weitere automatisierte Schritte in 10g. Das Tabellen Monitoring ist standardmäßig aktiv. Die Steuerung geschieht über den Parameter statistic_level=typical. Ändern sich mehr als 10 Prozent der Zeilen einer Tabelle, setzt Oracle die Statistiken auf STALE. Unter Oracle 9 ließ sich diese Eigenschaft mit dem Befehl ALTER TABLE ... MONITORING aktivieren.

Für Objekte ohne Statistiken und für Objekte mit Statistiken im Status STALE erhebt oder aktualisiert der Scheduler Job GATHER_STATS_JOB die Statistiken. Dieser Vorgang findet automatisiert über den neuen Scheduler statt. Für die täglichen Aufgaben des DBA ist das daher sicherlich eine der wichtigsten Neuerungen.

Liegen keine Statistiken vor oder sind die Statistiken im Status STALE, so führt die Datenbank häufiger als früher eine dynamische Statistikerhebung durch. Die Statistik wird vor der Ausführung für ein einzelnes Statement temporär erzeugt, aber nicht gespeichert. Gesteuert wird die dynamische Erhebung durch den Initialisierungsparameter optimizer_dynamic_sampling.

Fazit

Oracle unterstützt mit 10g offiziell nicht mehr den regelbasierten Optimizer - vorhanden ist er allerdings nach wie vor. Da der Befehl ANALYZE für zahlreiche Funktionen kein Äquivalent bietet, ist es nun an der Zeit, sich der komplexen Thematik der Statistikerhebung zu stellen. Und schließlich ist es besser, die eigenen Statistiken zu fälschen, als dem Zensus veralteter Regeln zu gehorchen.

Martin Hoermann (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen