extrem langsame Datenübertragung von IBM i

[mahones]

Hallo zusammen!

Einige Anwender bei uns nutzen noch die gute, alte "Datenübertragung von der IBM i", um Daten in Excel o.ä. weiter zu verarbeiten.

Jetzt stellt ein User fest, dass die Übertragun (von 12.000 Sätzen) bei ihm auf einmal unglaublich lange dauert - mehr als 5 Minuten. Vorher - er hat es zuletzt im Dezember aufgerufen - brauchte es nur wenige Sekunden...

Wenn ich diese Übertragung bei mir auf meinem PC mache, dauert es ebenfalls nur 5 Sekunden.

Wir haben bereits Konfiguration, Hardwareänderungen, etc. geprüft - alles in Ordnung.
Es ist eine einfache Übertragung mittels einer .dtf-Datei (oder auch .tto / .rto) zusammen mit einer .fdf-Datei. Ziel ist eine XLS-Datei...

Woran kann es liegen, dass es bei dem Benutzer (auf einmal) so lange dauert?

Vielleicht habt ihr ja noch einen Tipp, wie man hier eine akzeptable Laufzeit erzielen kann.

[Fuerchau]

Nun, da ist wieder viel Spekulation angesagt.
Wenn das auf deinem PC nur 5 Sekunden dauert, dann ist die AS/400 schon mal außen vor.
Jetzt kann es nur noch an diversen Netzeinstellungen (QoS o.ä.) liegen, dass die Übertragung hier ausgebremst wird.
Ggf. hat irgendwer eine Priorisierung auf Portebene festgelegt, die bei den "normalen" Usern das Übertragen von großen Datenmengen entschleunigt damit das Netz keinen großen Belastungen ausgesetzt wird.

Allerdings ist hier der Nebel, in dem wir stochern, äußerst dicht.

[mahones]

Tja, das mit der IBMi haben wir auch schon ausgeschlossen, aber dass es bewusste Einschränkungen, was Traffic / Mengen angeht, gibt, ist ebenso unwahrscheinlich.
Wir sind aber in Sachen Netzwerk auch tatsächlich dabei, dass diese Übertragung bei anderen "normalen" Benutzern ausgeführt wird, dass der Benutzer sich einmal an einem anderen PC anmeldet, dass er seinen PC mal woanders anschließt, etc.

Der Hilferuf hier erfolgte hauptsächlich, um parallel zu prüfen, ob es bei der Datenübertragung (oder dem Umfeld) evtl. Schalter gibt, die auf wundersame Weise vielleicht bedient wurden.

Aber schonmal danke für die schnelle Hilfe!

[TheDevil]

Hallo.
Neue Virenschutzsoftware auf dem Rechner des Kollegen ?
Releasewechsel auf 7.2 ?
Wir haben hier auch derzeit das Phänomen das z. B. SQL Abfragen über die ODBC Schnittstelle mal schnell und dann wieder verdammt langsam laufen. Dies aber erst nach einen Wechsel von 7.1. auf 7.2.
Wir und IBM sind am suchen wie die Karnickel aber haben dazu z. B. auch noch nichts gefunden.
Gruß,
Ralf

[Fuerchau]

Das liegt zum großen Teil an dem neuen Optimizer.
Ich habe auch schon festgestellt, dass das zwangscasten in einen passenden Typ beim
join xxx on ...
where yyy ...
zu besseren Ergebnissen führt.
Aus historischen Gründen ist ein Feld mal Decimal (gepackt), mal Numeric (gezont). Dies führt ggf. zur Nichtverwendung von Indizes.
Ein anderer z.T. fataler Fehler ist der Vergleich eines Zeichenfeldes mit einem numerischen Wert.

Beispiel (aus der XPPS-Welt):

where WKNR = 001 ...

Hier hat der Programmierer schlicht die Hochkomma vergessen.
"Früher" hat der Optimiizer automatisch "where WKNR = cast(001 as char(3))" gemacht und konnte somit einen Index über WKNR machen.
Der heutige Optimizer macht daraus "where cast(WKNR as decimal(3, 0)) = 001".
Wie man sieht, der Unterschied führt dazu, dass eine Indexverwendung nicht mehr möglich ist.
Woher ich das weiß?
Ganz einfach: in den Daten gab es leider ein WKNR mit Blank, was zu einem Dezimalfehler führte.
Mit Debugger stand dann im Fehlertext "Fehler bei Datenumsetzung cast(WKNR...".
Mit Indexverwendung wäre die DB an dem Satz gar nicht vorbeigekommen.
Somit konnte ich den SQL korrigieren und es ging wieder gewohnt fix.

Ich kann hier nur ähnliches vermuten, dass Typanpassungen vorgenommen werden, die eine Indexverwendung verhindern. Warum der Optimizer nun die Felder an Stelle der Konstanten castet entzieht sich mir völlig.
Das ist schon fast wieder wie bei einem V5R2!-Kunden bei dem ich grundsätzlich bei Beziehungen passend zum Schlüssel casten muss um performant zu sein.