BizTalk DB2-Adapter-Verbindungsfehler
https://stackoverflow.com/questions/24915
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianFrage
Meine Kollegen versuchen zu BizTalk 2006 R2 über DB2 / MVS-Adapter an einer Datenbank auf z / OS-Mainframe gehostet zu verbinden. Wenn die Verbindungseinstellungen zu testen, werden sie die folgende Störung zu erhalten
Could not connect to data source 'New Data Source':
The network connection was terminated because the host failed to send any data.
SQLSTATE: 08S01, SQLCODE: -605
Wenn in einer normalen Verbindungszeichenfolge und die Öffnung mit .NET-Code die Einstellungen setzen, das ist in Ordnung. Ich bin neu in BizTalk und DB2. Kann jemand empfehlen, was, wenn diese Fehler Flächen zu achten?
24. August 08:
Nun, wenn normaler .NET-Code mit einer normalen DB2-Verbindungszeichenfolge verwendet wird, kann die Verbindung hergestellt und Anfragen gestellt werden. Was diese DB2-Adapter meldet ist es nicht einmal eine richtige Verbindung Händedruck machen kann, geschweige denn von Abfragen. Ich bin nicht sicher, was sind die tatsächlichen Mechanismen zu einer DB2-Verbindung geschehen.
25. August 08:
Nach diese MSDN-Foren veröffentlichen , so scheint es, ein Login-Problem zu sein.
Ich habe das gesehen, und das ist hier nicht der Fall. Wenn wir die Benutzername als Package-Sammlung setzen trifft es immer noch das gleiche Problem.
26. August 08:
Aufgrund der spärlichen Informationen in Bezug auf Mainframe DB2-Datenbanken von Microsoft-Produkten verbindet, übernahm ich die Aufgabe rohe Netzwerkpakete zum Prüfen einen Anhaltspunkt zu bekommen, was zwischen dem .NET DB2-Providers Verbindung los ist (das funktioniert) und die BizTalk 2006 DB2-Adapter (die Bomben). Ich beobachtete DB2-Verkehr wird das DRDA-Protokoll durchgeführt werden. Und schloß schließlich die BizTalk Adapter Methode fehlschlägt von da was in dem Antwort des Servers SECCHKRM Paket aufgezeichnet ist
DRDA (Security Check)
DDM (SECCHKRM)
Length: 55
Magic: 0xd0
Format: 0x02
0... = Reserved: Not set
.0.. = Chained: Not set
..0. = Continue: Not set
...0 = Same correlation: Not set
DSS type: RPYDSS (2)
CorrelId: 0
Length2: 49
Code point: SECCHKRM (0x1219)
Parameter (Severity Code)
Length: 6
Code point: SVRCOD (0x1149)
Data (ASCII):
Data (EBCDIC):
Parameter (Security Check Code)
Length: 5
Code point: SECCHKCD (0x11a4)
Data (ASCII):
Data (EBCDIC):
Parameter (Server Diagnostic Information)
Length: 34
Code point: SRVDGN (0x1153)
Data (ASCII): \304\331\304\301@\301\331z@\301\344\343\310\305\325\343\311\303\301\343\311\326\325@\206\201\211\223\205\204
Data (EBCDIC): DRDA AR: AUTHENTICATION failed
Warum die gleichen Anmeldeinformationen hier ausfallen, während in dem .NET-Provider Erfolg ist mir schleierhaft. Gerade jetzt, was kann ich beobachten, ist ein deutlicher Unterschied zwischen den einzelnen Verfahren, wenn es um die Folge von Paketen übertragen kommt.
.NET DB2-Provider
No. Time Source Destination Protocol Info
1 0.000000 [client IP] [DB2 server IP] TCP kpop > 50000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=1
2 0.000399 [DB2 server IP] [client IP] TCP 50000 > kpop [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 WS=0
3 0.000414 [client IP] [DB2 server IP] TCP kpop > 50000 [ACK] Seq=1 Ack=1 Win=65536 [TCP CHECKSUM INCORRECT] Len=0
4 0.000532 [client IP] [DB2 server IP] DRDA EXCSAT | ACCSEC
5 0.038162 [DB2 server IP] [client IP] DRDA EXCSATRD | ACCSECRD
6 0.041829 [client IP] [DB2 server IP] DRDA ACCSEC | SECCHK | ACCRDB
7 0.083626 [DB2 server IP] [client IP] TCP 50000 > kpop [ACK] Seq=108 Ack=542 Win=65535 Len=0
8 0.190534 [DB2 server IP] [client IP] DRDA ACCSECRD | SECCHKRM | ACCRDBRM | SQLCARD
9 0.199776 [client IP] [DB2 server IP] DRDA PRPSQLSTT | SQLATTR | SQLSTT | OPNQRY
10 0.293307 [DB2 server IP] [client IP] TCP [TCP segment of a reassembled PDU]
11 0.293359 [DB2 server IP] [client IP] TCP [TCP segment of a reassembled PDU]
12 0.293377 [client IP] [DB2 server IP] TCP kpop > 50000 [ACK] Seq=870 Ack=1444 Win=64092 [TCP CHECKSUM INCORRECT] Len=0
13 0.293404 [DB2 server IP] [client IP] TCP [TCP segment of a reassembled PDU]
14 0.293452 [DB2 server IP] [client IP] TCP [TCP segment of a reassembled PDU]
15 0.293461 [client IP] [DB2 server IP] TCP kpop > 50000 [ACK] Seq=870 Ack=2516 Win=65536 [TCP CHECKSUM INCORRECT] Len=0
16 0.293855 [DB2 server IP] [client IP] TCP [TCP segment of a reassembled PDU]
17 0.293908 [DB2 server IP] [client IP] DRDA SQLDARD
18 0.293918 [client IP] [DB2 server IP] TCP kpop > 50000 [ACK] Seq=870 Ack=3588 Win=64464 [TCP CHECKSUM INCORRECT] Len=0
19 0.293957 [DB2 server IP] [client IP] DRDA QRYDSC
20 0.294008 [DB2 server IP] [client IP] DRDA QRYDTA
21 0.294017 [client IP] [DB2 server IP] TCP kpop > 50000 [ACK] Seq=870 Ack=4660 Win=65536 [TCP CHECKSUM INCORRECT] Len=0
22 0.294023 [DB2 server IP] [client IP] DRDA SQLCARD
23 0.295346 [client IP] [DB2 server IP] DRDA RDBCMM
24 0.297868 [DB2 server IP] [client IP] DRDA ENDUOWRM | SQLCARD
25 0.421392 [client IP] [DB2 server IP] DRDA PRPSQLSTT | SQLATTR | SQLSTT | OPNQRY
26 0.456504 [DB2 server IP] [client IP] DRDA SQLDARD | OPNQRYRM | TYPDEFNAM | QRYDSC | QRYDTA | ENDQRYRM | TYPDEFNAM | SQLCARD
27 0.456756 [client IP] [DB2 server IP] DRDA RDBCMM
28 0.488311 [DB2 server IP] [client IP] DRDA ENDUOWRM | SQLCARD
29 0.498806 [client IP] [DB2 server IP] DRDA PRPSQLSTT | SQLATTR | SQLSTT | OPNQRY
30 0.630477 [DB2 server IP] [client IP] TCP 50000 > kpop [ACK] Seq=5157 Ack=1579 Win=65171 Len=0
31 0.788165 [DB2 server IP] [client IP] DRDA SQLDARD | OPNQRYRM | TYPDEFNAM | QRYDSC | QRYDTA
32 0.788203 [DB2 server IP] [client IP] DRDA ENDQRYRM
33 0.788225 [client IP] [DB2 server IP] TCP kpop > 50000 [ACK] Seq=1579 Ack=5815 Win=64380 [TCP CHECKSUM INCORRECT] Len=0
34 0.788648 [client IP] [DB2 server IP] DRDA RDBCMM
35 0.795951 [DB2 server IP] [client IP] DRDA ENDUOWRM | SQLCARD
36 0.807365 [client IP] [DB2 server IP] DRDA PRPSQLSTT | SQLATTR | SQLSTT | OPNQRY
37 0.838046 [DB2 server IP] [client IP] DRDA SQLDARD | OPNQRYRM | TYPDEFNAM | QRYDSC | QRYDTA | ENDQRYRM | TYPDEFNAM | SQLCARD
38 0.838328 [client IP] [DB2 server IP] DRDA RDBCMM
39 0.841866 [DB2 server IP] [client IP] DRDA ENDUOWRM | SQLCARD
40 0.973506 [client IP] [DB2 server IP] TCP kpop > 50000 [ACK] Seq=1906 Ack=6304 Win=65482 [TCP CHECKSUM INCORRECT] Len=0
BizTalk DB2-Adapter
No. Time Source Destination Protocol Info
1 0.000000 [client IP] [DB2 server IP] TCP 28165 > 50000 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=8
2 0.002587 [DB2 server IP] [client IP] TCP 50000 > 28165 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 WS=0
3 0.010146 [client IP] [DB2 server IP] TCP 28165 > 50000 [ACK] Seq=1 Ack=1 Win=65536 Len=0
4 0.019698 [client IP] [DB2 server IP] DRDA EXCSAT
5 0.020849 [DB2 server IP] [client IP] DRDA EXCSATRD
6 0.034699 [client IP] [DB2 server IP] DRDA ACCSEC
7 0.036584 [DB2 server IP] [client IP] DRDA ACCSECRD
8 0.042031 [client IP] [DB2 server IP] DRDA SECCHK
9 0.046350 [DB2 server IP] [client IP] DRDA SECCHKRM
10 0.046642 [DB2 server IP] [client IP] TCP 50000 > 28165 [FIN, ACK] Seq=160 Ack=200 Win=65336 Len=0
11 0.053787 [client IP] [DB2 server IP] TCP 28165 > 50000 [ACK] Seq=200 Ack=161 Win=65536 Len=0
12 0.056891 [client IP] [DB2 server IP] DRDA ACCRDB
13 0.058084 [DB2 server IP] [client IP] TCP 50000 > 28165 [RST, ACK] Seq=161 Ack=295 Win=0 Len=0
Es ist interessant, das .NET-Provider Problem aus verschiedenen DRDA-Protokoll-Paketen innerhalb in einem einzigen TCP-Segment zu bezeugen. Der BizTalk Adapter auf der anderen Seite, legt nur ein Protokollpaket pro TCP-Segment. Ich weiß nicht, warum das so ist. Allerdings habe ich im Moment denken, dass ein roter Hering ist und der wahre Unterschied den Fehler bei der Authentifizierung verursacht, ist in der DRDA Datenaustausch. Ich weiß nicht, das DRDA-Protokoll, so dass es hat zu studieren, bevor ich mehr Sinn machen.
18. September 08:
In diesem Stadium wird das Problem noch nicht gelöst, da immer die Zusammenarbeit von dem DB2 DBA-Team und Hilfe von Microsoft wurde mit vielen Hindernissen begegnet.
Was ich will berichten ist, ich habe vielleicht einen entscheidenden Unterschied zwischen all den Fällen der erfolgreichen Verbindung im Vergleich zu dem gescheiterten Versuch beobachtet:
Der BizTalk DB2-Adapter ist mit zugrundeliegend Microsoft ODBC-Treiber für DB2 . Die anderen Software-Tests, die Verwendung von IBM DB2 ODBC-Treiber oder IBM DB2 ODBC-Treiber machen gelingen - IBMCL1 . Die Parameter IBMs Treiberkonfiguration unterscheidet sich von der Microsoft-Treiber. Aber wir sehen keinen offensichtlich kritischen Unterschied, dass für den Microsoft-Treiber zu einer fehlgeschlagenen Authentifizierung führen kann.
Lösung
Warum dauerte es sicherlich Microsoft lange genug, um diese explizit zu bestätigen:
Proxy-Verbindungen über DB2Connect wird nicht von BizTalk Adapter DB2 unterstützt
Da Politik unserer Kunden ist, um den Zugriff auf DB2-Datenbanken über DB2Connect der Adapter indiskutabel ist.
MEHR HINTERGRUND INFO
Der Grund, warum der DB2-Adapter funktioniert nur für eine direkte Verbindung zu einer z / OS-Mainframe-Host ist aufgrund gesetzlicher Beschränkungen. Technisch ist es möglich, eine Verbindung mit DB2Connect zu arbeiten, aber IBM hat es einen priorietary Knoten und verhinderte andere Parteien rechtlich zur Gründung der richtige DRDA- Sequenz um eine Verbindung herzustellen gemacht.
Andere Tipps
Ich habe noch nie diesen Adapter verwendet, aber mich selbst, so vermute ich, aber vielleicht ist es mit dem Konto zu tun, dass BizTalk nicht anschließen oder Ihre Ports korrekt konfiguriert wird.
Nach diese MSDN-Foren veröffentlichen , so scheint es, ein Login-Problem zu sein.
