DRDA mit Remote SQL Befehl funktioniert nicht mehr

[BenderD]

- was sagt denn das Joblog auf dem Database Server (am besten Job mit STRSRVJOB und STRDBG in Debug Mode versetzen, dann ist die Protokollierung etwas geschwätziger.
- warum macht ihr das als dynamic SQL und was passiert gegebenen Falls bei demselben Zugriff im static SQL?

D*B


Hallo,

ich habe nun auf der Maschine 1 die höchst mögliche Gruppen und Cum PTFs installiert.
Zusätzlich noch
SI26318|SE27758||2007-01-23|38UTIL SELECT * FROM
SI25882|SE27450||2006-12-12|OSP-DB-MSGCPF9190 KERBEROS
SI25841|SE27326||2006-12-22|OSP-DB-MSGMCH3402 MSGCPI8360
SI22701|SE24442||2006-02-24|OSP-DB ENCRYPTION OBJECT NOT
SI27365|SE28672||2007-08-11|OSP-DB-OTHER-F/STRINGHIGHUSE
SI26916|SE28217||2007-04-24|OSP-DB-MSGCPF325E PENDING

Jetzt habe ich mal ein anderes Programm verwendet. Hier ein auszug aus der Umwandlungsliste:

__________________________________________________ ____Spool-Datei_anzeigen____________________________________ __
Datei_._._._._._:___$SRP234_______________________ __________________________________________________ _____Seite/Ze
Steuerung_._._._.___-10________________________________________________ __________________________________Spalten_
Suchen__._._._._.___308___________________________ __________________________________________________ _____________
*...+....1....+....2....+....3....+....4....+....5 ....+....6....+....7....+....8....+....9....+....0 ....+....1...
___297_C___________________CALL______'QSQLOPEN'___ ________________________________SQL_______________ ____01_______
___298_C___________________PARM___________________ _SQLCA__________________________SQL_______________ ____01_______
___299_C___________________PARM___________________ _SQL_00000______________________SQL_______________ ____01_______
___300_C___________________END____________________ ________________________________SQL_______________ ___E01_______
___301_C___________________DOW_______SQLCOD_=_*ZER O_________________________________________________ ___B01_______
___302_C***_______________________________________ __________________________________________________ _____________
___303_C*EXEC_SQL_________________________________ __________________________________________________ _____________
___304_C*_FETCH_NEXT_FROM_REC_DYN_INTO_:ITNR1I,_:T EXT1G,_:BSUN1I,___________________________________ _____________
___305_C*_:WEGH1I,_:WGTU1I________________________ __________________________________________________ _____________
___306_C*END-EXEC______________________________________________ __________________________________________________
___307_C___________________Z-ADD_____-4____________SQLER6_________________________SQL___ 6_______________01_______
___308_C___________________CALL______'QSQROUTE'___ ________________________________SQL_______________ ____01_______
___309_C___________________PARM___________________ _SQLCA__________________________SQL_______________ ____01_______
___310_C___________________PARM___________________ _SQL_00006______________________SQL_______________ ____01_______
___311_C_____SQL_00009_____IFEQ______'1'__________ ________________________________SQL_______________ ___B02_______
___312_C___________________EVAL______ITNR1I_=_SQL_ 00011___________________________SQL_______________ ____02_______
___313_C___________________EVAL______TEXT1G_=_SQL_ 00012___________________________SQL_______________ ____02_______
___314_C___________________EVAL______BSUN1I_=_SQL_ 00013___________________________SQL_______________ ____02_______
___315_C___________________EVAL______WEGH1I_=_SQL_ 00014___________________________SQL_______________ ____02_______


Wenn ich das Programm debugge kann man feststellen, das er ca. 50 Sätze remote holt und dann auf dem Statement 308 stehen bleibt. Dieses Call QSQROUTE wird bei der Umwandlung reincompiliert und stammt von der IBM.

Im WRKACTJOB steht dieser Job dann auf Status: TIMW und das für immer und ewig.

Hoffentlich gibt es hierfür eine Lösung.

Gruß C.Schulz

[cs400_de]

Hallo zusammen,

danke für die Tipps: hier die Antworten:

1.) Statik Aufruf geht im Dialog mit STRSQL
2.) Statik Aufruf im RPG nicht getestet
3.) Den QRWTSRVR haben wir schon debugged. Da steht nichts im Protokoll. Absolut nichts. Sehr komisch. Werde das nochmal probieren.
4.) Der statische SQL läuft auch im iNavigator


