LF / SQL index

[woodstock99]

Hallo,

ich habe gerade auf der Iseries ein neues LF erstellt .

Dieses beinhaltet FELD

A,
B,
C.

Wenn ich jetzt folgenden SQL Befehl absetze .

Select A,B,C from Datei

sollte er doch die logische verwenden oder?

Er verwendet aber eine andere Datei mit einem SELECT/OMIT und sagt dann
11 - The access path contains static select/omit selection criteria which
is not compatible with the selection in the query.


Weiss da jemand Rat??
Gruss

[Fuerchau]

SQL verwendet grundsätzlich nur PF/TABLE's und für den Zugriffsweg vollständige LF's und Indizes.
Eine eingeschränkte LF, die nur bestimmte Felder beinhaltet dient nur der Vereinfachung eines SQL's (entspricht einer View mit Index).
Die Abfrage geht aber direkt auf die PF und sucht sich dann einen Index.
Je nach Version (V5/V6/V7) werden Select/Omit-LF's ignoriert oder wenn die Whereklausel dem Select/Omit entspricht auch verwendet.

[woodstock99]

Ja aer SQl geht doch auf die physische und der sucht sich dann , sollte sich die beste raussuchen oder ? Der IndexAdvisor hat mir ja die LF vorgeschlagen und jetzt nimmt die Maschine trotzdem die verkehrte. Verstehe ich nicht .
Meine LF mit Select/Omit wird doch vom SQE sowieso nicht verwendet und wird automatisch an den CQE weitergeleitet . Die Maschine soll einfach nur die neue logische nehmen tut es aber nicht ..... Warum auch immer :(.

In meinem Bespiel mach ich ja nur einen Select a,b,c und genauso ist die logische aufgebaut .
Er nimmt aber die mit Select/omit .. Verstehe ich wirklich nicht .

[Fuerchau]

Es wird nur die Beste bzgl. Index gewählt!
Die Felder des Select spielen da keine Rolle.
Wenn eine PF 5 Felder enthält und eine LF davon dann nur 3, ist diese LF wie eine View zu sehen.
Wobei eine View keinen Index haben kann.
Eine View dient ggf. nur der Vereinfachung (select * from MyView) sowie ggf. der Berechtigung, d.h., dass ein User über eine View nicht alle Felder sehen darf.

Wenn du nun deiner LF einen Index verpasst und deine Where/OrderBy/Groupby-Klausel dazu passt, könnte es sein, dass die LF gewählt wird.

[Pikachu]

Er verwendet aber eine andere Datei mit einem SELECT/OMIT und sagt dann
11 - The access path contains static select/omit selection criteria which
is not compatible with the selection in the query.

Wie sehen diese Nachricht und die vorhergende genau aus, insbesondere der Teil mit den jeweiligen Zugriffspfaden samt Ursachencodes.

[Fuerchau]

Hier liegt ein Verständnisfehler vor:
Mit dieser Nachricht werden alle LF's mit Index aufgeführt. Alle Codes ungleich 0 sind ein Grund, warum die LF nicht genommen wurde.
Ursache 11 bedeutet, dass Select/Omit der Grund für den Ausschluss ist.
Wie gesagt, ab V6 oder V7 können solche LF's auch gewählt werden, wenn where/order/Group/join passt.

[woodstock99]

The query access plan has been rebuilt.
All access paths were considered for file XXX
Additional access path reason codes were used.
Arrival sequence access was used for file XXX
Query options used to build the query access plan.

Message . . . . : All access paths were considered for file xxx.
Cause . . . . . : The query optimizer considered all access paths built over
member xx of file xxx in library LIB.
The list below shows the access paths considered. If file xxx in
library lib is a logical file then the access paths specified are
actually built over member xx of physical file xxx in library
lib. Following each access path name in the list is a reason code
which explains how the optimizer considered the access path.
lib/Falsche LF 11
The reason codes and their meanings follow:
0 - The access path was used to implement the query.

@furechau . ich raff es echt nicht . Ich mache doch einen SQL und wähle feld a ,b,c von der physischen. Normal müsste doch der optimizer hergehen und sagen , hey cool ich da eine LF die genauso aufgebaut ist. Der Indexadvisor schlägt mir ja auch diese LF vor ja es gibt ein SQL programm das genau diese felder a,b,c in der Where abfrage hat und trptzdem nimmt er die falsche LF .

bis jetzt hats ja auch immer funktioniert aber diese LF kann er so wies aussieht nicht leiden ..
Felder und Reihgenfolge passen mit dem Vorschlag des Advisors überein . Habs nochmal überprüft.

[Fuerchau]

Also noch mal langsam!
Eine LF besteht aus Feldern und aus Index-Feldern.
Wenn du nun einen "CREATE INDEX ..." machst, so enthält die LF automatisch alle Felder mit dem gewünschten Index der Felder.
Willst du das selbe mit einer LF erreichen so musst du alle Felder (oder einfach das selbe Satzformat) sowie die K-Bestimmung für den Index angeben.

Machst du eine LF mit nur 3 Feldern und dem Index über diese 3 Felder, ist das für SQL eine VIEW (unabhängig vom Index).
Views finden beim Index suchen aber keine Rolle, da diese (bei SQL) ja auch keinen Index haben.

Nun können wir aber auch aneinander "vorbeireden" und du erstellst die LF per DDS mit allen Feldern.

Was nun beim Optimizer passiert und was ich immer wieder erlebe ist, dass der vorgeschlagene Index anschließend nicht genommen wird!
Da kann man sich dann auf den Kopf stellen wie man will.

"Felder und Reihgenfolge passen mit dem Vorschlag des Advisors überein" bezieht sich ausschließlich auf die Schlüsselfelder!
Mach doch einfach folgendes:
Lösche deine LF und erstelle einen Index per "create index mylib/myindex on mylib/myfile (f1, f2, ...)" und prüfe das Ergebnis per SQL.

[UFK]

Mach doch einfach folgendes:
Lösche deine LF und erstelle einen Index per "create index mylib/myindex on mylib/myfile (f1, f2, ...)" und prüfe das Ergebnis per SQL.
Das Dingens wird wohl vewendet werden, also die Lösung sein.

Unschön ist die Macke beim SQL dennoch, denn früher hat man auf speziell für den Anwendungsfall formulierte logische Dateien gesetzt, die man dann konventionell mit RPG oder COBOL vewendet hat. Da treffen also Weltanschauungen aufeinander, DDS-Welt der AS400 gegen die SQL-Welt, und IBM kann es keinem der beiden wirklich recht machen.

Obendrein hat die DDS-Ansicht dazu geführt, daß manchmal sehr viele LF's über denselben physischen Dateien erstellt wurden, und der SQL-Optimierer spätestens bei der vierzigsten das Handtuch geworfen und beschlossen hat, lieber den Index selber zu erstellen, als weiter darüber zu brüten, welcher der vielen Zugriffswege denn optimal sein könnte.

Ich hatte auch mal Ärger mit dynamical select Join auf DDS-Basis, die jedesmal zur Neuindexierung von Millionen Datensätzen führten, obwohl die LF's eigentlich sofort nutzbar gewesen wären. Besser wurde es bei mir durch spezielle Indizes und simpel formulierte SQL-Anfragen, welche die SQL-Engine leichter mappen konnte. Besser als das Neu-Indexieren oder als das sequentuelle Scannen des kartesischen Produktes waren aber auch Selects mit korrelierten Subselects.

Interessant, daß IBM die Leute immer noch ins Messer rennen läßt, und sogar in Kauf nimmt, System-i Kunden zu vergraulen.

PS: habt Ihr euch schonmal mit der QAUOOPT beschäftigt ?

[Fuerchau]

Das liegt nicht an IBM sondern am SQL-Standard an den sich die IBM weitestgehend auch hält.
SQL und DDS ist absolut nicht vergleichbar. man kann zwar Analogien ziehen aber es gibt doch wesentliche Unterschiede.
Wenn man sich mit SQL-Konzepten nur an Hand von DDS beschäftigt ist man natürlich verraten und verkauft. So funktioniert SQL einfach nicht.
DYNSLT-Joins, wie der Name schon sagt, muss halt Indizes aufbauen und ist bei DDS eigentlich die schlechteste Lösung, eben mangels Index, performant waren die noch nie.
Und wenn man nun noch komplexe SQL's erfindet die man so überhaupt nicht programmieren würde, dann kann auch der Optimizer nichts mehr leisten.
SQL-Zugriffe müssen genauso wohl überlegt sein wie DDS-Zugriffe mit Native-IO und 100en LF's (die auch Maintenance-Zeit kosten).