[NEWSboard IBMi Forum]
Seite 1 von 2 1 2 Letzte
  1. #1
    Registriert seit
    Sep 2018
    Beiträge
    53

    Timeout bei SQL Abfragen

    Hallo,
    wir haben ein Problem mit SQL-Abfragen von einem IIS-8 Server an die i5 via ODBC.

    Größere, geschachtelte SQL-Abfragen werden morgens nicht abgearbeitet. Irgendwann bringt die Browseranwendung eine Zeitüberschreitung. Der Zugriff erfolgt über ODBC mit einer persistenten Verbindung (60 Sekunden).

    Das komische an der Sache ist: Hat er einmal eine Abfrage korrekt getätigt was er nach mehrmaligem Anlauf tut, tritt das Problem den ganzen Tag nicht mehr auf. Die Abfrage an sich benötigt dann nur noch < 1 Sekunde.

    Im Job QZDASOINIT (Sonderregister: CLIENT_APPLNAME: PHP-CGI) kann ich anhand des Joblogs keine Fehler feststellen.

    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.

  2. #2
    Registriert seit
    Feb 2017
    Beiträge
    22
    Hi,

    lass dir das Statement mal SQL Performance Center vom ACS anzeigen. Nach dem IPL muss der Zugriffsweg beim ersten Ausführen des Statements wahrscheinlich neu aufgebaut werden. Nachdem der Zugriffsweg dann steht und im Plan Cache vorgehalten wird, sind nachfolgende Aufrufe schneller abgearbeitet.

    Ggf. kann dir der Analyzer auch Hinweise bzgl. Optimierung deines SQLs geben, um das Risiko eines Timeouts zu mindern.

    Gruß,
    Manuel

  3. #3
    Registriert seit
    Aug 2001
    Beiträge
    2.606
    Wie Manuel sagte, du musst Deine Abfragen analysiseren.
    Am einfachsten geht das, indem Du über ACS in das Performance Center reinschaust und Dir die SQL-Statements anschaust ... und nach lang laufenden Statements suchst.

    Vermutlich wird wie Manuel bereits vermutet hat ein oder mehrere temporäre Indices aufgebaut ... und das dauert. "Temporäre" Indices bleiben so lange existent, wie ein Access Plan, der diesen Index verwendet im SQE Plan Cache existiert. Wenn Ihr die Maschine jede Nacht herunterfahrt, wird der Plan Cache gecleart, d.h. alle Access Pläne verschwinden und damit auch die temporären Indices. Am nächsten Morgen muss dann alles neu erstellt werden.
    Sollte es wirklich so sein, dass temporäre Indices verwendet werden, sollten diese permanent angelegt werden. Permanente Indices werden beim IPL nicht gelöscht und somit müsste der Zugriff am nächsten Morgen schneller sein.

    Tatsächlich dauert der Aufruf eines SQL-Statements (in einem Job oder einer Verbindung) immer länger als die Folge-Aufrufe. Der Grund dafür ist, dass ein FULL OPEN ausgeführt werden muss. Bei dem FULL OPEN wird eine volle Optimierung einschließlich dem Aufbau des Datenpfades (Open Data Path) ausgeführt. Das Öffnen des Datenpfades ist der zeitaufwändigste Schritt beim Ausführen eines SQL-Statements. Sofern der Datenpfad wiederverwendbar ist, wird er nicht gelöscht und beim Erneuten Ausführen des gleichen SQL-Statements werden lediglich die Daten aktualisiert.
    ... wenn dann beim FULL OPEN auch noch ein Index erstellt werden muss ...

    ... allerdings scheint beim Timeout nicht unbedingt die tatsächliche Zeit, sondern eine geschätze Ausführungszeit ausschlaggebend zu sein. Wir hatten den Fall schon beim Kunden, dass die Abfrage beim direkten Ausführen auf der i (ACS oder Green Screen) innerhalb von ein paar Sekunden durch war, der ODBC-Zugriff jedoch wegen Timeout abgebrochen bzw. gar nicht erst ausgefürht wurde, da die geschätze Runtime > 30 Sekunden war.
    (ob es dafür inzwischen einen Fix oder PTF gibt, kann ich nicht sagen)

    Vielleicht kannst Du ja auch irgendwo in der ODBC-Verbindung die Timeout-Zeit setzen.

    Birgitta
    Birgitta Hauser

    Contractor for Fresche Solutions Inc.
    Anwendungsmodernisierung, Beratung, Schulungen im Bereich RPG, SQL und Datenbank
    IBM Champion 2020
    RPG und SQL-Schulungen
    Erstellen und Verarbeiten XML- und JSON-Daten mit SQL

  4. #4
    Registriert seit
    Aug 2006
    Beiträge
    1.890
    Zitat Zitat von Frankk Beitrag anzeigen
    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

  5. #5
    Registriert seit
    Sep 2018
    Beiträge
    53
    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

  6. #6
    Registriert seit
    Sep 2018
    Beiträge
    53
    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!

  7. #7
    Registriert seit
    Feb 2001
    Beiträge
    18.495
    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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: http://www.fuerchau.de/software/upload400.htm
    BI? Da war doch noch was: http://www.ftsolutions.de

  8. #8
    Registriert seit
    Sep 2018
    Beiträge
    53
    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.

  9. #9
    Registriert seit
    Feb 2001
    Beiträge
    18.495
    Du machst den Select immer auf die Tabelle oder View.
    Der zu verwendende Index wird von SQL selber ermittelt.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: http://www.fuerchau.de/software/upload400.htm
    BI? Da war doch noch was: http://www.ftsolutions.de

  10. #10
    Registriert seit
    Aug 2001
    Beiträge
    2.606
    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
    Birgitta Hauser

    Contractor for Fresche Solutions Inc.
    Anwendungsmodernisierung, Beratung, Schulungen im Bereich RPG, SQL und Datenbank
    IBM Champion 2020
    RPG und SQL-Schulungen
    Erstellen und Verarbeiten XML- und JSON-Daten mit SQL

  11. #11
    Registriert seit
    Feb 2001
    Beiträge
    18.495
    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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: http://www.fuerchau.de/software/upload400.htm
    BI? Da war doch noch was: http://www.ftsolutions.de

  12. #12
    Registriert seit
    Mar 2002
    Beiträge
    4.906
    Zitat Zitat von Frankk Beitrag anzeigen
    Hallo,
    wir haben ein Problem mit SQL-Abfragen von einem IIS-8 Server an die i5 via ODBC.

    Größere, geschachtelte SQL-Abfragen werden morgens nicht abgearbeitet. Irgendwann bringt die Browseranwendung eine Zeitüberschreitung. Der Zugriff erfolgt über ODBC mit einer persistenten Verbindung (60 Sekunden).

    Das komische an der Sache ist: Hat er einmal eine Abfrage korrekt getätigt was er nach mehrmaligem Anlauf tut, tritt das Problem den ganzen Tag nicht mehr auf. Die Abfrage an sich benötigt dann nur noch < 1 Sekunde.

    Im Job QZDASOINIT (Sonderregister: CLIENT_APPLNAME: PHP-CGI) kann ich anhand des Joblogs keine Fehler feststellen.

    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.
    ... beim Timeout über QRYTIMLMT sollten die diagnostics des Optimizers im Joblog zu finden sein, bist Du sicher, dass Du im richtigen Joblog nachsiehst?

    Sieht mir eher nach einem Client Problem aus (persistente Verbindung, die mit der unkontrollierten Beendigung des Database Servers nicht klarkommt). Wenn im Joblog tatsächlich keine diagnostics stehen, ist der PTF Stand krumm:

    D*B
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

Ähnliche Themen

  1. Mit JSON_TABLE Array abfragen
    Von dschroeder im Forum NEWSboard Programmierung
    Antworten: 2
    Letzter Beitrag: 05-11-19, 15:35
  2. Webservice per SQL abfragen
    Von KM im Forum NEWSboard Programmierung
    Antworten: 11
    Letzter Beitrag: 20-02-18, 12:06
  3. Java via QSH - ENDJOB abfragen
    Von alex.kretschmer im Forum NEWSboard Java
    Antworten: 6
    Letzter Beitrag: 29-09-16, 11:22
  4. UDP Socket timeout
    Von max40 im Forum NEWSboard Programmierung
    Antworten: 0
    Letzter Beitrag: 27-01-16, 11:58
  5. OVRDBF in CL-PGM abfragen
    Von Amalie im Forum IBM i Hauptforum
    Antworten: 1
    Letzter Beitrag: 23-11-01, 08:37

Stichworte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •