By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,496 Members | 1,489 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,496 IT Pros & Developers. It's quick & easy.

Connection hang with HADR takeover by force and old primary server is down

P: n/a
DB2 ESE 8.2.3 (FP10) for Linux

We are experiencing a connection hang of 10 - 15 minutes in the following
HADR and automatic client reroute scenario:

01 server is primary database
02 server is standby database

a. applications connected to database on 01 server
b. shutdown 01 server
c. run takeover db by force on 02 server (force is necessary because
databases are no longer in peer state)
d. a user logged on directly to the 02 server can connect to new primary
database without delay as soon as takeover completed
e. for remote clients it takes about 10-15 minutes to get any response back
(wait time varies each time, and even varies somewhat by app tier blade).
f. after 10-15 minute delay, automatic client reroute on remote clients
reconnects to alternate server 02 after SQL retry.

However, if the following scenario occurs, there is no delay:

a. applications connected to database on 01 server
b. db2 instance stopped with force on 01 server (but 01 server is still up
and can be pinged)
c. run HADR takeover db by force on 02 server (not in peer state)
d. after only a 5-10 second delay, automatic client reroute reconnects to
alternate server 02 after SQL retry

Both of the above scenarios exhibit the same symptoms (delays) with either
the type 2 driver (SQL commands submitted from remote client via CLI) or a
type 4 client (Websphere 6).

Does anyone know why the connections to the 01 server are hung for 10-15
minutes after an HADR takeover by force on 02, only if the 01 server is
completely down, but there is no delay.if the server 01 is still reachable
(but instance is down).

We tried setting the db2 type 2 client's registry to have
db2tcp_client_rcvtimeout=15 (15 seconds). The registry value seems to have
helped the waiting issue (connection released after about 1 minute) but it
also seems to have severed the connection (that is no automatic client
reroute retry). The following error message was received:

SQL30081N A communication error has been detected. Communication protocol
being used: "TCP/IP". Communication API being used: "SOCKETS". Location
where the error was detected: "10.34.9.139". Communication function
detecting the error: RecvTimeout". Protocol specific error code(s): "4",
"*", "*". SQLSTATE=08001

Then after retry:
Communication function detecting the error: "selectForRecvTimeout".
Protocol specific error code(s): "4", "*", "*". SQLSTATE=08001
Feb 2 '06 #1
Share this Question
Share on Google+
1 Reply


P: n/a

You might want to look at your TCP keepalive (system configuration).
We have seen cases where Automatic Client Reroute suffers a response
delay due to the fact that it does not learn of the connection failure
in a timely fashion. This shows up where the socket is broken in the
comms layer (such as when the server host is shut down) but doesn't
show up where the database server connection has an explicit error
returned from DB2; those symptoms seem highly correlated to what you
report.

Regards,
-Steve P.
----------------------------
Steve Pearson
IBM DB2 UDB for LUW Development
Portland, OR, USA

Feb 3 '06 #2

This discussion thread is closed

Replies have been disabled for this discussion.