Zum Inhalt springen

oracle analyze table x compute statistics


yesyes2008

Empfohlene Beiträge

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ß.

Link zu diesem Kommentar
Auf anderen Seiten teilen

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

Link zu diesem Kommentar
Auf anderen Seiten teilen

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 ?

Link zu diesem Kommentar
Auf anderen Seiten teilen

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.

Link zu diesem Kommentar
Auf anderen Seiten teilen

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.

Link zu diesem Kommentar
Auf anderen Seiten teilen

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.

Link zu diesem Kommentar
Auf anderen Seiten teilen

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

Link zu diesem Kommentar
Auf anderen Seiten teilen

Dein Kommentar

Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung wiederherstellen

  Nur 75 Emojis sind erlaubt.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

Fachinformatiker.de, 2024 by SE Internet Services

fidelogo_small.png

Schicke uns eine Nachricht!

Fachinformatiker.de ist die größte IT-Community
rund um Ausbildung, Job, Weiterbildung für IT-Fachkräfte.

Fachinformatiker.de App

Download on the App Store
Get it on Google Play

Kontakt

Hier werben?
Oder sende eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×
×
  • Neu erstellen...