Melde mich gleich nochmal wegen Punkt 3.

Gruß
C.Schulz

[cs400_de]

Habe den QRWTSRVR erneut debugged.
Es steht nichts nennenswertes im Log.
Außer das eine Verbindung von der V5R2 Maschine aufgemacht wurde.

Vielleicht mache ich auch was falsch?

Hier meine Vorgehensweise:

1. Ein funktionierende Remote SQL Abfrage (embedded laufen lassen).
2. Die Nummer des kurz erscheinenden Jobs notieren.
3. Nochmal ein funktionierendes laufen lassen.
4. Die Nummer des wieder erscheinenden QRWTSRVR Jobs ist die gleiche.
5. Das RPG mit der hängenbleibenden SQL Abfrage aufrufen.
6. In 5 Sekunden geht der RPG Job auf TIMW (auf der V5R2 Maschine)
7. innerhalb der 5 Sekunden strsrvjob und strdbg (ohne parms) auf den obigen Job aufrufen.

[Fuerchau]

Wie ich sehe, castest du die Felder, vergibts allerdings keine neue Namen.
Ggf. ist das hier das Problem, da die Order-By-Klausel auf ein Feld verweist, dass nicht in deiner Select-Liste steht !
Das ist zwar erlaubt, könnte aber das Problem sein.

Ergänze die Cast's mal mit einem Namen:

... cast(Feld as ...) Feld, ...

[BenderD]

... wenn ich das richtig verstehe, ist das zu spät, der debugger muss bereits vor dem open auf den Cursor gestartet sein.
Ich würde folgendes raten:
- Job auf Client (V5R2) unter debug starten, Breakpoint vor dem Connect
- Connect User und Kennwort auf dezidiertes Benutzerprofil ändern
- Step hinter den Connect
- WRKOBJLCK BenutzerProfil *USRPRF auf Server liefert den passenden SQL Server Job QRWTSRVR
- STRSRVJOB auf diesen Job
- STRDBG
- jetzt den Job auf dem Client weiter schnurren lassen und in dem Serverjob nachsehen was passiert, insbesondere sind die Diagnostics interessant (Zugriffsplan und estimated Dauer)

BTW wie groß ist die abgefragte Tabelle? Vielleicht dauert das nur fast ewig und Stunden später passiert noch was!

D*B


Habe den QRWTSRVR erneut debugged.
Es steht nichts nennenswertes im Log.
Außer das eine Verbindung von der V5R2 Maschine aufgemacht wurde.

Vielleicht mache ich auch was falsch?

Hier meine Vorgehensweise:

1. Ein funktionierende Remote SQL Abfrage (embedded laufen lassen).
2. Die Nummer des kurz erscheinenden Jobs notieren.
3. Nochmal ein funktionierendes laufen lassen.
4. Die Nummer des wieder erscheinenden QRWTSRVR Jobs ist die gleiche.
5. Das RPG mit der hängenbleibenden SQL Abfrage aufrufen.
6. In 5 Sekunden geht der RPG Job auf TIMW (auf der V5R2 Maschine)
7. innerhalb der 5 Sekunden strsrvjob und strdbg (ohne parms) auf den obigen Job aufrufen.

[cs400_de]

BTW wie groß ist die abgefragte Tabelle? Vielleicht dauert das nur fast ewig und Stunden später passiert noch was!

D*B

