DB2 Stored Procedure Langsam

[r3v0]

Hallo Zusammen... Wieder einmal eine Frage...

Und zwar habe ich Zwei Select Befehle und eine riesige und eine noch größere View.

Der erste Select ist schnell und geht auf die riesige View.

Der Zweitebefehel zickt ziemlich rum.
Wenn ich diesen Select einzel auf die Datenbank abfeuer ist er beim ersten mal sehr Langsam was aber okay ist. Wenn ich ihn direkt danach wieder abfeuer ist er ziemlich schnell so wie ich es haben will quasi.

Das Ganze ist in eine StoredProc gepackt worden Und mit einen Union verknüpft. Beim Call von der Storedproc braucht er ca 10 Sekunden.

Wenn ich den Zweiten Select auskommentier braucht die Stored Procedure ca 600ms. Jedoch wenn ich den ersten Select befehel auskommentiere und nur den etwas langsameren drauf los lasse braucht die Stored Procedure ganze 8 Sekunden bis was zurück kommt.

Auch nach mehrmaligen ausführen wird sie nicht schneller.

Jetzt habe ich schonmal was von Optimierung gehört das ein Select etwas losschickt um den Perfekten Weg zu suchen und dies nach öfteren wiederholen optiemiert. Jedoch Eine Stored Procedure macht dies nicht.

gibt es eine Möglichkeit dies zu optieren.

Wie gesagt die beiden Views sind eigentlich komplett gleich bis auf ein Datenfeld was noch extra genommen wird.

Die Selects sind auch gleich bis das sie halt auf die verschiedenen Views gehen.

Falls es einer verstehet und mir helfen kann vielen vielen dank im vorraus

r3v0

[Der_Unwissende]

Hi,

Optimierungen basieren i.d.R. auf Kostenmodellen, die vorher erstellt werden müssen. Je nach dem wie Dein DBMS eingestellt ist, wird hier mehr oder weniger Zeit für den Optimierer/das Erstellen eines genauen Kostenmodells eingeplant. Ich denke das, worauf Du Dich beziehst ist vorallem das manuelle Erstellen eines solchen Kostenplans. Dazu musst Du auf jede Relation in Deiner DB die Funktion run stats on table aufrufen (ist jetzt DB2 spezifisch!).

So ein erstelltes Kostenmodell sollte die Perfomance steigern können, allerdings musst Du hier darauf achten, dass Du diese Modelle auch regelmässig auffrischen musst (machen nur Sinn, wenn sie halbwegs repräsentativ/aktuell sind). Besser ist es immer, wenn Du schon im Vorfeld optimierst. Da stellt sich hier (bei 8 Sek. Bearbeitungszeit) schon die Frage, wie weit das schon der Fall ist. Um was für eine Anfrage handelt es sich denn? Wieviele Relationen werden denn verknüpft? Sind die mit einem Index versehen? Wenn nicht, gibt es einen guten Grund (also >> Änderungen an den Relationen)? Falls die mit einem Index versehen sind, passt der zu der Art von Anfrage? (also im Sinne dass Du nicht Hashfunktionen für Bereichsanfragen verwendest).

Gruß Der Unwissende

[r3v0]

Hallo Danke für die Umfassende Antwort.

Wir haben die ganze Anfrage nun auf 771 MS runtergebracht was noch passt.

Die View hatte 5 bzw 6 Große Tabellen verknüpft. Allgemein läuft die Optimierung ganz gut. Wir hatten nur eine Abfrage drin die verschiedene felder auf NULL überprüft hat. dies hat den ganzen Befehl auf die 10 sekunden gebracht.

Bzw ich übergebe der Procedure wenn es gut läuft 5 ID´s wenn es "schlecht" läuft nur 3 dann muss ich den anderen beiden den wert -1 geben und so findet er nichts in den tabellen wenn er nichts findet überprüft er auf NULL was so beabsichtigt ist.

Die Abfrage NULL rausgenommen lief alles rund. Jetzt denke ich das ich eine Abfrage in den SQL Befehl reinsetze ob die zutreffenden ID´s -1 sind ... Dann soll er auf Is NULL überprüfen. Anders kann ich es mir nicht vorstellen es zu lösen.


Die View hat soweit ich weiß keinen Index. Haben Views überhaupt Indexe?

so wie es immoment läuft ist es okay. Mal schauen was passiert wenn die Abfragen drin sind

Nochmals danke für die Schnelle Umwandlung. Werd mal mit meienn Chef drüber sprechen.

[Der_Unwissende]

Zitat von r3v0:

Die View hat soweit ich weiß keinen Index. Haben Views überhaupt Indexe?

