Statistiken unter Oracle9i Voraussetzung für effiziente SQL-Statements

Transkript

1 Statistiken unter Oracle9i Voraussetzung für effiziente SQL-Statements Autor: Sascha Schlangenotto, S&N AG netbank solutions DOAGNews Q2_2004 Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, bei auch nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes.

2 Motivation Statistiken zur Bestimmung eines optimalen Ausführungsplans erfahren eine immer größere Bedeutung für die Leistungsfähigkeit der Datenbank. Denn nur so kann der Optimizer (Cost Based Optimizer, CBO) die Ausprägungen und das Volumen der Daten berücksichtigen. Viele neue Features setzen sogar die Verwendung des CBO und damit aktuelle Statistiken voraus. Dazu zählen u.a.: Partitionierung von Tabellen und Indizes Parallele Abfragen und parallele DML-Anweisungen Star Transformationen und Star Joins Query Rewrite mit Materialized Views Von der Verwendung des Rule Based Optimizers, der nach einem starren Regelwerk arbeitet, ist auch aus dem Grund abzuraten, weil Oracle bereits angekündigt hat, diesen Optimizer Modus in der Oracle 10g Version zwar noch anzubieten, aber nicht mehr weiter zu supporten. Sichern der Statistiken Vor der Ermittlung neuer Statistiken sollten die aktuellen Statistiken gesichert werden, da die neuen Statistiken nicht unbedingt immer zu besseren Ausführungsplänen und damit schnelleren Antwortzeiten führen. Durch die neuen Statistiken könnte ein Schwellwert überschritten werden, der den Optimizer zu einem anderen Ausführungsplan für ein SQL- Statement veranlasst. In der Regel ist der neue Ausführungsplan besser als der alte, aber eben nicht immer. Oracle hat u. a. aus diesem Grund mit dem Package dbms_stats die Möglichkeit geschaffen, Statistiken zu sichern, bevor neue erzeugt werden. Falls sich die neuen Statistiken als nachteilig herausstellen, können die alten Statistiken mit wenig Aufwand kurzfristig wieder eingespielt werden. Interessant ist auch das Sichern der Statistiken im Produktionsumfeld, um diese auf einem Entwicklungssystem einzuspielen. Die Qualität der entwickelten Abfragen hinsichtlich Performance könnte so besser im Entwicklungsumfeld berücksichtigt werden, selbst wenn das Datenvolumen dort geringer ist. Für die Aufnahme der sonst im Data Dictionary gespeicherten Statistiken ist mindestens eine Tabelle anzulegen. Mindestens bedeutet, dass für eine Datenbank insgesamt eine oder aber für jedes Schema eine Tabelle zur Aufnahme der historischen Statistiken angelegt werden kann. Durch folgende Anweisung wird im Schema SCOTT die Tabelle SCOTT_STATISTIKEN bereitgestellt: execute dbms_stats.create_stat_table ('SCOTT', 'SCOTT_STATISTIKEN') Damit die Statistiken anderer User in der Tabelle SCOTT_STATISTIKEN abgelegt, später abgefragt und gelöscht werden können, müssen alle User, die diese Tabelle verwenden wollen, folgendes Recht bekommen: GRANT SELECT, UPDATE, INSERT, DELETE ON SCOTT_STATISTIKEN TO <user>; Alle Statistiken des Schemas SCOTT können wie folgt exportiert werden: execute dbms_stats.export_schema_stats ( -

3 ownname => 'SCOTT', statown => 'SCOTT', stattab => 'SCOTT_STATISTIKEN', - statid => 'SCOTT Statistiken vom ') Parameter ownname stattab statown statid Bedeutung Schema, dessen Statistiken exportiert werden sollen. Bestimmt, in welcher Tabelle die Statistiken historisiert werden. Gibt das Schema an, in der die über stattab angegebene Tabelle enthalten ist. Diese Id, die selber zu vergeben ist, ist für das Zurückspielen der Statistiken in das Data Dictionary erforderlich. Eine Sicherung der aktuellen Statistiken ist auch im Rahmen der Aktualisierung der Statistiken möglich. Erzeugen der Statistiken Statistiken können für Tabellen, Indizes und für das System erstellt werden. Sobald neue Statistiken für Tabellen oder Indizes zur Verfügung stehen, werden per Default die im Library Cache hinterlegten Ausführungspläne ungültig. Bei erneuter Ausführung eines Statements werden so die neuen Statistiken berücksichtigt. Die Generierung von System-Statistiken hingegen hat nur auf die Ausführungspläne neuer Statements Einfluss. Oracle 9i bietet verschiedene Verfahren, um Tabellen/Indizes bzw. Schemata zu analysieren: Package dbms_stats SQL Befehl ANALYZE TABLE Prozedur dbms_utility.analyze_schema Die Verwendung des Packages dbms_stats wird von Oracle für 9i Datenbanken ausdrücklich empfohlen. Statistiken können u. a. parallel erstellt werden (gilt nicht für Indizes), vom Administrator gezielt angepasst werden, oder sie können sogar für die I/O und CPU Leistungsfähigkeit des Servers generiert werden. Entscheidend ist auch, dass Oracle für die Zukunft angekündigt hat, nur noch Statistiken zu berücksichtigen, die mit diesem Package erstellt wurden. Der ANALYZE Befehl wird jedoch noch benötigt, um z. B. Angaben über verkettete Zeilen zu erhalten. Die Prozedur analyze_schema schließlich wird nur noch aus Gründen der Abwärtskompatibilität angeboten. Wenn beim Aufruf der im Folgenden beschriebenen Prozeduren der Fehler ORA-00933: SQL-Befehl wurde nicht korrekt beendet gemeldet wird, hilft folgender Workaround: ALTER SESSION SET NLS_NUMERIC_CHARACTERS='.,'; Statistiken auf verschiedenen Ebenen Statistiken können für Datenbankobjekte wie Tabellen und Indizes inklusive möglicher Partitionen und außerdem auf System-Ebene erstellt werden. Darüber hinaus kann für Tabellen differenziert werden, auf welchem Niveau Statistiken generiert werden, wie die folgende Tabelle zeigt.

