B.Hauser
23-10-08, 19:58
@Baldur,
ich verstehe irgendwie die ganze Aufregung nicht.
1. Was zuvor mit der CQE ausgeführt werden konnte, kann auch weiterhin mit der CQE ausgeführt werden.
2. Was an jetzt an die SQE gegeben wird und abbricht, muss der IBM gemeldet werden.
3. Was jetzt an die SQE geroutet wird und keinen passenden Index findet, weil durch das Setzen der Option IGNORE_DERIVED_INDEX Zugriffswege in logischen Datein mit SELECT/OMIT Anweisungen nicht mehr zugänglich sind sollte folgendes machen:
- Die bestehenden logischen Dateien mit select/omit-Anweisungen löschen
- Für jeden in den logischen Dateien mit select/omit-Anweisung einen SQL Index anlegen
- Die logischen Dateien mit select/omit-Anweisungen wieder erstellen.
Die Anzahl der Zugriffswege wird nicht erhöht, da DDS beschriebene Dateien den Zugriffsweg mit SQL-Indices sharen können (umgekehrt geht das nicht, da DDS beschriebene logische Dateien per Default eine Page Size von 8K haben, währen SQL Indices eine Page Size von 64K haben. Der SQE Query-Optimizer kann jetzt die SQL Indices verwenden, währen native I/O weiterhin die DDS beschriebenen logischen Dateien mit select/omit-Anweisungen verwenden kann.
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
ich verstehe irgendwie die ganze Aufregung nicht.
1. Was zuvor mit der CQE ausgeführt werden konnte, kann auch weiterhin mit der CQE ausgeführt werden.
2. Was an jetzt an die SQE gegeben wird und abbricht, muss der IBM gemeldet werden.
3. Was jetzt an die SQE geroutet wird und keinen passenden Index findet, weil durch das Setzen der Option IGNORE_DERIVED_INDEX Zugriffswege in logischen Datein mit SELECT/OMIT Anweisungen nicht mehr zugänglich sind sollte folgendes machen:
- Die bestehenden logischen Dateien mit select/omit-Anweisungen löschen
- Für jeden in den logischen Dateien mit select/omit-Anweisung einen SQL Index anlegen
- Die logischen Dateien mit select/omit-Anweisungen wieder erstellen.
Die Anzahl der Zugriffswege wird nicht erhöht, da DDS beschriebene Dateien den Zugriffsweg mit SQL-Indices sharen können (umgekehrt geht das nicht, da DDS beschriebene logische Dateien per Default eine Page Size von 8K haben, währen SQL Indices eine Page Size von 64K haben. Der SQE Query-Optimizer kann jetzt die SQL Indices verwenden, währen native I/O weiterhin die DDS beschriebenen logischen Dateien mit select/omit-Anweisungen verwenden kann.
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