oracle analyze table x compute statistics

[yesyes2008]

Hallo,

Vor kurzem wurden auf einer 9i die als Archiv genutzt, wird die Statistiken neu erstellt, was zuletzt vor einem Jahr durchgeführt wurde.

Seit dem sind in die betreffende Tabelle ~4Mio DS hinzugekommen, vor dem erstellen der Statistiken benötigte der Select <2 Sekunden, nach der Erstellung ~15 Sekunden.

Ich möchte wissen, ob sich das Erstellen von Statistiken für den cbo negativ auf die Laufzeit eines selects auswirken kann oder ob die Ursache eine Andere sein muß.

[dbwizard]

Hallo,

Ich möchte wissen, ob sich das Erstellen von Statistiken für den cbo negativ auf die Laufzeit eines selects auswirken kann oder ob die Ursache eine Andere sein muß.

Hallo,

- ja , kann es

Aber : Bitte benutze nicht mehr die COMPUTE STATISTICS. Verwende anstelle dessen das DBMS_STATS Package.

Dazu folgende Info:

dbms_stats is the stated, preferred method of collecting statisttics.

dbms_stats can analyze external tables, analyze cannot.

DBMS_STATS gathers statistics only for cost-based optimization; it does not gather other

statistics. For example, the table statistics gathered by DBMS_STATS include the number

of rows, number of blocks currently containing data, and average row length but not the

number of chained rows, average free space, or number of unused data blocks.

dbms_stats (in 9i) can gather system stats (new)

ANALYZE calculates global statistics for partitioned tables and indexes instead

of gathering them directly. This can lead to inaccuracies for some statistics, such as

the number of distinct values. DBMS_Stats won't do that.

Most importantly, in the future, ANALYZE will not collect statistics needed by

the cost-based optimizer.

Auszug aus:

Ask Tom "Analyze and DBMS_STATS"

Gruss

[carstenj]

Hi,

einfach mal den Ausführungsplan angucken. Du kannst die Statistiken ja anschließend wieder löschen, und den Ausführungsplan vergleichen.

[yesyes2008]

Ich danke Euch beiden, für die schnelle Hilfe, nach dem löschen der Statistiken lief der Select mit gewohnter Geschwindigkeit

Könnt ihr mir als Einsteiger den zusammenhäng vielleicht erklären ?

Ich bin davon ausgegangen, das die Statistiken lediglich für CBO Auswertungen benutzt werden, damit die Kosten genauer ermittelt werden können.

Wenn die Statistiken über dbms_stats ermittelt worden wären, hätte sich das ebenfalls so ausgewirkt oder wird das durch die Änderungen gegenüber compute_statistics verhindert ?

[carstenj]

Hi,

Ich bin davon ausgegangen, das die Statistiken lediglich für CBO Auswertungen benutzt werden, damit die Kosten genauer ermittelt werden können.

so ist das ja auch. Wobei die Kosten für de Optimizer als Entscheidungsgrundlage dienen, wie er den Ausführungsplan generieren soll.

Da klassische Fall, der zu Problemen führt, sind fehlende Indizies und fehlende/veraltete Statistiken. Ich vermute einfach mal, dass das auch hier der Fall ist: Entweder fehlt ein Index, oder der CBO berechnet die Kosten nicht korrekt, weil du in der Abfrage noch andere Tabellen involviert hast, die keine/veraltete Statistiken haben.

Der CBO macht eigentlich nur dann Sinn, wenn die Statistiken vorhanden und halbwegs aktuell sind, was ab Oracle 10g eigentlich auch durch Standardjobs gewährleistet wird, unter 9i aber noch nicht.

[Corto -sX-]

Eigentlich soll das DBMS_STATS der effizientere Weg sein, und er ist es auch in 98% der fälle. Es fallen eben weniger "unnütze" statistikdaten an, die eben für selects nicht nötig sind, eher für DBMS- interne Vorgänge.

Ich (bzw meine Kollegin) hatte aber z.b. hier einen Fall liegen, in dem eine PL/SQL Prozedur, die ein FIA bei uns geschrieben hat, nach einem compute statistics in etwa 40 minuten gelaufen ist, und nach dem DBMS_STATS dauert das ganze etwa 2 stunden.

Das ist aber der einzige Fall in dem mir DBMS_STATS bisher nicht gefallen hat.

[yesyes2008]

Da klassische Fall, der zu Problemen führt, sind fehlende Indizies und fehlende/veraltete Statistiken. Ich vermute einfach mal, dass das auch hier der Fall ist

Du hattest recht, es hat ein Index gefehlt der dazu geführt hat das die Abfrage mit neuen Statistiken länger gebraucht hat, nach dem einpflegen des Indexes und neu generieren mit dbms_stats läufts jetzt reibungslos.

Vielen Dank Euch allen für Eure Hilfe.

[dbwizard]

Du hattest recht, es hat ein Index gefehlt der dazu geführt hat das die Abfrage mit neuen Statistiken länger gebraucht hat, nach dem einpflegen des Indexes und neu generieren mit dbms_stats läufts jetzt reibungslos.

Vielen Dank Euch allen für Eure Hilfe.

Solche "Anomalitäten" lassen sich oftmals durch ein Trace der Session veranschaulichen, gerade wenn ein Index fehlt

Gruss