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
