Automatic client reroute limitations

Consider DB2® database client reroute restrictions when designing your high availability DB2 database solution.

Here is a list of limitations of the DB2 database automatic client reroute feature:

• You cannot use the ACR feature if you enable reads on standby.
• ACR is only supported when the communications protocol used for connecting to the DB2 database server, or to the DB2 Connect™ Server, is TCP/IP. This means that if the connection is using a different protocol other than TCP/IP, the automatic client reroute feature will not be enabled. Even if the DB2 database is set up for a loopback, TCP/IP communications protocol must be used in order to accommodate the automatic client reroute feature.
• When using automatic reroute between the DB2 Connect clients or server products and a host or System i® database server, if you are in the following situations you will have the associated implications:
  • 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 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.
• If the connection is reestablished to the alternate server location, any new connection to the same database alias will be connected to the alternate server location. If you want any new connection to be established, to the original location in case the problem on the original location is fixed, there are a couple of options from which to choose:
  • You need to take the alternate server offline and allow the connections to fail back over to the original server. (This assumes that the original server has been cataloged using the UPDATE ALTERNATE SERVER command such that it is set to be the alternate location for the alternate server.)
  • You could catalog a new database alias to be used by the new connections.
  • You could uncatalog the database entry and re-catalog it again.
• DB2 for Linux, UNIX, and Windows supports the automatic client reroute feature for both the client and the server if both the client and server support this feature. Other DB2 database product families do not currently support this feature.
• The behavior of the automatic client reroute feature and the behavior of the automatic client rerouting in a DB2 for z/OS sysplex environment are somewhat different. Specifically:
  • The automatic client reroute feature requires the primary server to designate a single alternative server. This is done using the UPDATE ALTERNATE SERVER FOR DATABASE or UPDATE ALTERNATE SERVER FOR LDAP DATABASE command issued at the primary server. This command updates the local database directory with the alternate server information so that other applications at the same client have access this information. By contrast, a data-sharing sysplex used for DB2 for z/OS maintains, in memory, a list of one or more servers to which the client can connect. If a communication failure happens, the client uses that list of servers to determine the location of the appropriate alternative server.
  • In the case of the automatic client reroute feature, the server informs the client of the most current special register settings whenever a special register setting is changed. This allows the client, to the best of its ability, to reestablish the runtime environment after a reroute has occurred. By contrast, a Sysplex used for DB2 for z/OS returns the special register settings to the client on commit boundaries therefore any special registers changed within the unit of work that has been rerouted need to be replayed. All others will be replayed automatically.

  Full automatic client reroute support is available only between a Linux, UNIX, or Windows client and a Linux, UNIX, or Windows server. It is not available between a Linux, UNIX, or Windows client and a DB2 for z/OS Sysplex server (any supported version); only the reroute capability is supported.

• The DB2 database server installed in the alternate host server must be the same version (but could have a higher fix pack) when compared to the DB2 database instance installed on the original host server.
• Regardless of whether you have authority to update the database directory at the client machine, the alternate server information is always kept in memory. In other words, if you did not have authority to update the database directory (or because it is a read-only database directory), other applications will not be able to determine and use the alternate server, because the memory is not shared among applications.
• The same authentication is applied to all alternate locations. This means that the client will be unable to reestablish the database connection if the alternate location has a different authentication type than the original location.
• When there is a communication failure, all session resources such as global temporary tables, identity, sequences, cursors, server options (SET SERVER OPTION) for federated processing and special registers are all lost. The application is responsible to reestablish the session resources in order to continue processing the work. You do not have to run any of the special register statements after the connection is reestablished, because the DB2 database will replay the special register statements that were issued before the communication error. However, some of the special registers will not be replayed. They are:
  • SET ENCRYPTPW
  • SET EVENT MONITOR STATE
  • SET SESSION AUTHORIZATION
  • SET TRANSFORM GROUP

  When you have a problem with DB2 Connect, you should refer to the list of restricted special registers specific to the DB2 Connect product on a data server.

• If, after the connection is reestablished following a communication failure and the client is using CLI, JCC Type 2 or Type 4 drivers, then those SQL and XQuery statements that have been prepared against the original server are implicitly re-prepared with the new server. However, embedded SQL routines (for example, SQC or SQX applications), are not re-prepared with the new server.
• Do not run high availability disaster recovery (HADR) commands (START HADR, STOP HADR, or TAKEOVER HADR) on client reroute-enabled database aliases. HADR commands are implemented to identify the target database using database aliases. Consequently, if the target database has an alternative database defined, it is difficult for HADR commands to determine the database on which the command is actually operating. A client might need to connect using a client reroute-enabled alias, but HADR commands must be applied on a specific database. To accommodate this, you can define aliases specific to the primary and standby databases and only run HADR commands on those aliases.
• Because each database server can only have one alternate server defined, if you have a HADR multiple standby setup, you need to select one standby database (likely the principal standby) as the alternate server of the primary.

An alternate way to implement automatic client rerouting is to use the DNS entry to specify an alternate IP address for a DNS entry. The idea is to specify a second IP address (an alternate server location) in the DNS entry; the client would not know about an alternate server, but at connect time DB2 database system would alternate between the IP addresses for the DNS entry.