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
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.
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?!
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.
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
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?
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?
Wisst ihr welche Statements die größten Probleme bereiten?
Habt ihr die Cardinalitäten der Pläne dieser Statements verglichen?
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.
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).
EDIT:
sorry doppelt gepostet
Comment