SQL-Pessimizer

[andreaspr@aon.at]

Mich würde auch interessieren ob du das gleiche Problem hast, wenn du die Parameter an eine SQL Prozedur übergibst und von dort dann einfach nur den geöffneten Cursor zurückgibst.

lg Andreas

[BenderD]

... ich frage mich immer, wer den DB2/400 Vernutzern nur den Blödsinn mit den stored Procedures, die ResultSets zurückgeben einredet (ganz kurios wird's dann, wenn man dann die Daten mit Rekord Löffel Ekzem zusammenkratzt). Das widerspricht nicht nur dem Konzept von SQL als Sprache zur Beschreibung von Mengen mittels relationaler Operationen, sondern hebt auch den letzten Rest von Datenbank Unabhängigkeit auf.

D*B

[Fuerchau]

Da kann ich Dieter ja nur zustimmen.
Der ODBC-Treiber unterstützt die Abfrage der benötigten Parameter sowie deren Typ.
Ich habe nur einen einzigen Parameter vom Typ "Numeric", da das Abfragefeld vom Typ Zoned ist.

Der SQL ist tatsächlich ein wenig komplizierter:
2 CTE's mit Group By und Where, 1 derived Table mit Where und Group by und ca. 10 Left Joins mit abschließendem Where und Parameter.

Und was die Typanpassung angeht, so wird im Falle von Konstanten die Anpassung der Konstanten vorgenommen und nicht des Abfragefeldes.

Automatische Anpassungen werden nicht bei Join-Beziehungen durchgeführt.
Dies kann man dann statisch mittels Cast's aber selber machen.

Das Problem läßt sich aber nicht weiter analysieren, da es ja ohne Parametermarker nun ratz fatz funktioniert und somit erledigt ist.

[Fuerchau]

Noch ein Nachtrag:

bei beiden Varianten konnte man sehr schön verfolgen, dass temporäre Dateien erstellt wurden (*QUERYnnnn). Jedoch kam bei der Variante mit Parametermarkern zum Schluss die Querytimeout-Meldung bei der anderen Variante aber die Daten.

Dies deckt sich im Übrigen auch mit einem MS-Access / ODBC-Problem.
MS-Access kann zur Zeit mit dem V7-Rechner keine "verknüpften" Tabellen über ODBC erstellen.
Zur Sicherheit habe ich das QZDA-SQLPKG neu erstellen lassen, PTF's und Servicepacks sind auch aktuell (bevor jemand nachfragt).

MS-Access (auch MS-Query über Excel) meldet unterschiedliche Fehler.
Bei einer SQL-Passthru-Abfrage mit "select * from Lib.Table" (Tabelle hat knapp 100 Sätze) kommt der Query-Timeout, beim Einbinden als verknüpfte Tabelle "Feld zu lang".
Ein "Select f1, f2, ... from Lib.Table" funktioniert problemlos.

Alles lief ja bis V6R1!

Der Fehler an IBM ist (hoffentlich) bereits unterwegs.

Vielleicht kann das (MS-Access) ja mal noch jemand ausprobieren?

[KM]

... ich frage mich immer, wer den DB2/400 Vernutzern nur den Blödsinn mit den stored Procedures, die ResultSets zurückgeben einredet

Was soll daran Blödsinn sein?

[Fuerchau]

Insofern Blödsinn, dass dadurch nur geringe oder keinerlei SQL-Vorteile des Optimizers genutzt werden können.
Alles hängt von der Procedure ab wie performant dies wird.
Procedures habe natürlich ihre Berechtigung, wenn Sie denn "erheblich" mehr tun als nur einen Select durchzuführen (Business-Logic).
Dafür gibt es halt die "Ein-" und "Ausgabe"-Parameter, in denen man die Ergebnisse zurückerhält.
Resultsets sind da eher unerquicklich und verleiten ggf. zu Verwendung in Joins.
Hier kann der Optimizer dann fast gar nichts mehr tun.

[B.Hauser]

Insofern Blödsinn, dass dadurch nur geringe oder keinerlei SQL-Vorteile des Optimizers genutzt werden können.
Alles hängt von der Procedure ab wie performant dies wird.
Procedures habe natürlich ihre Berechtigung, wenn Sie denn "erheblich" mehr tun als nur einen Select durchzuführen (Business-Logic).
Dafür gibt es halt die "Ein-" und "Ausgabe"-Parameter, in denen man die Ergebnisse zurückerhält.
Resultsets sind da eher unerquicklich und verleiten ggf. zu Verwendung in Joins.
Hier kann der Optimizer dann fast gar nichts mehr tun.

Sofern die ausgegebenen Result Sets auf SQL Cursorn beruhen, die beim Verlassen der Stored Procedure geöffnet bleiben, erfolgt sehr wohl eine Optimierung!

Result Sets haben den Nachtteil, dass das ausgegebene Daten-Volumne von außen (außer über die übergebenen Parameter-Werte) nicht beeinflussen kann. Werden also nicht alle zurückgegbenen Daten benötigt, müssen die unerwünschten Daten trotzdem gelesen bzw. überlesen werden.

Ebenso können Result Sets nicht in SELECT-Statements verwendet oder mit einander über SQL verknüpft werden.

Birgitta

[BenderD]

Was soll daran Blödsinn sein?

... das steht in dem Teil knapp formuliert drin, den Du beim zitieren rausgenommen hast
Etwas ausführlicher:
- Stored Proedures haben von allen SQL Bestandteilen die geringste Portabilität.
- eingeschränkte Verwendbarkeit im Vergleich zu Views
- fördern Vermischung von Datenbank und Business Logik
- sind ResultSets, die nicht wie Tabellen benutzt werden können
- reduzieren die flexible Nutzung der Datenbank
- sind im Problemfall schlecht zu debuggen
- sind schlecht wartbar
- mangelnde Unterstützung durch Entwicklungswerkzeuge
- können in den meisten Fällen durch Views ersetzt und damit vereinfacht werden
- werden oft als Krücke für schlechtes Datenbank Desing verwendet

D*B

[andreaspr@aon.at]

Witzig wie da gegen Stored Procedures vorgegangen wird!

Alle bis jetzt genannten Punkte deuten darauf hin dass es in diesem Bereich einen großen Wissensbedarf gibt.
Sorry!

In Birgittas und meinen Schulungen werden auch Stored Procedures Schritt für Schritt erklärt (Verwendung, Wartung, Entwicklung uvm.)

Ich will jedoch jetzt nicht auf jeden genannten Punkt eingehen und erklären warum diese teilweise eindeutig falsch sind.
Dafür kann ein neuer Thread erstellt wenn es spezifische Fragen gibt.

lg Andreas

[BenderD]

Mich würde auch interessieren ob du das gleiche Problem hast, wenn du die Parameter an eine SQL Prozedur übergibst und von dort dann einfach nur den geöffneten Cursor zurückgibst.

lg Andreas

... diese "Empfehlung" ist doch gerade hier Murks!!! Wenn die stored Procedure Bestandteil eines komplexen Queries wird, geht das doch nur noch über weitere funktionale Logik in weiteren Procedures. Ich gebe hin und wieder Kurse über Datenbank Design inklusive View Layer; wenn ich mal in südlichen Gefilden damit unterwegs bin, gebe ich Dir da gerne einen Rabatt.

D*B

[Fuerchau]

Und ich erstelle dann für jeden SQL, den ein Anwender mit meiner Software selber produziert eine SQL-Prozedur die nichts anderes tut, als diesen SQL auszuführen?

Das Problem liegt im Zusammenspiel zwischen ODBC-Treiber und dem QZDA-Job und lässt sich so ziemlich auf die Abfrage von Spalten-Metadaten (SQL-Schemaabfragen durch ODBC definiert) einschränken.

Mit V7 hat die IBM nämlich einige der Abfragen auf Stored-Procedure umgestellt und genau diese lösen den Querytimeout aus.
Ich möchte nun aber ungern diesen Timeout auf Nomax umstellen da dies weitere Konsequenzen nach sich zieht die die Anwender nur mehr verwirren.
Ein Timeout macht nämlich durchaus sinn.

[andreaspr@aon.at]

Und ich erstelle dann für jeden SQL, den ein Anwender mit meiner Software selber produziert eine SQL-Prozedur die nichts anderes tut, als diesen SQL auszuführen?

War die Frage jetzt ernst gemeint oder seid ihr jetzt einfach nur beleidigt?

@Dieter:
Ich bin mir nicht sicher ob ihr mich beim erstem mal verstanden habt, deshalb nocheinmal im Detail.
Ich habe vorgeschlagen (zum Testen!!) dieses komplexe Query einfach nur in eine SP zu verschieben (copy & paste) und dort als Cursor zurück geben lassen.
Wie ich zuvor schon geschrieben habe, würde mich interessieren, ob das Problem dann noch immer vorhanden ist.
Dabei ging es jetzt auch nicht um eine "Empfehlung" abzugeben sondern weitere Hinweise auf das Problem zu finden.

Wenn man das nun nicht Testen möchte hab ich damit auch kein Problem.