Timeout bei SQL Abfragen

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

[holgerscherer]

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

Das ist Glaubenssache - je nach dem, wie intensiv der Kunde vorher testen kann und will, wenn er denn will. Die Zeitspanne hier liegt zwischen Wöchentlich und Weihnachten.

[BenderD]

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