0

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.

Improve this question
5
  • 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, 2015 at 21:04
  • WebSphere Application server , DB2 Client on other machine. Yes they can establish new connections.
    – Jenson
    Nov 18, 2015 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, 2015 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, 2015 at 21:29
  • In DB catalog; Protocol=TCPIP, Authentication=NOTSPEC
    – Jenson
    Nov 18, 2015 at 21:29

1 Answer 1

Reset to default
0

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.

Improve this answer
4
  • "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, 2015 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, 2015 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, 2015 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, 2015 at 17:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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