Timeout bei SQL Abfragen

[Fuerchau]

Also der Fehler SQL0666 ist so alt wie man mit SQL auf die AS/400 und nun IBM i zugreifen kann.
Der Optimizer schätzt eben die Zeit, die die Ausführung des SQL's wahrscheinlich dauern wird.
Zwar hat sich da immer mal wieder was getan, allerdings liegt der Optimizer leider auch häufig daneben.

Eine View (mit where) über die Tabelle zu bauen bringt für den Optimizer rein gar nichts.
Es wird immer über die Table selektiert und der SQL ggf. mit der Where.-Klausel aus der View ergänzt.
Die View hat außer für Schreibfaule aus SQL-Sicht keine Bedeutung.

Anders sieht es mit einem Index aus.
Mit dem neuen Optimizer (V6 oder erst V7) wird ein Index mit Where-Klausel (unsere gute alte LF mit Select/Omit) verwendet, wenn die where-klausel des SQL's mit dem des Index übereinstimmt.
Aber Achtung: wirklich ein Index und keine LF.

Trotz aller Indizierungen wird halt gerne der Fehler gemacht, bei den Where-und Join-Bedingungen nicht auf die korrekt Typisierung zu achten.
Da reicht schon ein Unterschied mit gepackt zu zoned, ins besonders bei unterschiedlichen Längen.
Hier hilft dann auch schon mal ein "cast(fromfield as totype)" um dem Optimizer zu helfen, den korrekten Index zu finden.
Ansonsten wird halt gerne ein Tablescan angewandt. Und wenn dann die Anzahl Zugriffe die Abfragezeit verlängert gibts halt einen SQL0666.
Das selbe gilt immer wieder für fehlende Indizes die zur gwünschten Where-Klausel passen müssen.
Hierbei kann man sich auch nicht immer auf die vorgeschlagenen Indizes verlassen.
Wenn man diese dann anlegt nimmt SQL sie dann doch nicht.

Mit unserer BI-Anwendung wird häufig per selbstgestricktem SQL vom Kunden auf die IBM i zugegriffen.
Hier beobachte ich das dann häufig, dass z.B. das Joblog gerne mit 1000den Meldung vollgeschrieben wird, dass eine Typanpassung erforderlich ist. Wenn dann auch noch alle paar Sekunden 1 Joblog mit 4000 Seiten erstellt wird, gibts auch schon mal eine 98%-Platte-Voll-Warnung.

Um dem SQL0666 aus dem Weg zu gehen, wird dann aus ODBC-Sicht gerne der Timeout auf 3600 oder schon mal 32000 Sekunden gesetzt obwohl der SQL dann tatsächlich in erheblich kürzerer Zeit ausgeführt wird.

[Frankk]

Hallo,
ich habe mir nun gleich mal einen Index gebastelt. mit create index .... hat auch soweit funktioniert. Jetzt bringt mir mein strsql auf der i5 (wenn ich auf die Datei einen select mache) den Hinweis:

SQL7011 xxx in yyy keine Tabelle, Sicht oder physische Datei.

Verstehe ich da was falsch? Mit wrkobj bringt er: Art: *file Attribut: LF

Das erzeugen des Indexes ging rasend schnell.

[Fuerchau]

Du machst den Select immer auf die Tabelle oder View.
Der zu verwendende Index wird von SQL selber ermittelt.

[B.Hauser]

Wenn Du dem Optimizer eine logische Datei angibst, dann interessiert ihn das relativ wenig.
Das SQL-Statement wird im Untergrund umgeschrieben. Dabei nimmt der Optimizer aus der DDS Beschreibung lediglich die Feld-Auswah, Join-Anweisungen und Select/Omit-Anweisugen, und schreibt das SQL Statement basierend auf diesen Informationen um. Der Schlüssel der logischen ist an dieser Stelle schnutzpiepegal. Die logische Datei wird wie eine View (immer ungeschlüsselt!) behandelt. Die eigentliche Optionierung beginnt erst nach dem Umschreiben. Zu diesem Zeitpunkt ist nicht mehr bekannt, dass eine logische Datei mit einem Schlüssel vorgegeben war. Wird die logische Datei genommen, ist es nichts weiter als Zufall.

Indices werden von dem Optimizer verwendet um schnell auf die Daten zugreifen zu können.
Übrigens mit SQL kann man einen Index nicht direkt ansprechen, aber man kann einen Index mit Native I/O (in RPG und COBOL) wie eine beliebige Datei (F-Bestimmungen / Chain / SetLL / Read ...) verarbeiten.

Um Dein Statement zu optimieren, müsste man
a) das Statement zunächst einmal sehen auch hier können Probleme liegen, dergestalt, dass SQL zwar die Sätze findet, jedoch keinen Index verwenden kann.
b) die vorhandenen Zugriffswege kennen
c) die Daten bzw. Datenzusammensetzung kennen um zu entscheiden, ob und welcher Index erforderlich ist.

Birgitta

[Fuerchau]

Seit ca. V7R2 (bzw. Create Index ... where ...) kann der Optimizer auch LF's mit Select/Omit finden und verwenden.
Wie oben gesagt, die Where-Klausel muss exact stimmen.