View Full Version : SQL-Pessimizer
Da habe ich doch mal wieder ein seltsames Phänomen bei einem komplexen SQL via ODBC an ein System mit V7R1:
Ohne Parametermarker -> Antwortzeit ca. 30 Sekunden
Mit Parametermarker und korrektem Feldwert -> Querytimelimit von ca. 339000 Sekunden überschritten
Laut Joblog (Debugmodus) sehen beide Ausführungshinweise identisch aus. Man kann sogar temporäre *QUERYnnnn sehen, die auch gefüllt werden (offene Dateien), aber zum Schluss entscheidet sich SQL dann doch, das Querytimelimit als Fehler auszuwerfen.
Nun mach ich das also ohne Parametermarker.
Könnte es sein, dass bei Verwendung von Parameter Markern eine Datenkonvertierung in irgendeiner Form erfolgen muss, die ohne Parameter Marker nicht erforderlich ist, da der String korrekt aufbereitet wurde?
Birgitta
andreaspr@aon.at
29-06-13, 11:25
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
... 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
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.
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?
... 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?
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.
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
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