Stabilitätsproblem bei verschiedenen System

[erazor125]

Hallo Entwickler-Team,

ich suche Hilfe bei einem bereits länger bestehenden Problem unseres Oracle-Systems.

System: Oracle 10g, Version 10.2.0.4.0


Programm:
Wir arbeiten an einem größeren PL/SQL-Programm zur Datenkonsolidierung.
Zu Beginn werden mehrere Datendateien per SQL-Loader in die Datenbank in eine Ladetabelle gepumpt.
Auf dieser Tabelle werden anschließend mehrere Arbeitsschritte (Updates) getätigt.
Nach Abschluss der verschiedenen Schritte werden gültige Daten in eine andere Tabelle übertragen.


Problem:
Wir arbeiten intern auf einem Testsystem, auf welchem der Prozess ohne Probleme mit einer Gesamtlaufzeit von 40 - 50 min abläuft.
Bei dem System unseres Kunden ist ebenfalls Oracle 10g installiert, nur ein anderer Patch (10.2.0.3.0).
Ansonsten ist das System von der Ausstattung gleich oder stärker (Prozessor, Ram usw...).

Leider treten jedoch bei bestimmten Schritten immer wieder Performanceprobleme auf.
Einfache Statements die bei uns in wenigen Sekunden abgeschlossen sind, benötigen bei unserem Kunden mehrere Stunden und Tage.
Einziges bisher bekanntes Problem ist eine Fehlentscheidung bei den Ausführungsplänen.

Aufgrund dieser Fehlentscheidung haben wir bereits Statementoptimierung (Hints usw.) probiert und versucht, mit Hilfe von
gespeicherten Ausführungsplänen (Outlines) dem Problem entgegenzuwirken, jedoch leider ohne optimalen Erfolg.

Ich bin daher auf der Suche nach Hilfe im Bereich Systemstabilität
bzw suche Statements für Systemtabellen oder andere Möglichkeiten die Stabilität einer Instanz auszulesen/verbessern.

Ich hoffe hier kann jemand helfen.
Bin leider nach etlichen Versuchen und Lösungsmöglichkeiten langsam ratlos

[jonathan]

Hallo erazor125,

handelt es sich bei eurem System um ein DWH (Data-Warehouse)?
Wenn ja ist die Frage, ob bei der Installation und Konfiguration der Datenbank die richtigen Parameter gesetzt wurden. Ich hatte in vergangener Zeit ein ähnliches Problem.

[erazor125]

Nein, es handelt sich nicht um ein DWH, es stellt aber ähnliche Funktionen dar.

Das ganze ist eigentlich nur ein ca. 5000 Zeilen großes Package das mehrere Updates, Inserts usw ausführt.

Und hier kommt es wie bereits gesagt bei manchen Stellen zu den Problem das er sich aus irgendwelchen Gründen für falsche Ausführungspläne entscheidet die dann so schlecht ausfallen das er statt 30 Sekunde mehrere Stunden beschäftigt ist

[dbwizard]

Nein, es handelt sich nicht um ein DWH, es stellt aber ähnliche Funktionen dar.

Das ganze ist eigentlich nur ein ca. 5000 Zeilen großes Package das mehrere Updates, Inserts usw ausführt.

Und hier kommt es wie bereits gesagt bei manchen Stellen zu den Problem das er sich aus irgendwelchen Gründen für falsche Ausführungspläne entscheidet die dann so schlecht ausfallen das er statt 30 Sekunde mehrere Stunden beschäftigt ist

- Nun, ich denke, Sachen wie fehlende Indizies und Statistiken hast du sicher schon überprüft. ich würde an deiner Stelle einen Trace des ganzen Prozesses auf der Produktionsdatenbank und vielleicht als Vergleich auch auf dem Testsystem durchführen. Du benötigst bessere Informationen über das Problem, ansonsten tapst du nur im Dunkeln. Ist die Datenmenge auf beiden System den in etwa vergleichbar ?


Gruss

[erazor125]

Die Daten auf dem System sind die gleichen. Wir bekommen diese vom Kunden zum Testen als in Sachen Datenmenge, Qualität ist es das gleiche.

Jap, liegst du richtig, in Sachen Indizes und Statistiken ist bereits ausführlich optimiert, validiert usw. Also daran kann es sicher nicht liegen.

Wie gesagt, das einzige was auffällt, ist der Ausführungsplan. Bei uns entscheidet sich der CBO und wählt einen anderen Plan wodurch die Ausführung ins Unentliche läfut.

Aber warum?!

[Bernhard Geyer]

Kann der Kunde nicht updaten? Evtl. wurde genau dieses Problem mit dem Update gelöst.

Wo die Fixliste zu finden ist findest du hier

[dbwizard]

Die Daten auf dem System sind die gleichen. Wir bekommen diese vom Kunden zum Testen als in Sachen Datenmenge, Qualität ist es das gleiche.

Jap, liegst du richtig, in Sachen Indizes und Statistiken ist bereits ausführlich optimiert, validiert usw. Also daran kann es sicher nicht liegen.

Wie gesagt, das einzige was auffällt, ist der Ausführungsplan. Bei uns entscheidet sich der CBO und wählt einen anderen Plan wodurch die Ausführung ins Unentliche läfut.

Aber warum?!

- Deswegen hilft dir ein Trace eventuell weiter...