Das View an sich hat natürlich keinen Index. Es handelt sich ja nur um ein SQL-Statement (auch ein Insert oder Select hat keinen Index ). Ich bezog mich hier eher auf die Relationen, auf denen das View arbeitet. An sich ist ein Index ja gerade dafür gedacht, dass Du schneller Suchen kannst (eben zu Kosten der Einfüge/Lösch/Updateoperationen). Wenn Du jetzt eine Select-Anfrage erstellst oder eben einen Join, o.Ä., dann wird hier der Anfrageoptimierer (hoffentlich) einen Index berücksichtigen, soweit dieser vorhanden ist.
Wird also auf den Tabellen hauptsächlich eine bestimmte Anfrage ausgeführt, so lohnt sich hier ein Index (also Anfrage im Sinne von lesender Zugriff!). Natürlich kann es auch verschiedene Anfragen geben, die auf verschiedene Attribute zugreifen, da lohnen sich dann mehrere Sekundäre Indizes, allerdings nur solange die Lesezugriffe die Anzahl der Änderungen deutlich überwiegen (Update eines Index kostet natürlich wieder etwas Zeit).

An sich hilft hier im Zweifel auch die Auswertung der Statistiken die hier erhoben wurden. So erstellen Systeme wie Oracle und DB2 durchaus auch solche Informationen (wenn man es ihnen sagt), so dass man sieht, wie häufig welche Operationen eben statt finden/fanden. Das ganze lässt sich dann leicht ausnutzen um hier weitere Optimierungen vor zu nehmen. An sich hilft vielleicht auch gleich die Analyse des Auswertungsplans weiter (da findet man in den Graphischen Tools gleich einen Graphen, ansonsten müssten explain oder explain plan oder so helfen).

[r3v0]

Also alle anderen Tabellen haben aufjedenfall Indexe usw. Von Der Optimierung und Strukturierung bin ich mittlerweile überzeugt. Wobei ich auch noch nicht durchblicke, (Azubi und erst seid ein paar monaten in der abteilung, Prjekt läuft schon länger)

Wir haben uns gestern abend nochmal hin gesetzt, was überlegt und ausprobiert. Dabei sind wir auf die Erkenntnis gekommen das die Abfrage auf NULL ihre 8 Sekunden braucht und der Rest schnell durchläuft.

So Zwei Fragen:

erste: Gibt es eine Alternative von der Abfrage is NULL?
zweite: Wenn Nein Kann ich in einer View Dem Sagen das Alle NULL Felder auf z.b. -1 gesetzt werden sollen?

Danke im Vorraus

[r3v0]

Sodale Es gibt was neues...

Wenn man sofort in der View auf Is Null überprüft und dies dann quasi als berechnetes Feld in der View anzeigen lässt wäre alles schön!!!!!!!!!!!!!!!!! MYSQL Macht das alles schön brav total geil...

DB2 Kennt wiederrum kein bisschen einen vergleich ...
als kleines beispiel... :

SQL-Code:

