DB2 Version 9.7 for Linux, UNIX, and Windows

Automatic client reroute description and setup

The main goal of the automatic client reroute feature is to enable an IBM® Data Server Client application to recover from a loss of communications so that the application can continue its work with minimal interruption. As the name suggests, rerouting is central to the support of continuous operations. But rerouting is only possible when there is an alternate location that is identified to the client connection.

The automatic client reroute feature could be used within the following configurable environments if the server is DB2® for Linux, UNIX, and Windows:

DB2 Enterprise Server Edition (ESE) with the partitioned database environment
InfoSphere® Replication Server
IBM PowerHA® SystemMirror for AIX®
High availability disaster recovery (HADR).
Automatic client reroute works in conjunction with HADR to allow a client application to continue its work with minimal interruption after a failover of the database being accessed.

The seamless automatic client reroute feature is required in the following configuration if the database server is on System i® or System z®:

IBM Data Server Client connects to a z/OS® or i5/OS™ system through a DB2 Connect™ server which has an alternate server. The automatic client reroute is used between the IBM Data Server Client and two DB2 Connect servers.
DB2 Connect client or server products accessing a DB2 for z/OS Parallel Sysplex® data sharing environment. Automatic client reroute is used between DB2 Connect and the z/OS Sysplex system. The automatic client reroute feature supports seamless failover between a DB2 Connect-licensed client and the Sysplex. For more information about seamless failover, see the topic about automatic client reroute (client-side) in the DB2 Information Center.

In the case of the DB2 Connect server and its alternate, because there is no requirement for the synchronization of local databases, you only need to ensure that both the original and alternate DB2 Connect servers have the target host or System i database catalogued in such a way that it is accessible using an identical database alias.

In order for the DB2 database system to have the ability to recover from a loss of communications, an alternative server location must be specified before the loss of communication occurs. The UPDATE ALTERNATE SERVER FOR DATABASE command is used to define the alternate server location on a particular database.

After you have specified the alternate server location on a particular database at the server instance, the alternate server location information is returned to the IBM Data Server Client as part of the connection process. In the case of using automatic client reroute between DB2 Connect client or server products and a host or System i database server, the remote server must provide one or more alternate addresses for itself. In the case of DB2 for z/OS, multiple addresses are known if the database is a Parallel Sysplex data sharing environment, therefore an alternate server does not need to be cataloged on DB2 Connect. If communication between the client and the server is lost for any reason, the IBM Data Server Client will attempt to reestablish the connection by using the alternate server information. The IBM Data Server Client will attempt to reconnect with a database server which could be the original server, and alternate server listed in the database directory file at the server, or an alternate server that is in the server list returned by the z/OS Parallel Sysplex system. The timing of these attempts to reestablish a connection varies from very rapid attempts initially to a gradual lengthening of the intervals between the attempts.

After a connection is successful, SQL30108N is returned to indicate that a database connection has been reestablished following the communication failure. The hostname or IP address and service name or port number are returned. TheIBM Data Server Client only returns the error for the original communications failure to the application if the reestablishment of the client communications is not possible to either the original or alternative server.

Note the following considerations involving alternate server connectivity in a DB2 Connect server environment:

When using a DB2 Connect server for providing access to a host or System i database on behalf of both remote and local clients, confusion can arise regarding alternate server connectivity information in a system database directory entry. To minimize this confusion, consider cataloging two entries in the system database directory to represent the same host or System i database. Catalog one entry for remote clients and catalog another for local clients.
Any Parallel Sysplex information that is returned from a target DB2 for z/OS server is kept only in cache at the DB2 Connect server. Only one alternate server is written to disk. When multiple alternates or multiple active servers exist, the information is only maintained in memory and is lost when the process terminates.

In general, if an alternate server is specified, automatic client reroute will be enabled when a communication error is detected. However, in a high availability disaster recovery (HADR) environment, it will also be enabled if SQL1776N is returned back from the HADR standby server.