4 Niveau Art der erstellten Information (Auszug) / Verwendung Views zur Abfrage der Statistiken Tabelle Spalte, ohne Histogramm Anzahl der Zeilen, durchschnittliche Satzlänge / Bei einer kleinen Tabelle ist ein Full Table Scan effizienter als der Umweg über einen Index. Anzahl der unterschiedlichen Ausprägungen der Spalte / Wenn es wenige unterschiedliche Werte im Verhältnis zur Anzahl der Zeilen gibt, ist die Selektivität gering. Die Verwendung eines Indexes kann deshalb schlecht sein. user_tables, all_tables, dba_tables, user_tab_col_statisti cs, all_tab_col_statistics, dba_tab_col_statistic s Spalte, mit Histogramm Verteilung der Daten wird bestimmt (Histogramme) / Selbst wenn die Selektivität einer Spalte gering ist, ist die Verwendung eines Indexes bei einem seltenen Wert in der Verteilung vorteilhaft. Beispiel: Eine Tabelle enthält Zeilen. In der Spalte gibt es 3 verschiedene Werte (Werte 1 und 2: je mal, Wert 3: 1 mal). Bei der Abfrage auf =3 ist ein Index sehr effizient, bei Abfrage auf =1 oder =2 hingegen nicht. user_tab_histograms, all_tab_histograms, dba_tab_histograms Da die Erstellung von Histogrammen Zeit und Platz im Data Dictionary kostet, sollten diese nur für Spalten erstellt werden, die häufig in einer WHERE-Klausel verwendet werden und deren Werte nicht gleichverteilt sind. Beim Vergleich einer Spalte mit einer Bindevariable sind Histogramme nicht von Vorteil, da der Ausführungsplan erstellt wird, bevor der Wert der Bindevariable ausgewertet wird. Statistiken für das Schema SCOTT können wie folgt angelegt werden: execute dbms_stats.gather_schema_stats ( - ownname => 'SCOTT', block_sample => FALSE, - estimate_percent => dbms_stats.auto_sample_size, options => 'gather', - method_opt => 'FOR ALL INDEXED COLUMNS SIZE AUTO', - cascade => TRUE, stattab => 'SCOTT_STATISTIKEN', - statown => 'SCOTT', statid => 'SCOTT Statistiken ') Parameter estimate_percent block_sample method_opt options Bedeutung Legt fest, wie viele Datensätze der Tabelle Oracle bei der Ermittlung der Statistiken lesen soll. Zu wenige können zu Statistiken führen, die die reale Situation nicht richtig wiedergeben. Je höher der Wert ist, desto größer ist auch die Last. Mögliche Werte: NULL: Alle Datensätze werden betrachtet (entspricht einem Compute; Default). Zwischen und 100, z. B. 10 für 10 Prozent (entspricht einem Estimate). dbms_stats.auto_sample_size: Oracle legt die Anzahl der betrachteten Datensätze selber fest. Erlaubt bei einem Estimate die Differenzierung, immer ganze Blöcke oder einzelne Datensätze aus einer größeren Menge von Blöcken zu lesen. Mögliche Werte: True: Es werden ganze Blöcke gelesen (schnell, aber u. U. nicht genau genug, wenn die Daten nicht gleichverteilt auf der Festplatte gespeichert sind). False: Einzelne Datensätze werden gelesen (genauer, aber langsamer; Default). Bestimmt, welche Statistikarten erzeugt werden sollen. Mögliche Werte: For columns: Berücksichtigt nicht die Ausprägungen der einzelnen Spalten. For columns <Spalte1>, : Berücksichtigt die Ausprägungen der Spalten. For all columns size 1: Berücksichtigt die Ausprägungen aller Spalten (Default). For all columns size auto: Berücksichtigt die Ausprägungen aller Spalten und legt, wenn Oracle dies für sinnvoll hält, Histogramme an. For all indexed columns size auto: Berücksichtigt nur die Ausprägungen aller indizierten Spalten und legt für diese, wenn Oracle dies für sinnvoll hält, Histogramme an. Die Objekte, für die neue Statistiken erzeugt werden sollen, können eingeschränkt werden. Mögliche Werte:

