IBM Data Management magazine Issue 2, 2009

potential loss of data by specifying one of three synchronization modes:

Synchronous: } A database change made on the primary database won’t be committed until the associated log records have been written to the transaction log file on the standby DB2 instance.

Near synchronous: } Same as synchronous mode, except that the change made to the primary database can be committed when the associated log records have been written to memory on the standby DB2 instance (rather than written to the standby instance’s transaction log).

Asynchronous: } Committing a database change on the primary database is not held up in any way by the communication of log records to the standby database.

Connect to the standby database and start HADR on the standby server by executing the START HADR command.

. Connect to the primary database and start HADR on the primary server with the S TAR T HADR command.

You can also set up an HADR environment using the Set Up HADR Databases Wizard, which can be activated by selecting the High Availability Disaster Recovery action from the Databases menu found in the Control Center.

Configurations for Automatic Client Reroute and HADR Automatic Client Reroute is a DB2 feature that redirects client applications from the primary database to the standby database immediately after a failover operation is performed. If you set up HADR using the Set Up HADR Databases Wizard, Automatic Client Reroute is enabled by default. If you set up HADR manually, you can enable the Automatic Client Reroute feature by executing the UPDATE ALTERNATE SERVER FOR DATABASE command;

0 – 4,294,967,295
Default: 0 seconds
hadr_peer_
window
1 – 4,294,967,295
Default: 120 seconds
hadr_timeout
hadr_local_svc
hadr_local_host

Param

Table 1: HADR-specific database configuration parameters

eter Value range/default Description

hadr_db_role N/A Read-only; indicates the current role of the database, if it is
part of a HADR environment. Valid values are S TANDARD,
PRIMARY, or STANDBY.
Specifies the local host for HADR TCP communication; either a
host name or an IP address can be used.
Specifies the TCP service name or port number for which the
local HADR process accepts connections.
Specifies the TCP/IP host name or IP address of the remote
HADR node.
Specifies the instance name of the remote server. Administration
tools, such as the Control Center, use this parameter to contact
the remote server. HADR also checks whether a remote
database requesting a connection belongs to the declared
remote instance.
Specifies the TCP service name or port number that will be
used by the remote HADR node.
Specifies the synchronization mode to use for HADR. This
determines how primary log writes are synchronized with
the standby database when the systems are in peer state.
Valid values for this configuration parameter are S YNC
(Synchronous), NEARS YNC (Near Synchronous), AS YNC
(Asynchronous).
Specifies the time (in seconds) that the HADR process waits
before considering a communication attempt to have failed.
(The value assigned to this configuration parameter must be the
same for both the primary and the standby database.)
Specifies the time (in seconds) that a HADR primary-standby
database pair continues to behave as though still in peer state,
if the primary database loses connection with the standby
database. This helps ensure data consistency.

hadr_remote_ host hadr_remote_ inst

Any valid character string
Default: N ULL
Any valid character string
Default: N ULL
Any valid character string
Default: N ULL
Any valid character string
Default: N ULL

hadr_remote_ svc hadr_syncmode

Any valid character string
Default: N ULL
SYNC, NEARSYNC,
ASYNC
Default: NE ARS YNC

UPDATE ALTERNATE SE

Automatic Client Reroute does not use the values stored in the hadr_remote_host and hadr_remote_svc database configuration parameters. For example, if a database named SALES, located at SVR1, is the primary database in an HADR environment and its corresponding standby database (also named SALES) resides on host SVR2 and listens on port number 456, you could set up Automatic Client Reroute by executing a command that looks like this:

RVER FOR DATABASE sales

USING HOSTNAME svr2 PORT 456

Once this command is executed, clients connect to host SVR1 to obtain the alternate server information. If a communication error occurs between a client and the SALES database at host SVR1, the client will first attempt

to reconnect to the SALES database on host SVR1. If this fails, it will then attempt to establish a connection with the standby SALES database located on host SVR2.

A helping hand for disaster recovery HADR provides an excellent solution for minimizing the impact on a database environment when hardware, network, or software malfunctions or natural disasters occur. In addition to reducing data loss and downtime, HADR enables an organization to keep a disaster recovery (DR) copy of a database available and up-to-date, even when the DR site is hundreds of miles away. And if Automatic Client Reroute is used in conjunction with HADR, client applications can automatically be rerouted to the DR database copy or site in the event of a failover.