yesyes2008 Geschrieben 17. Dezember 2009 Teilen Geschrieben 17. Dezember 2009 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ß. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
dbwizard Geschrieben 17. Dezember 2009 Teilen Geschrieben 17. Dezember 2009 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 Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
carstenj Geschrieben 17. Dezember 2009 Teilen Geschrieben 17. Dezember 2009 Hi, einfach mal den Ausführungsplan angucken. Du kannst die Statistiken ja anschließend wieder löschen, und den Ausführungsplan vergleichen. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
yesyes2008 Geschrieben 17. Dezember 2009 Autor Teilen Geschrieben 17. Dezember 2009 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 ? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
carstenj Geschrieben 17. Dezember 2009 Teilen Geschrieben 17. Dezember 2009 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. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Corto -sX- Geschrieben 17. Dezember 2009 Teilen Geschrieben 17. Dezember 2009 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. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
yesyes2008 Geschrieben 17. Dezember 2009 Autor Teilen Geschrieben 17. Dezember 2009 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. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
dbwizard Geschrieben 17. Dezember 2009 Teilen Geschrieben 17. Dezember 2009 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 Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Empfohlene Beiträge
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.