SQL Performance Probleme im Batch

[BenderD]

... solange der im QDBGETMQO ist, wird vom DBMON auch nix geschrieben. spannend wird es allenfalls, sobald der davon zurückkommt, wenn er das tut und nicht über irgendeinen schwindeligen timeout rausfliegt und fertig ist... jedenfalls liefert google nach QDBGETMQO massig PTFs hast Du schon bug report gemacht und Software defect reklamiert?

D*B

[itec01]

... solange der im QDBGETMQO ist, wird vom DBMON auch nix geschrieben. spannend wird es allenfalls, sobald der davon zurückkommt, wenn er das tut und nicht über irgendeinen schwindeligen timeout rausfliegt und fertig ist... jedenfalls liefert google nach QDBGETMQO massig PTFs hast Du schon bug report gemacht und Software defect reklamiert?

D*B

ja, da sind wir dran.
Ich habe jetzt das SQL nochmals analysiert und habe das Problem gefunden:
'AND DNHID IN (SELECT CDIDNID FROM CDICTLP '
'WHERE CDIBAID = 0 AND CDISHID = '' '') '
In der Datei CDICTLP gibt es 148000 Datensätze und in der Datei wo die DNHID herkommt gibt es ca. 8 Mio. Sätzen. Ich denke, dass hier irgendwo das Problem liegt.
Dieser Eintrag verursacht den Fehler. Ich habe es ausgesternt und siehe da, es funktioniert super schnell. Weiß der Geier wieso dies interaktiv funktioniert. Hier muss ein Fehler im embedded SQL vorliegen.
Ich werde das SQL von "IN" auf einen join umbauen und sehen was dann passiert.

Die täglichen SQL's, welche funktionieren arbeiten so:
AND DNHID IN (SELECT CDIDNID FROM CDICTLP '+
WHERE CDIBAID = ' + %editc(CDIBAID:'X') +
AND CDISHID = ''' + CdiShId + ''' ' +
AND CDIDISC = ''' + pi@DisC + ''' ' +') '

Da ist die Satzanzahl deutlich geringer.

Klaus

[Fuerchau]

Ein Inner join kann da schon helfen, ggf. auch ein exists (select ...).
Der "in (select ...)" wird schon mal je einzelnem Datensatz ausgeführt was die lange Ausführungszeit erklärt.
Wobei der schnellste Zugriff dann über einen Index mit "=" bzw. "between"-Vergleichen gut funktioniert (between möglichst am Ende).