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

On Node2, if the HADR configured for standby database, Sample1, is down, the Standby Package1
fails. Similarly, if the HADR configured for standby database, Sample2, is down, the Standby
Package2 fails. In either of these cases, failure of one package does not impact other packages
configured for the same instance. In this case, the standby package logs a failure message in the
package log and sends an email if the ALERT_MAIL_ID package attribute is set.
The primary HADR package continues to run. Standby is not connected to the primary database,
so the primary HADR package logs a warning message, standby disconnected and sends an email.
When the Standby comes online, the primary HADR re-establishes the connection, and the primary
package logs another message to the package log about the re-established connection.
If the standby package is halted manually, the primary package logs a warning message, standby
disconnected and sends an email.
Event 2: Primary HADR package fails
On Node1, if the HADR configured for primary database, Sample1, is down, the Primary Package1
fails. Similarly, if the HADR configured for primary database, Sample2 is down, the Primary
Package2 fails. Failure of one package does not impact other packages configured for the same
instance. In this event, the failed primary package logs a failure message in the package log and
sends an email.
The standby HADR package continues to run. Primary is not connected to the standby database,
so the standby HADR package performs a role takeover and logs a warning message, primary
disconnected and sends an email. When the Standby comes online, the primary HADR re-establishes
the connection, and the primary package logs another message to the package log about the
re-established connection.
If the primary package is halted manually, the standby package logs a warning message, primary
disconnected and sends an email if ALERT_MAIL_ID package attribute is set.
Event 3: ECMT DB2 package fails
When ECMT DB2 package configured on Node1 fails, both of the primary HADR packages also
fail because the primary packages are dependent on this ECMT DB2 package. The ECMT DB2
package and all its dependent packages log a failure message in their respective package logs
and then sends an email. All the corresponding standby HADR packages perform the role takeover
and sends an email to inform that the role takeover is performed.
Similarly, when ECMT DB2 package configured on Node2 fails, both the standby HADR packages
also fail because the standby packages are dependent on this ECMT DB2 package. The ECMT
DB2 package and all the dependent packages log a failure message in the package log and sends
an email.
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
If Node1 crashes when it is in the online state, the standby HADR package uses the by force
option to perform a role takeover, and thus becomes the new primary database. All database
clients reconnect to this database using the Automatic Client Reroute feature of DB2 HADR. Standby
package logs the result of success or failure of the role takeover process in the package log and
then sends an email.
Event 5: Primary package is manually halted
If the Primary Package1 is halted using the cmhaltpkg command, the corresponding Standby
Package1 does not perform a role takeover. It continues to stay up and logs a message in the
package log stating that the primary package is manually halted. There is no impact on the Primary
Package2, standby packages and ECMT DB2 Package2 when the Primary Package1 is halted
manually.
Event 6: The failed primary package restarts on the primary node
Using the DB2 HADR toolkit 41