Stabilitätsproblem bei verschiedenen System

[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


@dim

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

die pläne haben sich schon geändert. wenn man den executionplan anzeigen lässt ist err wie er sein soll, jedoch innerhalb des prozesses aufgrund vonvielen update entscheidet sich der optimizer anders.

dbms_stats.gather_table_stats läuft dazwischen ebenfalls, trotzdem findet er auf dem system des kunden irgendeinen grund sich für einen anderen plan zu entscheiden.

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?

Das Programm ist aus eigener Entwicklung, und es gibt natürlich ein logtabelle in die wir regelmäßig im prozess loggen diese laufen auch über autonome transaktionen.

zur zeit ist es eigentlich immer das selbe statement, aber im gesamten schon dritte, bei den anderen zwei konnten wir durch statementoptimierung helfen. aber da es einfach problematisch ist wenn wir jedes mal optimierne müssen weil sich die software auf anderen systemen nicht verhält wie sie soll.
daher sind wir auf der suche nach stabilität.

Wie meinst du das mit der Kardinalität der Pläne?!

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.

Von dem Produktivsystem bekommen wir nur daten. unsere entwicklungsumgebung erzeugt selbst statistiken, jedoch nach dem gleichen schema. während des prozesses werden des öfteren mit hilfe von dbms_stats die statistiken aktualisiert.

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

Die Systeme sind in Sachen Version ja identisch, bis auf den Versionsunterschid des Patches. Die konfiguration ist beim kunden stärker (ram, prozessor ...), also sollte doch bei einem stärkeren system eigentlich auch schneller gearbeitet werden können oder lieg ich da falsch?



EDIT:
sorry doppelt gepostet

[dimitri]

Wie meinst du das mit der Kardinalität der Pläne?!

Ich meine damit die Kardinalitäten, die in den Ausführungsplänen angegeben sind. Große Abweichungen deuten hier hier auf falsche Berechnungen hin.

Die konfiguration ist beim kunden stärker (ram, prozessor ...), also sollte doch bei einem stärkeren system eigentlich auch schneller gearbeitet werden können oder lieg ich da falsch?

Nicht unbedingt. Z.B. kann ein Prozessor Upgrade auch zu einer Verlangsamung führen, wenn z.B. die Festplatte der Flaschenhals war. Dann werden auf ein eh schon zu langsames Device ggf. noch mehr Anfragen losgeschickt. Nach der Formel Responsetime=Servicetime*Requests kann die Performance hier auch noch mehr in den Keller gehen. War aber nur ein Beispiel und nicht auf euch gemünzt.

Habt ihr schon mal die Konfigurationen verglichen? Nur weil eine Maschine mehr RAM hat muss der ja nicht auch genutzt werden. Gibts Unterschiede in diversen CBO Einstellungen? Insb. cursor_sharing, optimizer_index_cost_adj, SGA_* Parameter, PGA_AGGREGATE_TARGET, dynamic_sampling und last but not least dem optimizer_mode
Wär auch mal interessant zwei unterschiedliche Ausführungspläne zu sehen.

Sind die schon erwähnten Systemstatistiken identisch?

Ich lösche übrigends in Batchläufen bei Tabellen, die während der Verarbeitung nach und nach befüllt werden vorher z.T. bewußt die Statistiken, arbeite dann mit dem dynamic_sampling Hint und lasse Oracle hier kurz on-the-fly drüberschauen. Insb. bei GTTs ist das empfehlenswert (dort könnten Statistiken sowieso nur manuell gesetzt werden), aber auch wenn es sich um stark volatile Tabellen handelt.
Die Ausführungspläne sind meinen Erfahrungen nach sehr gut und das vorherige Löschen der Statistiken entfert auch ein ggf. schon vorhandenes Statement aus dem Library Cache (was z.B. ein dynamic sampling von Oracle verhindern würde)

Um welche Edition handelt es sich denn bei euch? Evtl. ist nämlich auch der Einsatz des Parallel Hints denkbar. Damit kann ein Mehrkernsystem im Batchbetrieb erst richtig ausgereizt werden.