[jonathan]

Ich glaube das war bei der 10g DB noch nicht dabei ab, aber es gibt eine Weboberfläche, über die man die DB auch gut managen kann. Bei 11g heißt diese Funktionalität Oracle 11g Enterprise Manager.

In diesem Webinterface kann man sehr gut die ein- und ausgehenden Prozesse der Datenbank überwachen und jede einzelne Session auf Performance untersuchen kann. In einem Seminar habe ich einmal mitbekommen, wie man durch diese Zusatzfunktion Performance-Engpässe lösen kann.

Für Konsolenfreunde ist es NICHTS, aber für grafische Auswertungen und etwas grafische Administration sehr gut.

Vielleicht kannst du damit etwas herausfinden?!

[dbwizard]

Ich glaube das war bei der 10g DB noch nicht dabei ab, aber es gibt eine Weboberfläche, über die man die DB auch gut managen kann.

HI,

Was war bei 10g noch nicht dabei ?

[jonathan]

Bin mir nicht ganz sicher... ggf. als optionale Funktion.

[dbwizard]

Bin mir nicht ganz sicher... ggf. als optionale Funktion.

Du meinst den Enterprise Manager ?


Gruss

[jonathan]

Wie im vorherigen Beitrag schon beschrieben, ja.

[dbwizard]

Wie im vorherigen Beitrag schon beschrieben, ja.

- Den Enterprise Manager gab's im 10 er schon, allerdings ist er eine kostenpflichtige Option (für den produktiven Betrieb). Dabei seit der 10 er und "Kostenlos" ist das Database Control


Gruss

[dimitri]

Aufgrund dieser Fehlentscheidung haben wir bereits Statementoptimierung (Hints usw.) probiert und versucht, mit Hilfe von
gespeicherten Ausführungsplänen (Outlines) dem Problem entgegenzuwirken, jedoch leider ohne optimalen Erfolg.

Was bedeutet ohne Erfolg? Haben sich die Pläne nicht geändert oder war die Laufzeit trotz besserer Pläne zu lange?

Ich bin daher auf der Suche nach Hilfe im Bereich Systemstabilität

Naja stabil ist es, aber nicht performant genug

bzw suche Statements für Systemtabellen oder andere Möglichkeiten die Stabilität einer Instanz auszulesen/verbessern.

Ich würde die Finger von diversen Statements lassen, die aus Systemtabellen irgendwelche Werte auslesen. Wenn man diese Statements nicht selbst schreiben kann, dann ist es meistens auch so, dass man nicht weiß was diese Werte genau besagen.

Ich hoffe hier kann jemand helfen.

Habt ihr euer Programm instrumentiert? Sprich schreibt ihr Logausgaben mit Zeiten etc. in eine Tabelle weg (eine der wenigen Methoden, bei denen autonome Transaktionen sinnvol sind).
Wisst ihr welche Statements die größten Probleme bereiten?
Habt ihr die Cardinalitäten der Pläne dieser Statements verglichen?

Jap, liegst du richtig, in Sachen Indizes und Statistiken ist bereits ausführlich optimiert, validiert usw. Also daran kann es sicher nicht liegen.

D.h. ihr exportiert nicht nur die Daten aus der produktiven Umgebung sondern auch die Statistiken, importiert beide in die Entwicklungsumgebung und trotzdem treten unterschiedliche Pläne auf? Oder erzeugt ihr eigene Statistiken? Diese können nämlich durchaus unterschiedlich sein, da auch die Tabellen anders sind. Die Daten sind identisch, aber die interne Belegung und Anordnung der Blöcke ist bei einer DB die lange in Betrieb ist und einer DB die frisch per imp oder impdp geladen wurde durchaus gravierend anders.

Aber warum?!

Unterschiedliche Statistiken. Z.B wird ab 10g defaultmäßig nicht mehr das I/O basierte Kostenmodell verwendet, sondern das CPU basierte. D.h. der CBO weiß auch wie die Hardware aussieht und wie schnell sie ist. Dafür gibt es sog. Systemstatistiken, die ebenfalls über das dbms_stats Package erzeugt werden. Wollt ihr wirklich identische Systeme haben, müsst ihr auch diese berücksichtigen (standardmäßig gibt es hier Defaulteinstellungen).

Einen 10046 Trace würde ich jetzt nicht unbedingt als erstes machen, denn auch hier gilt das gleiche wie bei den Systemtabellen.

Eher sinnvoll wäre ein 10053 Trace, der dir zeigt welche Möglichkeiten der CBO durchrechnet und von welchen Voraussetzungen er ausgeht, allerdings muss man auch diesen Trace lesen können.

Die Interpretation eines mit dbms_xplan erzeugten Plans zeigt meist auch schon falsche Werte bei Kardinalitäten etc.

Dim

[erazor125]

Wir selbst verwenden Oracle Enterprise Manager auch intern, der Kunde jedoch leider nicht, daher können wir das nicht genau analysieren damit.

Bekommen jetzt aber mal einen report mit statspack, vllt hilft das weiter.

haben bis jetzt nur versucht mit hausmitteln wie outlines, ausfürhungsplananalyse usw dem problem entgegenzuwirken, jedoch ohne erfolg.

ich hoffe mal die report aus statspack oder ähnlichem bringen hier mehr aufschluss