View Full Version : DRDA mit Remote SQL Befehl funktioniert nicht mehr
PS:Warum castest du überhaupt ?
Die Besonderheit der SAP Tabellen ist, das diese mit einer CCSID von 13488 (Grafikfelder) erstellt wurden. Will man von der V5R2 RPGle Anwendung auf Tabellen der SAP zugreifen so muss der JOB vorher mit CHGJOB CCSID(500) geändert werden.
Mit cast(menge as char(50) ccsid 500) wird das Grafikfeld in ein Charakterfeld umgewandelt.
Mit translate(... , ’,’ , ’.’) werden Punkte zu Kommas.
Mit cast(... as numeric(7, 2)) wird das Ergebnis in numerisch umgewandelt.
Eine direkte Umwandlung von Graphik-Feldern in numerisch ist nicht möglich.
- wieviele Sätze haben die beteiligten Tabellen denn? 1 Mio, 10 Mio, 100 Mio oder einige 100 Mio?
- um hier Einblick zu bekommen sind die Messages beim open des Cursors wichtig, da sieht man, was die Query Engine vorhat und wie lange sie zu brauchen meint, und am einfachsten kommt man da halt im Debug dran.
D*B
A.) Die Abgefragte Tabelle MARC hat 828.154 Sätze.
B.) Im Visual Explain steht, wenn ich auf Tablescan klicke (Es gibt ja 4 grafisch dargestellte Schritte) unten im grauen Feld: DECLARE C1 CURSOR FOR DYNAMIC_SQL_007
dazu hier die Daten aus der rechten Anzeige.
Table Scan - R3SIDDATA.MARC
Attribut Wert
Table name, base table name, in...
Name of Table Being Queried MARC
Library of Table Being Queried R3SIDDATA
Member of Table Being Queried MARC
Long Name of Table Being Queried MARC
Long Library of Table Being Que... R3SIDDATA
Estimated Time Information (Sta...
Processing Time(ms) 7,263
Cumulative Time(ms) 7,263
Additional Table Info
Total Rows in Table 828,081
Table Size(bytes) 1,209,863,237
Active Table Rows 828,081
Deleted Table Rows 0.0
Estimated rows selected and qu...
Rows Selected Per Plan Step Ite... 828,081
Rows Processed During Last Pl... 828,081
Plan Step Iterations 1
Total Rows Selected 828,081
Total Rows Processed 828,081
Optimize for N Rows All
Percent Selectivity 100
Cumulative Percent Selectivity 100
Fetch N Rows All
Estimated Cost Information Abo...
Processing Time(ms) 7,263
I/O Or CPU Bound I/O Bound
CPU Cost(ms) 113.368
I/O Cost(ms) 7,263
I/O Count 9,345
Table Scan - R3SIDDATA.MARC
Attribut Wert
PreLoad Relation No
Memory Used(bytes) 47,321,146
Memory Constrained No
Cumulative Memory Constrained No
Actual Runtime Information
Actual Rows Selected Per Plan ... 828,086
Actual Rows Processed Per Pla... 828,086
Actual Plan Step Iterations 2
Actual Total Rows Selected 1,656,173
Actual Total Rows Processed 1,656,173
Information About the Plan Perf...
Contains Predicate Yes
Scrollable Yes
Plan Name Table Scan
Plan Step Type Logic
Reason Code Table Scan Cost Is Better
Plan Step Name Node_13
Statement Text SELECT Cast(MARC_1.MATNR A...
< 1 Mio Sätze => also nicht viel (es sei denn die Möhre pfeift auf dem letzten Loch.
laut Job Protokoll macht der einen full Table Scan (den ganzen Oops Nerv und Visual Explain Krams kannste getrost vergessen, das findet nicht in dem Job statt)
Die estimated Time müsste in den Messages in den Details zu finden sein, aber die 7,xyz Sekunden sind für die paar Sätze schon plausibel...
Ich gehe mal davon aus, dass die Meldungen alle schon nach dem open drin stehen und der erst beim fetch in den Wind düst. Sieht für mich heftig nach einem defect problem aus. Dir wird wohl nichts anderes übrig bleiben als zu versuchen das ganze auf der V6R1 Büchse only zu reproduzieren oder von einem höheren Release zuzugreifen - und selbst dann dürfte es schwierig werden die Coldline zur Arbeit zu tragen...
D*B
A.) Die Abgefragte Tabelle MARC hat 828.154 Sätze.
B.) Im Visual Explain steht, wenn ich auf Tablescan klicke (Es gibt ja 4 grafisch dargestellte Schritte) unten im grauen Feld: DECLARE C1 CURSOR FOR DYNAMIC_SQL_007
dazu hier die Daten aus der rechten Anzeige.
Table Scan - R3SIDDATA.MARC
Attribut Wert
Table name, base table name, in...
Name of Table Being Queried MARC
Library of Table Being Queried R3SIDDATA
Member of Table Being Queried MARC
Long Name of Table Being Queried MARC
Long Library of Table Being Que... R3SIDDATA
Estimated Time Information (Sta...
Processing Time(ms) 7,263
Cumulative Time(ms) 7,263
Additional Table Info
Total Rows in Table 828,081
Table Size(bytes) 1,209,863,237
Active Table Rows 828,081
Deleted Table Rows 0.0
Estimated rows selected and qu...
Rows Selected Per Plan Step Ite... 828,081
Rows Processed During Last Pl... 828,081
Plan Step Iterations 1
Total Rows Selected 828,081
Total Rows Processed 828,081
Optimize for N Rows All
Percent Selectivity 100
Cumulative Percent Selectivity 100
Fetch N Rows All
Estimated Cost Information Abo...
Processing Time(ms) 7,263
I/O Or CPU Bound I/O Bound
CPU Cost(ms) 113.368
I/O Cost(ms) 7,263
I/O Count 9,345
Table Scan - R3SIDDATA.MARC
Attribut Wert
PreLoad Relation No
Memory Used(bytes) 47,321,146
Memory Constrained No
Cumulative Memory Constrained No
Actual Runtime Information
Actual Rows Selected Per Plan ... 828,086
Actual Rows Processed Per Pla... 828,086
Actual Plan Step Iterations 2
Actual Total Rows Selected 1,656,173
Actual Total Rows Processed 1,656,173
Information About the Plan Perf...
Contains Predicate Yes
Scrollable Yes
Plan Name Table Scan
Plan Step Type Logic
Reason Code Table Scan Cost Is Better
Plan Step Name Node_13
Statement Text SELECT Cast(MARC_1.MATNR A...
iNavigator und ODBC-Zugriffe verwenden keinen DRDA-Zugriff sondern die QZDA-Jobs.
Du kannst DRDA nur z.B. von einem anderen V6R1-System oder per DB2/Connect (oder PHP mit embedded DB2-Zugriff, o.ä.) verwenden.
Daher ist die Aussage, dass es über iNavigator geht nicht aussagefähig.
Dir wird wohl nichts anderes übrig bleiben als zu versuchen das ganze auf der V6R1 Büchse only zu reproduzieren oder von einem höheren Release zuzugreifen -
D*B
Hallo,
habe nun das Programm abgespeckt auf eine andere V6R1 Partition portiert, die SQL Packages erstellt und siehe da es läuft durch und zwar gegen die DB auf dem IASP einer anderen V6R1 Kiste. So wie es laufen sollte. Mit allen CASTS usw.
Das heißt für mich das V5R2 ein Problem macht.
Gruß
C.Schulz
Klappe zu, Affe tot - dann ist das ein bugfeature zum ärgern von Altrelease Nutzern, sprich man hat eine Treiber Inkompatibilität eingebaut, damit die betreffenden Shops einen (Kosten pflichtigen) upgrade machen (oder ihr SAP auf einer anderen Büchse laufen lassen - Oracle freut sich...).
Was macht ihr mit den Programmen? Für Batch Übertragungen könnte man da auch auf Java umsteigen...
D*B
Hallo,
habe nun das Programm abgespeckt auf eine andere V6R1 Partition portiert, die SQL Packages erstellt und siehe da es läuft durch und zwar gegen die DB auf dem IASP einer anderen V6R1 Kiste. So wie es laufen sollte. Mit allen CASTS usw.
Das heißt für mich das V5R2 ein Problem macht.
Gruß
C.Schulz
Hallo,
ich werde die entsprechenden Tabelle so nochmal auf der V5R2 Maschine erstellen und dann per CPYTOIMPF usw. ins IFS runter, rüber auf die andere Maschine und wieder hoch.
Ich mach mit dem Vorschlag vom Holger weiter:
http://newsolutions.de/forum-systemi-as400-i5-iseries/system-i-hauptforum/15276-sav-und-rst-von-v6r1-nach-v5r2.html
Gruß
C.Schulz
Cast ist hier wohl nicht erforderlich, da 13488 auch in V5R2 unterstützt wird.
Definiere deine Felder als Typ C, der Fetch stellt die Daten korrekt zur Verfügung.
Mit %char kannst du dann in SBCS und %dec die Zahl umwandeln.
Du kannst auch normale CHAR-Felder als Ziel für den Fetch nehmen, SQL wandelt dann automatisch in die Default-CCSID des Job's um.
Es sollte nie ein Job mit CCSID 65535 laufen !
gibt es im Joblag (möglicherweise nur unter debug) warnings beim fetch? da hat sich was bei V6R1 geändert (Stichwort Ersatzzeichen)...
D*B
Hallo,
habe nun das Programm abgespeckt auf eine andere V6R1 Partition portiert, die SQL Packages erstellt und siehe da es läuft durch und zwar gegen die DB auf dem IASP einer anderen V6R1 Kiste. So wie es laufen sollte. Mit allen CASTS usw.
Das heißt für mich das V5R2 ein Problem macht.
Gruß
C.Schulz
Hallo,
ich könnte mir schon vorstellen, dass R520 ein Problem macht, denn von IBM werden immer nur zwei Releases down unterstützt. Ich denke zuvor wurde R540 genutzt, dann sind dies nach R520 zwei Releases. Laut dem IBM Dokument gibt es ja schon bereits Probleme mit dem Support für R530.
Das dürfte eigentlich egal sein, da der Zugriff ja per DRDA funktioniert und somit das V6R1 nicht weiß oder wissen muss, welches System da zugreift.
Ich könnte ja auch mit DB2/Connect von ganz woanders her kommen (Z/Systems, PHP, o.ä.).
Es muss also was am DRDA inkompatibel geändert worden sein.