SQL-Optimizer ist einfach blöd

[BenderD]

ad3: wie soll man denn Hibernate (Object relational mapping Framework in Java) oder Microstrategy (Frontend für DataWarehouse) dazu bringen in bestimmte SQL Statements, die man nicht einmal findet, solche Workarounds einzubauen???

ad4: heißt dann auch: Hände weg von V6R1!!!

ad5: wenn derived Indexe so verarbeitet werden wie andere auch, dann bräuchte man keine!!!!

ad6 und 7: das sind doch alles platte Marketing Aussagen, denen ich nicht einmal bis morgen über den Weg traue. (vergleiche auch: DB2/400 und DB2 UDB, WebQuery, WebSphere und AS400, 64 Bit Java, ADM, APD, Office)

mit ganz lieben Grüßen

Dieter Bender

@Baldur,

ich verstehe irgendwie die ganze Aufregung nicht.

3. Ansonsten kann man einfach durch Hinzufügen einer Dummy-Anweisung z.B. Where Upper('x') = 'X' die Abfrage an die CQE zurückgeben. Funktionen wie Upper, Lower und Translate werden unter V5R4 noch nicht von der SQE unterstützt.
Ein Workaround, das mit dem man durchaus arbeiten kann bis das PTF ausgeliefert wird.

4. Wenn Optionen in der QAQQINI verändert werden, sollte man schon genau wissen, was man tut und bevor man das Ganze scharf mach auf Herz und Nieren prüfen. Die Optionen, die in der Abfrage-Options-Datei als Default-Werte angegeben sind, sind die von IBM gesetzten und die als beste Variante für das Release angesehenen Werte.
Wenn man schon mit geänderter QAQQINI arbeitet, sollte man diese einmalig bei Job-Start setzten und dann nie wieder ändern.

5. Derived Indices werden vom SQE-Optimizer genauso verwendet wie Zugriffswege in DDS beschriebenen logischen Dateien mit Select/Omit-Anweisungen vom CQE-Optimizer, d.h. nur der Zugriffweg nicht aber die Selektion bzw. Where-Anweisungen werden berücksichtigt.

Unter Release 6.1 sind Derived Index in erster Linie für native I/O gemacht, damit DDS beschriebene Dateien durch SQL abgelöst werden können. Unter Release 6.1 kann der Optimizer die Derived Indices (mit Where-Bedingungen) noch nicht voll ausnutzen, das heißt aber nicht, dass das nicht geplant ist.

6. STRDBG ist nicht mehr strategisches Produkt für die Query und Performance-Analyse, d.h. es werden auch nicht alle Meldungen im Joblog ausgegeben.
Strategisches Produkt ist der iNavigator der gerade unter V5R4 beträchtlich erweitert wurden. Ansonsten muss man halt mit den Database Monitoren arbeitet, was allerdings ohne iNavigator ziemlich schwierig ist und die Beschreibung dazu auch reichlich dürftig.

7. Die CQE wird nicht abgeschafft werden, da z.B. Query/400 auf dem gegenwärtigen Stand stabilisiert wird. Das Strategische Produkt ist jetzt DB2 WebQuery, was bis dato noch die wenigsten installiert haben und noch weniger ausprobiert haben.

Was glaubst Du wer wohl die hundertausende von Query/400s oder OPNQRYF, die immer noch draußen rumschwirren und von denen auch heute noch fleißig neue erstellt werden ausführt?

Birgitta