5 cascade objlist gather: Alle Tabellen werden analysiert (Default). gather auto: Es werden alle Tabellen analysiert, die entweder noch keine Statistiken besitzen oder bei denen sich mehr als 10 % der Datensätze geändert haben. Die Art, wie analysiert wird, wird von Oracle festgelegt (z. B. mit oder ohne Histogramme). Deshalb haben lediglich noch folgende andere Parameter Bedeutung: ownname, statown, stattab, statid und objlist. gather stale: Aktualisiert nur die Tabellen, bei denen sich mehr als 10 % der Datensätze geändert haben (Tabellen, die noch keine Statistiken haben, werden nicht analysiert). gather empty: Nur Tabellen ohne Statistiken werden analysiert. list auto / list stale / list empty: Gibt eine Liste aller Objekte über den Parameter objlist zurück, die bei Verwendung von gather auto / gather stale / gather empty analysiert werden würden. Steuert, ob auch Statistiken für die Indizes erstellt werden. Mögliche Werte: FALSE: Indexstatistiken werden nicht erstellt (Default). TRUE: Indexstatistiken werden erstellt. Liefert eine Liste aller Objekte, die entweder analysiert wurden (bei gather auto, gather stale, gather empty) oder analysiert werden würden (bei list auto, list stale, list empty). Der Parameter ist vom Typ dbms_stats.objecttab. Bei Verwendung der Parameter statown, stattab und statid werden die alten Statistiken gesichert, bevor die neuen ermittelt und damit in das Data Dictionary übernommen werden. Voraussetzung für die Verwendung der Optionen gather stale und gather auto ist, dass das Monitoring für die betreffenden Tabellen des Schemas eingeschaltet ist. Das Monitoring für alle Tabellen des Schemas SCOTT wird aktiviert durch: execute dbms_stats.alter_schema_tab_monitoring('scott', TRUE) Für einzelne Tabellen wird das Monitoring so aktiviert: ALTER TABLE <Tabellenname> MONITORING; Danach kann Oracle selbst ermitteln, welche Statistiken neu erstellt werden müssen. Um zu bestimmen, wie viele Datensätze sich in einer Tabelle geändert haben, werden die user/all/dba_tab_modifications Views verwendet. Diese stellen nach einer DML-Anweisung die aktuelle Anzahl geänderter Sätze erst mit Verzögerung bereit (bis zu 15 Min. bei Oracle 9i, bis zu 3 St. bei Oracle 8i). Durch den Aufruf execute dbms_stats.flush_database_monitoring_info als DBA User kann die Aktualisierung erzwungen werden. Bevor die Prozedur gather_schema_stats ausgeführt oder die Datenbank heruntergefahren wird, werden die Werte im Data Dictionary ebenfalls aktualisiert. Die Liste aller Objekte, die mit gather auto beim nächsten Analyselauf betrachtet werden würden, kann über den Parameter objlist wie folgt abgefragt werden: DECLARE needanalyze dbms_stats.objecttab; BEGIN dbms_stats.gather_schema_stats ( ownname => 'SCOTT', options => 'list auto', cascade => TRUE, objlist => needanalyze); FOR i IN 1..needAnalyze.count LOOP dbms_output.put_line ( needanalyze(i).objname ' ' needanalyze(i).objtype); END LOOP; END;

