Query: logische Datei wird nicht verwendet

[RolfSalzer]

Hallo,
Habe folgendes Phänomen:
Ein Query verwendet einen vorhandenen Zugriffspfad nicht, obwohl dieser exakt die Schlüsselfelder aufweist, die gefragt sind und auch kein select/omit drin ist. Die Datei ist die zweite Datei in einem Query mit nur 2 Dateien.
Wenn ich vorher strdbg mache kommt eine Auflistung, warum welcher Zugriffspfad nicht verwendet wurde (CPI432C).Hier wird Ursachencode 4 aufgeführt. Der Text hierzu lautet:
4 - Die Kosten zur Verwendung dieses Zugriffspfads, die vom Optimierungsprogramm ermittelt wurden, sind höher als die Kosten für die ausgewählte Zugriffsmethode.
Sagt mir jetzt leider gar nichts. Was kann ich tun ?

[Fuerchau]

Rein gar nichts !
Der Optimizer meint eben, das dieser Zugriffspfad zwar die richtige Schlüsselfolge hat, aber die Zugriffe darüber langsamer sind als die von ihm gewählte Zugriffsmethode.
Das kann durchaus sein, da ggf. Bitmap-Verarbeitung ausgewählt wird und diese Zugriffsform eben häufig schneller erfolgt.
Allerdings gilt der Optimizer häufig als Pessimzer und liegt mit seinen Schätzungen und Methoden völlig daneben.
Ab V5R3 gibt es 2 verschiedene Optimizer, den alten und halt einen neuen.
Wenn der Neue eben daneben liegt dann gibt es kurzfristig einen kleinen Trick, dass der alte Optimizer verwendet wird:
Man lege irgend eine LF mit Select/Omit an. Der neue Optimizer kann diese noch nicht verarbeiten, also wird der alte genommen.
Die Zugriffe werden dann auch ggf. anders durchgeführt.

[B.Hauser]

@Rolf:
Handelt es sich um ein Query/400 - Query oder um ein SQL-Select-Statement?
Erfolgt die Verknüpfung der beiden Dateien über die Schlüssel-Felder?
Werden Felder aus der zweiten Datei ausgewählt?
Werden Sätze über Feld-Inhalte in der zweiten Datei ausgewählt?
Wird für die zweite Datei überhaupt ein Zugriffs-Pfad verwendet oder die physische Datei verarbeitet?
Was passiert, wenn die beiden Dateien vertauscht werden? (sofern die Dateien mit gleich verknüpft wurden)

Dies u.v.m. sind Fragen, die der Query-Optimizer intern stellt und bei der Wahl des Optimalen Zugriffs-Weges berücksichtigt.

Sehr oft kann man den Query-Optimizer durch das Umschreiben der SQL-Statements zu anderen Entscheidungen bringen. Manchmal hilft auch eine Sortierung anzugeben. (Obwohl die Empfehlung der IBM lautet, nur dann eine Sortierung zu verwenden, wenn erforderlich!)

Einige gute Quellen zum Thema Query Optimizer findest Du unter folgenden Links:
Indexing and statistics strategies for DB2 UDB for iSeries
oder
Query performance and query optimization

Ab V5R3 gibt es 2 verschiedene Optimizer, den alten und halt einen neuen.

Die SQL Query Engine (SQE) gibt es bereits seit Release V5R2M0 und unterstützt nur echte SQL-Interfaces. Query/400, OPNQRYF und QQQQUERY sind keine SQL-Interfaces und werden nur von der Classic Query Engine (CQE) verarbeitet. Es ist auch nicht geplant, dass diese Interfaces je mit der SQE verarbeitet werden.
Ob CQE oder SQE ziehen entscheidet der Query-Dispatcher.
Welche der beiden Query-Engines für eine SQL-Abfrage verwendet wurde, kann man nur mit Hilfe von Database Monitoren (STRDBMON oder iSeries Navigator --> Detaillierte Leistungs-Überwachung starten) feststellen. Wird Visual Explain verwendet, kann man aufgrund der unterschiedlichen Symbole sehen, ob CQE oder SQE verwendet wurden.

In den meisten Fällen wird man feststellen, dass trotz des Vorhandenseins der neuen SQE die Abfragen mit der CQE ausgeführt wurden.

Wenn der Neue eben daneben liegt dann gibt es kurzfristig einen kleinen Trick, dass der alte Optimizer verwendet wird:
Man lege irgend eine LF mit Select/Omit an. Der neue Optimizer kann diese noch nicht verarbeiten, also wird der alte genommen.
Die Zugriffe werden dann auch ggf. anders durchgeführt.

Liegt eine logische Datei mit SELECT/OMIT-Anweisungen auf einer physichen Datei, wird ein SQL-Statement auf diese Datei immer mit der CQE ausgeführt. Wenn es nur darum geht, zu prüfen, wie sich ein einzelnes SQL-Statement unter CQE oder SQE verhält, reicht es eine logische Datei im SELECT-Statement zu verwenden. Dann wird das SQL-Statement mit Sicherheit vom Dispatcher an die CQE reroutet.

Birgitta

[Fuerchau]

Wobei die IBM keine Garantie dafür abgibt, dass es so bleibt (Aussage von IBM, da ich nach Umstellung von V5R2 auf V5R3 eine Zeitschätzung von über 300.000 Sekunden bei einem Union-Select bekam und daraufhin die Empfehlung genau so lautete: LF mit Select/Omit und schon wurde der "alte" Optimizer aufgerufen mit Schätzzeiten unter 30 Sekunden).