Ja das hatten wir auch schon gedacht.
Wir haben auch bei manchen Jobs / Tabellen schon 4 Tage gewartet und der TIMW status verschwindet nicht mehr.
Wenn man den Server Job beobachtet, sieht man bei funktionierenden langen Abfragen immer mal wieder, so alle 3-5 Minuten einen I/O und relativ wenig CPU Zeit. Bei den Jobs die auf der rufenden Maschine mit TIMW stehen bleiben gibt es auf der Zielmaschine keine I/Os mehr (tagelang) und doch einiges an CPU Zeit.

Gruß

[cs400_de]

Wie ich sehe, castest du die Felder, vergibts allerdings keine neue Namen.
Ggf. ist das hier das Problem, da die Order-By-Klausel auf ein Feld verweist, dass nicht in deiner Select-Liste steht !
Das ist zwar erlaubt, könnte aber das Problem sein.

Ergänze die Cast's mal mit einem Namen:

... cast(Feld as ...) Feld, ...


Hallo,

wir haben die CASTs eingebaut und es fällt wieder in den berühmten TIMW Status ohne erkennbare I/Os auf der Zielmaschine.

Gruß

[Fuerchau]

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.

PS:
Warum castest du überhaupt ?

[BenderD]

- 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.
- was die von Baldur angesprochenen Casts angeht, da ist der Cast in der Where Klausel möglicherweise tödlich - der führt zum full table scan, falls die Query Engine den ernster nimmt als den order by.

D*B


Ja das hatten wir auch schon gedacht.
Wir haben auch bei manchen Jobs / Tabellen schon 4 Tage gewartet und der TIMW status verschwindet nicht mehr.
Wenn man den Server Job beobachtet, sieht man bei funktionierenden langen Abfragen immer mal wieder, so alle 3-5 Minuten einen I/O und relativ wenig CPU Zeit. Bei den Jobs die auf der rufenden Maschine mit TIMW stehen bleiben gibt es auf der Zielmaschine keine I/Os mehr (tagelang) und doch einiges an CPU Zeit.

Gruß

[cs400_de]

- Job auf Client (V5R2) unter debug starten, Breakpoint vor dem Connect
- Connect User und Kennwort auf dezidiertes Benutzerprofil ändern
- Step hinter den Connect
- WRKOBJLCK BenutzerProfil *USRPRF auf Server liefert den passenden SQL Server Job QRWTSRVR
- STRSRVJOB auf diesen Job
- STRDBG
- jetzt den Job auf dem Client weiter schnurren lassen und in dem Serverjob nachsehen was passiert, insbesondere sind die Diagnostics interessant (Zugriffsplan und estimated Dauer)



Job 821926/QUSER/QRWTSRVR von Benutzer DVSCHULZ mit Angabe SPLFILE(*NO)
angehalten.
Job 821926/QUSER/QRWTSRVR freigegeben von Benutzer DVSCHULZ.
Job 821926/QUSER/QRWTSRVR durch DVSCHULZ geändert.
PREPARE für Anweisung STMT0001 beendet.
****: Debug-Nachrichten des Optimierungsprogramms für Abfrage werden
gestartet.
Alle Zugriffspfade wurden für Datei MARC berücksichtigt.
Zugriff nach Eingangsfolge für Datei MARC verwendet.
****: Debug-Nachrichten für Abfrage werden beendet.
ODP erstellt.
Blockung für Abfrage.
Cursor C1 eröffnet.
985 Zeilen von Cursor *N abgerufen.



Im iNAV zeigt er im Visual Explain 4 Steps an:

1 Table Scan
2 Tempory Sorted List
3 Sorted List Scan
4 Final Select



Beim Final Select steht:
Total Estimated Run Time (ms) 7,557

und beim Stement Text:
SELECT CAST(MATNR AS CHAR(18)) MATNR, CAST(GPNUM AS CHAR(9)) GPNUM FROM IASP144/R3EMPDATA/MARC WHERE CAST(MANDTAS CHAR(3)) = ? ORDER BY MATNR