6 Empfehlung Für kleinere und mittlere Datenbanken ist die Option gather auto gut geeignet, da der Administrationsaufwand gering und die Laufzeit der Statistikerstellung noch kalkulierbar ist. Dafür ist lediglich die Prozedur gather_schema_stats, z.b. über einen Datenbank-Job, periodisch aufzurufen. Mehr Kontrolle über die Art wie analysiert wird, erlaubt die Option gather stale. Da diese Objekte ohne Statistiken nicht betrachtet, sollte gegebenenfalls zusätzlich ein Aufruf mit gather empty erfolgen. Auf diese Weise ist die Laufzeit immer geringer, als wenn über die Option gather einfach alle Objekte des Schemas analysiert werden würden. Bei sehr großen Datenbanken ist das gezielte Analysieren einzelner Tabellen über die hier nicht beschriebene Prozedur dbms_stats.gather_table_stats jedoch meist die bessere Wahl. Erzeugen von Statistiken auf System-Ebene Um die Leistungsfähigkeit der Hardware bei der Erstellung von Ausführungsplänen zu berücksichtigen, empfiehlt Oracle, Systemstatistiken zu erstellen: execute dbms_stats.gather_system_stats ( - gathering_mode => 'interval', interval => 2, statown => 'SCOTT', - stattab => 'SCOTT_STATISTIKEN', statid => 'System-Statistiken ') Parameter gathering_mode interval Bedeutung Legt fest, in welchem Zeitraum System-Daten gesammelt werden: Noworkload: Die Statistiken werden nur aus Oracle internen Default Werten erzeugt. Eine reale Last wird nicht betrachtet. Dieser Modus bietet nur mäßige Statistiken und sollte nur für die Entwicklungsphase verwendet werden. Interval: Für die Dauer des Intervalls wird auf Basis der realen Last die System-Statistik erstellt. Der Parameter interval spezifiziert die Dauer. Start Stop: Startet bzw. beendet die Beobachtung des Systems. Angabe der Länge des Intervalls in Minuten (nur für den Modus Interval) Anders als bei den Prozeduren zur Erstellung der Tabellen- und Schemastatistiken, werden die Systemstatistiken nur dann sofort in das Data Dictionary übernommen, wenn die stat* Parameter nicht angegeben werden. Anderenfalls werden die neuen Statistiken nur in die durch stattab angegebene Tabelle geschrieben. Zur Aktivierung müssen die Statistiken dann noch (als DBA) importiert werden: execute dbms_stats.import_system_stats ( - statown => 'SCOTT', stattab => 'SCOTT_STATISTIKEN', - statid => 'System-Statistiken ') Die aktuellen Systemstatistiken können über die Tabelle sys.aux_stats$ abgefragt werden. Anpassen von Statistiken Wenn die Anzahl der Datensätze in einer Tabelle gering ist und nicht die Möglichkeit besteht, Statistiken aus der Produktionsumgebung zu importieren, können die Statistiken über die Prozeduren set_table_stats und set_column_stats des Packages dbms_stats manipuliert werden. So kann auch bei einer geringen Datenmenge das Verhalten des Optimizers geprüft werden. Wiederherstellung der Statistiken Die Wiederherstellung der gespeicherten Statistiken des Schemas SCOTT mit der Id "SCOTT Statistiken " geschieht z. B. wie folgt:

7 execute dbms_stats.import_schema_stats ( - ownname => 'SCOTT', statown => 'SCOTT', stattab => 'SCOTT_STATISTIKEN', - statid => 'SCOTT Statistiken ') Dabei ist auf die richtige Angabe der statid zu achten, da keine Fehlermeldung erzeugt wird, wenn eine statid angegeben wird, die gar nicht in der Tabelle SCOTT_STATISTIKEN vorhanden ist. Zusammenfassung Die Bereitstellung von aussagekräftigen Statistiken ist von zentraler Bedeutung für den optimalen Betrieb der Datenbank. Für jede Datenbankgröße und Anwendung bietet Oracle mit dem Package dbms_stats geeignete Prozeduren zur Umsetzung einer Strategie für das Exportieren, Erstellen und Importieren von Statistiken für Tabellen, Indizes, Partitionen und das System selbst an. Weitere Beispiele zu diesem Thema, die insbesondere die Verwendung von Histogrammen verdeutlichen, können gerne per Mail angefordert werden. Kontakt: Sascha Schlangenotto S&N AG Tel.: 05251/ netbank solutions Fax: 05251/ Klingenderstr. 5 Internet: D Paderborn Mail: sschlangenotto@s-und-n.de