My ASP.net application uses ODBC(64 bit) to connect to DB2 Database(9.5.3). I am using 64 bit IBM DB2 Client 10.5. on Windows Server 2008 R2. Connection pool is turned on.

It works fine(immediate connectivity) for most of the time, but occasionally too much time is consumed to establish connectivity. By too much time I mean to say 10 to 11 minutes. No error is reported. No issue with database, as it can be accessed from other servers at same timestamp.

All database request issued during this time via DB2 Client are kept on hold and then once connectivity is established, all are executed immediately.

When the issue is going on, I tried to connect to database through Windows server CMD and that too waits for around 10 mins. No error is reported. Network team says they dont see network traffic from Windows server to Database server when issue is going on. And no errors from network side. Which means DB2 client is not making connectivity request.

What could be causing delay in connectivity? This is not a consistent issue. It automatically resolves after around 10 mins. Is there any issue with DB2 driver ? Was any resource withheld during that time? I am closing all connections properly.

  • What are those "other servers" that can access the database while your "Windows server" cannot? Can they establish new connections, or are they simply using previously established connections? Is your DB2 authentication set to "client" or "server"? – mustaccio Nov 18 '15 at 21:04
  • WebSphere Application server , DB2 Client on other machine. Yes they can establish new connections. – Jenson Nov 18 '15 at 21:10
  • Since you contrast your "Windows server" to those "other servers", should we assume they are not running Windows? and what about authentication? – mustaccio Nov 18 '15 at 21:16
  • other server is AIX, But I can also connect to database from DB2 Client on local machine , which is running Windows. – Jenson Nov 18 '15 at 21:29
  • In DB catalog; Protocol=TCPIP, Authentication=NOTSPEC – Jenson Nov 18 '15 at 21:29

I can't give you a definitive answer, but I would suspect slow authentication, both client and server being Windows-based: because of the client-server version mismatch there may be some extra authentication back-and-forth between them, and at some point either (or both) will traverse the Active Directory on the domain and possibly all trusted domains for user ID and group lookup.

Try setting the authentication method on the client to match that on the database server (SERVER would be the default), this might speed things up. For this you'll need to uncatalog and re-catalog the database in question.

Ask your sysadmins to check AD status if (when) you experience this issue again, may be there's a spike in load or some other issue.

  • "at some point either (or both) will traverse the Active Directory on the domain and possibly all trusted domains for user ID lookup" I suspect this is the issue. I will give it a try and let you know. Thanks – Jenson Nov 19 '15 at 14:43
  • serverfault.com/questions/53971/… This link also says to investigate in same direction. On my client: Server Connection Authentication (SRVCON_AUTH) = NOT_SPECIFIED Database manager authentication (AUTHENTICATION) = SERVER – Jenson Nov 20 '15 at 16:56
  • I am not getting what needs to be updated to prevent authentication against the Active Directory. Should I change the SRVCON_AUTH=NOT_SPECIFIED value to to SRVCON_AUTH=SERVER ? IBM www-01.ibm.com/support/knowledgecenter/SSEPGG_9.7.0/… says if SRVCON_AUTH=NOT_SPECIFIED then value of AUTHENTICATION, which is SERVER in this case is used. Sorry about my ignorance. – Jenson Nov 20 '15 at 16:57
  • You cannot prevent authentication against AD, but you can possibly shorten the cycle by avoiding authentication attempts on the client. Uncatalog the database on the client, then catalog it specifying authentication server. – mustaccio Nov 20 '15 at 17:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.