Timeout bei SQL Abfragen

[KingofKning]

Hallo,

Die Frage ist:
Warum bekommt er Anfangs ein Timeout und später geht es wieder? Zur Information: Die i5 wird frühmorgens nach erfolgter Datensicherung durchgestartet. Offensichtlich dadurch bedingt tritt das Problem immer wieder nur morgens auf. Release ist V7R3M0 mit aktuellem PTF Stand.

Die Frage ist, warum startet Ihr die Maschine immer neu? Ist ja kein Windows ;-)

GG 4132

[Frankk]

Hallo Brigitta,
danke für Deine sehr ausführliche Antwort. Tatsache ist, wenn ich den Job mir anschaue und die geöffneten Dateien mir näher anschaue, arbeitet der sehr an unserer Lagerbuchungsdatei (2,5 Mio. Datensätze). Ich habe daraufhin mir eine logische Datei gebaut (welche auch permanent in unserer Datenbibliothek angelegt ist), die die Datensätze vorselektiert. Von den 2,5 Mio. bleiben dann noch ca. 11000 übrig. Dennoch, obwohl wir auf diese logische Datei losgehen, arbeitet er immer wieder bis zum timeout an der logischen Datei. Mir scheint, dass ihn diese logische nicht gefällt und er im Hintergrund doch auf die Originaldatei geht und sich eine temporäre Sicht davon "bastelt".

...oder wie kann ich diese temp. Idices permanent anlegen?

Frank

[Frankk]

Hallo,

klar wäre es eigentlich nicht notwendig täglich die Maschine neu durchzustarten. Einmal pro Woche würde auch genügen. Nur: Dann hätte ich das Problem am darauffolgenden Montag auch. Auch klar: Die Probleme würden sich dann deutlich reduzieren.

An dieser Schraube könnte man dann auch drehen!

[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.

[holgerscherer]

Hallo,

klar wäre es eigentlich nicht notwendig täglich die Maschine neu durchzustarten. Einmal pro Woche würde auch genügen. Nur: Dann hätte ich das Problem am darauffolgenden Montag auch.

Wenn der temporäre Speicher nicht zu sehr versaut und voll gemüllt wird, reicht auch einmal im Jahr. Denn mit dem IPL geht alles verloren, was im RAM liegt und vielleicht dem schnelleren Zugriff dienen kann. Und sei es nur ein kleiner Hinweis auf eine Verwendung von Zugriffspfaden.

[AG1965_2]

Die aktuelle best practice sollte doch eigentlich IPL 4x jährlich sein - wenn man die cum. PTFs eingespielt hat, oder?

[KingofKning]

Alternativ könnte er ja nach einem IPL ein SQL-Job mit der Abfrage laufen lassen. Das am besten 2mal hintereinander im 5 Minuten Abstand dann sind die Zugriffspfade wieder da.

Und dann hat man genügend Zeit zu analysieren wie es zu verbessern geht.

GG 4125

[Frankk]

Das klingt gut! Werde ich beim nächsten "Riesen-SQL" machen! Danke für den Hinweis mit dem IPL und Abfrage laufen lassen.

An alle nochmals ein herzliches Dankeschön für eure Hilfe! Einige Aspekte (mit der LF beispielsweise) kannte ich so noch nicht!

Wir haben unsere Anwendung aktuell nochmals überarbeitet und sind zu einer Storedprocedure (was auch durchaus performant ist) übergegangen.