-
SQL-Fehler CPF427F nach Systemwechsel
Hallo @all,
nach einem Systemwechsel von iSeries 825 auf i5 550
haben wir Probleme beim SQL-Zugriff vom Windows-Server.
Eine Abfrage scheitert mit CPF427F :
"Geschätzte Abfrageverarbeitungsdauer von 3265 überschreitet Zeitlimit von 600."
Vor dem Systemwechsel hat alles funktioniert.
Alle logischen Dateien der abgefragten physischen Datei sind weiterhin vorhanden. Auch die Systemwerte sind unverändert.
Weiß da jemand Bescheid ?
Vielen Dank im Voraus
H. Lossin
-
Nur zur Sicherheit: Wie steht denn der Systemwert QQRYTIMLMT?
-
Hallo,
"leider" auf *nomax, darin liegt es also nicht.
Uns ist jetzt aufgefallen, daß auch die noch funktionierenden SQL-Abfragejobs über ODBC jetzt viel länger laufen als vorher und gehörig CPU ziehen.
Ansonsten ist das neue System aber viel schneller als das Alte.
Irgendwas beim Systemwechsel muß da nicht sauber funktioniert haben, obwohl ich keinerlei Meldungen diesbezüglich hatte.
mfg
H. Lossin
-
Hallo,
hört sich nach neuer Query Engine, auch als "die phantastische SQE" bekannt, die zuweilen einen Hang zum full table scan hat, an. Neueste group PTFs für die Database einspielen, wenn die schon drin sind, auf die nächsten hoffen...
Ich vermute mal, dass es auch keine vagabundierende QAQQINI ist, als Workaround geht höchstens noch reichlich order by auf vorhandene Zugriffspfade, wenn man diese Freiheit denn hat.
mfg
Dieter Bender
Zitat von lossin
Hallo,
"leider" auf *nomax, darin liegt es also nicht.
Uns ist jetzt aufgefallen, daß auch die noch funktionierenden SQL-Abfragejobs über ODBC jetzt viel länger laufen als vorher und gehörig CPU ziehen.
Ansonsten ist das neue System aber viel schneller als das Alte.
Irgendwas beim Systemwechsel muß da nicht sauber funktioniert haben, obwohl ich keinerlei Meldungen diesbezüglich hatte.
mfg
H. Lossin
-
Das Problem hatten wir auch.
Lösungsvorschlag der IBM:
Anlegen einer LF mit Select-Bedingung. Dies führt dazu, dass der alte Optimizer verwendet wird (warum auch immer).
Es hat zumindest funktioniert.
Eine QAQQINI wird von ODBC nur bedingt verwendet, das QRYTIMLMT jedenfalls nicht. Die QueryTimout des ODBC-Aufrufes (ADO-Commandobjekt) wird verwendet.
-
Vorsicht: beide Fehler in der Datenbank existieren weiterhin:
- SQE macht full table scan trotz index (BTW, das versucht sie schin unter V5R3 nach jedem Group PTF)
- irgendwoher zieht er sich die QRYTIMLMT(600)
Im übrigen wirkt eine globale QAQQINI auch auf ODBC, oder man kann sie setzen, je nach Treiber, in jedem Fall per stored Procedure.
letzteres wäre auch noch ein Versuch für einen Workaround, vermutlich allerdings mit katastrophalen Folgen für die Systemlast.
Das sieht mir alles nach einem KO Kriterium für die Installation von V5R4 aus, wenn man massiv SQL verwendet, zumindest im Database Server Umfeld.
mfg
Dieter Bender
Zitat von Fuerchau
Das Problem hatten wir auch.
Lösungsvorschlag der IBM:
Anlegen einer LF mit Select-Bedingung. Dies führt dazu, dass der alte Optimizer verwendet wird (warum auch immer).
Es hat zumindest funktioniert.
Eine QAQQINI wird von ODBC nur bedingt verwendet, das QRYTIMLMT jedenfalls nicht. Die QueryTimout des ODBC-Aufrufes (ADO-Commandobjekt) wird verwendet.
-
Bei ODBC-Zugriffen (zumindest aus Windows mit OLEDB/ODBC-Treibern) wird das Default-QueryTimeout im Connection-Objekt festgelegt.
Dieses überschreibt einen Eintrag in der QAQQINI bzw. den Systemwert.
Pro Command-Objekt (Query-Objekt) kann das Timeout wieder geändert werden.
-
Hallo Ihr Beiden,
ich störe Euren Dialog ja nur ungerne :-)
aber ich spiele jetzt erstmal die aktuellsten PTFs ein und
hoffe auf das Wunder !
Wir haben übrigens zur Zeit noch V5R3.
Ansonsten hoffe ich, daß die Schlafmützen bei IBM es endlich packen unser System zu aktivieren, damit ich einen Call aufmachen
kann.
mfg
H.Lossin
-
Hallo,
die sogenannte SQE, von der so mancher schwärmt, wird seit längerer Zeit implementiert; mit jedem Release und mit jedem Database Group PTF kommt da ein Stück neu auf die Büchse, oft mit massiven Problemen für Database Server Betrieb und ähnliches SQL Umfeld. Was habt ihr denn für einen Group PTF Stand (WRKPTFGRP ?) für die Datenbank? Wenn der Blank ist, dann ist eure Maschine schlampig installiert und ich würde den Lieferanten an den Ohren ziehen und zu Ostern ein Schleifchen von selbigen binden, allerdings habt ihr dann Hoffnung, dass es funzt, es gibt da durchaus saubere Stände.
mfg
Dieter Bender
PS: mit V5R4 würde ich warten empfehlen - und Vorsicht bei Group PTFs Database - never run a changing System.
Zitat von lossin
Hallo Ihr Beiden,
ich störe Euren Dialog ja nur ungerne :-)
aber ich spiele jetzt erstmal die aktuellsten PTFs ein und
hoffe auf das Wunder !
Wir haben übrigens zur Zeit noch V5R3.
Ansonsten hoffe ich, daß die Schlafmützen bei IBM es endlich packen unser System zu aktivieren, damit ich einen Call aufmachen
kann.
mfg
H.Lossin
-
Bezüglich dieser SQE darfst du leider nicht auf Wunder hoffen.
Bei Einführung V5R3 musste ich meine ODBC-Timeouts im Client auf teilweise 30.000 Sekunden stellen, obwohl die spätere tatsächlich Antwortzeit nur ca. 3 Sekunden betrug.
Eben wegen der SQL0666-Fehlermeldung !
Eine Einstellung seitens der AS/400 gibt es da wirklich nicht.
-
@Baldur: für schwarz sehen bin ich zuständig
so Hoffnungslos ist das auch wieder nicht, ich kenne da eine Büchse mit V5R3, reinrassiger SQL Datenbank (ohne jede DDS erstellte logische), die massig generierte SQLs gegen diese Datenbank mit Terrabyte von Daten über ODBC loslässt und das läuft unter einem real existierenden Group PTF Stand stabil ohne jede CPF427F; den Group PTF Stand, den ändern wir allerdings nur in allergrößter Not und V5R4 kann warten.
Zitat von Fuerchau
Bezüglich dieser SQE darfst du leider nicht auf Wunder hoffen.
Bei Einführung V5R3 musste ich meine ODBC-Timeouts im Client auf teilweise 30.000 Sekunden stellen, obwohl die spätere tatsächlich Antwortzeit nur ca. 3 Sekunden betrug.
Eben wegen der SQL0666-Fehlermeldung !
Eine Einstellung seitens der AS/400 gibt es da wirklich nicht.
-
Wenn es wirklich über den iSeries Access ODBC-Treiber läuft, gibt es im ODBC-TreiberManager unter "Leistung" und Button "Erweitert" die Möglichkeit ein Häkchen zu deaktivieren.
Abfragezeitlimit zulassen
Hiermit kann die Anwendung das Attribut für das Abfragezeitlimit festlegen.
Bei Inaktivierung dieses Kontrollkästchens wird die Unterstützung des Attributs für das Abfragezeitlimit inaktiviert.
SQL-Abfragen sind dann solange aktiv, bis sie vollständig ausgeführt worden sind
Die entsprechende DSN property heisst :
QueryTimeout=0
siehe auch hier :
IBM - ODBC Query Timeout Property: SQL0666 Estimated Query Processing Time Exceeds Limit
So wie es aussieht gehen deine Abfrage aber über die Jet-Engine bzw. DAO.
Die zugehörigen properties - ConnectionTimeout (default=600) und QueryTimeout(default=60) - findest du in der Windows-Registrierung (Regedit.exe) unter :
HKEY_LOCAL_MACHINE\Software\Microsoft\Jet\3.5(oder 4.0)\Engines\ODBC
Similar Threads
-
By olbe in forum NEWSboard Programmierung
Antworten: 2
Letzter Beitrag: 28-12-06, 13:53
-
By deni87991 in forum IBM i Hauptforum
Antworten: 11
Letzter Beitrag: 08-08-06, 13:50
-
By jakarto in forum IBM i Hauptforum
Antworten: 2
Letzter Beitrag: 24-07-06, 13:41
-
By GraueEminenz in forum NEWSboard Programmierung
Antworten: 1
Letzter Beitrag: 10-07-06, 11:58
-
By Kaufmann in forum IBM i Hauptforum
Antworten: 11
Letzter Beitrag: 28-06-06, 14:11
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks