HP Serviceguard Toolkits for Database Replication Solutions User Guide, March 2012

running on Node2. Similarly, ECMT DB2 Package2 is configured to run either on Node3 or on
Node4, and is currently running on Node3.
For primary and standby packages, the package dependency and package priority must be
configured in such a way that if any of the packages fail, all the packages must failover to the
alternate node. While you set up the package for failover, you must set the dependency and priority
attributes for the package. The priority of the ECMT DB2 package must be lower than the HADR
packages, so that if one package fails, all the packages configured for that instance are also
moved to the alternate node.
NOTE: Failover takes place at the instance level and not at the database level.
The primary database package manages the primary database and the primary HADR. Similarly,
the standby database package manages the standby database and the standby HADR. Also, if
the primary database fails or if the node hosting the primary database crashes, the standby package
automatically takes over the role of the primary database. A role switch operation can be configured
for the primary and standby packages to restore the original role of the databases. It is performed
as soon as the failed database comes back online and the status becomes “peer”.
In this scenario, the DB2 HADR toolkit supports the following events:
NOTE: Packages in Event 1–4 are initially in the “Online” state.
Event 1: Standby HADR package fails
If Standby Package1 fails, Standby Package2 and ECMT DB2 Package2 are halted on Node3
and all the three packages are moved to Node4. Similarly, if Standby Package2 fails, Standby
Package1 and ECMT DB2 Package2 are halted on Node3 and all the three packages are moved
to the Node4. If Node3 fails, it leads to a failover of all the packages configured on that node to
its alternate node, Node4. In this case, the standby package logs a failure message in the package
log and sends an email. The primary HADR package logs a warning message, standby disconnected
and sends an email.
Event 2: Primary HADR package fails
If Primary Package1 fails, Primary Package2 and ECMT DB2 Package1 are halted on Node2 and
all the three packages are moved to Node1. Similarly, if Primary Package2 fails, Primary Package1
and ECMT DB2 Package1 are halted on Node2 and all the three packages are moved to Node1.
In case Node2 fails, it leads to a failover of all the packages configured on that node to its alternate
node, Node1. In this case, the standby package logs a failure message in the package log and
sends an email. The primary HADR package logs a warning message, standby disconnected and
sends an email.
Event 3: ECMT DB2 package fails
When ECMT DB2 Package1 fails, both the primary HADR packages configured on Node1 also
fails because the primary packages are dependent on the ECMT DB2 Package1. All the failed
packages log a failure message in the package log and sends an email. All the dependent HADR
packages and ECMT DB2 Package1 fails over to the alternate node and their respective standby
packages perform role takeover. The standby HADR packages log a message and sends an email
to inform that the role takeover is performed.
Similarly, when ECMT DB2 Package2 fails, both the standby HADR packages configured on Node2
also fails because the standby packages are dependent on this ECMT DB2 package. All the failed
packages log a failure message in the package log and then send an email. All the dependent
HADR packages and ECMT DB2 Package2 configured on this node fails over to the alternate
node.
NOTE: To halt the ECMT DB2 package manually, you must manually halt all the HADR packages
that are dependent on the ECMT DB2 package.
Event 4: The node hosting the primary database crashes
Using the DB2 HADR toolkit 43