CREATE VIEW TEST(
  ID,
  (1=1) AS TestFeld,
....

Das wäre in MYSQL schön und es würde immer true also 1 rauskommen.
In der DB2 Zickt der rum bei so einen vergleich.

Gibt es da irgendwie was vernünftiges was man nehmen kann auf der DB2??

Danke im Vorraus

[Der_Unwissende]

Zitat von r3v0:

erste: Gibt es eine Alternative von der Abfrage is NULL?

Ist finde ich etwas schwer zu beantworten. Ich habe ehrlich gesagt noch nicht ganz verstanden, was genau hier auf is NULL geprüft wird und/oder warum. An sich versucht man natürlich schon im DB-Design möglichst wenig Attribute im Schema zu haben, die unbestimmt sein können (also NULL werden dürfen).
Ob es eine Alternative gibt hängt also schon allein davon ab, was genau ihr jetzt macht. An sich wäre halt eine Möglichkeit, dass Du die Stored-Procedure an die Anzahl der Argumente anpasst (also für 3, 4 und 5 Argumente je eine erstellst). Wenn ich es richtig verstanden habe, kann es Fälle geben in denen eine ID ansonsten eh nicht in den Daten vorhanden sein kann.
Was ich nicht richtig verstehe ist, was genau auf is Null geprüft werden muss. Wenn es keinen Eintrag mit der entsprechenden ID gibt, dann wird entsprechend nichts getan. Davon ausgehend, dass diese ID eben eindeutig ist, wüßte ich nicht was man da noch mit NULL prüfen kann/muss. Selbst die Überprüfung auf is NULL kommt mir mit 8 Sek. doch etwas sehr langsam vor, da sollte man sich vielleicht wirklich mal den Auswertungsplan anschauen, vielleicht gibt der einem dann Aufschluss über das Problem.

An sich hätte ich jetzt verstanden, dass Du mehrere Relationen (5 oder 6) verknüpfst und hier mit 3 - 5 Datensätzen arbeitest. Dabei gehe ich davon aus, dass eben diese 3-5 IDs in einer Relation der primäre Schlüssel sind und damit 3-5 Tupel identifizieren. Egal wie jetzt weiter verknüpft wird, der DB-Optimierer wird sicherlich erstmal diese 3-5 Tupel Selektieren. Existiert hier sogar ein Index, sollte das sehr sehr flink gehen. Damit muss diese Relation nicht weiter betrachtet werden, nur noch diese 3-5 Relationen sind interessant. Wie auch immer jetzt die weiteren Verknüpfungen aussehen, solange über die Elemente, die verknüpft werden ein Index angelegt wurde, sollten die Arbeiten extrem flink erledigt werden können (immerhin geht es hier um eine extrem kleine Anzahl von Datensätzen die nach der Selektion nach den IDs übrig bleiben!). Die Relation zwischen der normalen Suchzeit und der Zeit wenn NULL mit abgefragt wird könnte ich mir da nicht erklären (was natürlich auch nicht viel heißt!).

[r3v0]

öhm jah! Da ist ein problem das ich nicht wirklcih den code posten kann... bzw nicht weiß ob ichs darf...

Also die Überprüfung von is NULL ist nicht das Problem... Irgendwie... Ich weiß es nicht ich habe Kopfschmerzen...

Nochmal versuch zu erklären!

überprüfe ob es die ID in der Spalte gibt...
Wenn die ID nicht vorhanden ist...
überprüfe ein ANDERES Feld auf NULL

So jetz haben wir es geschafft die IS NULL abfrage rauszubekommen in dem wir einfach werte via WHERE then odersowas eingefügt haben dann einfach auf die Werte überprüft. Aber das ist genauso langsam!
Aber genau da hängt er sich irgendwie auf...

Ich weiß nicht mehr weiter! Ich denke ich geh erstmal ins WE... Und hoffe das sich das Problem erldeigt

Kennst du beim I Sieres Navigator auch den SQL Performance Monitor?
Kann der auch Stored Procedures Überwachen!? Bis jetzt hab ich nur gesehen das der "Jobs" beobachten kann aber ich weiß nicht wirklich was jobs sind

[r3v0]

tada ich könnte nen blog aufmachen!

Das ganze überm I Series Navigator ist Langsam!
Das ganze über ado über Delphi ist nur die ersten beiden mal nachherm connecten langsam erste 3,5 sek 2te 2 sekunden alle danach 500 ms also 0,5

?????????????????????????????????????????

[Der_Unwissende]

Zitat von r3v0:

Das ganze überm I Series Navigator ist Langsam!
Das ganze über ado über Delphi ist nur die ersten beiden mal nachherm connecten langsam erste 3,5 sek 2te 2 sekunden alle danach 500 ms also 0,5

Was sich leicht erklären lässt! Ein paar Tools (insbesondere solche für Interaktive Anfragen) bieten eine ganze Menge mehr als nur das reine Absetzen von Anfragen. Stell Dir einfach mal ein echtes Produktivsystem vor, indem jeder selbst über den I Series Navigator auf die DB zugreifen müsste. Ich denke da ist eine Applikation (oder mehrere) doch sehr viel gebräuchlicher.
Bieten bestimmte Tools also Informationen über die Auswertung (graphische Darstellung, Profiling, ...), so entfallen diese Funktionen in Applikationen natürlich.
Das die Zeit für die Anfragen sinkt, wenn Du die mehrfach ausführst ist auch klar, da ein DBS wie DB2 natürlich intelligente Caching-Strategien einsetzt. Liegt eine Seite schon im Hauptspeicher, so muss die natürlich nicht wieder von der Festplatte geladen werden (unterschied liegt hier im Bereich von 10^5!). Dann wird natürlich die Anfrage optimiert, ggf. ein Index erstellt oder die Menge vorsortiert (o.Ä.). Bei der zweiten Suche kann also ggf. schon auf eine optimierte Struktur zugegriffen werden und auch die Abschätzungen der Selektivität steht bei wiederholten Anfragen wohl schon (hier könnte es nochmal zu einem Unterschied kommen, wenn Du zwischendurch Datensätze änderst).

Jedenfalls denke ich habt ihr im Moment eine Form, die euch ja von der Geschwindigkeit genügt? Dann ist doch erstmal gut!