HADR - Disconnected-Peer

This depends on what your goal is.

* One common pattern is to repair the original primary (let's call it
A) and reingetrate it into the HADR in the standby role (where
original standby B became the primary via the TAKEOVER operation).
Since your takeover using PEER WINDOW ONLY option was successful, HADR
should be able to make the two copies of the database consistent again
as long as all the intervening log files are available.

Steps would be something like:
- repair/restart host A
- start DB2 instance at A (db2start)
- activate DB2 instance at A in standby role:
START HADR ON DB <dbalias> AS STANDBY

Monitor status of the HADR pair. Once standby A catches up to primary
B and enters Peer state, the pair is now again capable of perfoming
normal failover or a role switch. The latter could be performed if
desired to place the pair in its original configuration (with A as
primary). Use a TAKEOVER command *without* the BY FORCE option at A
to perform a role switch.

* If too much time passed since A failed and it appears A may not be
able to catch up to B timely (or at all, if some log files are not
available, e.g.), another option would be to reinitialize A as standby
to the new primary B by taking a new backup of B and restoring it at
A, then starting A as standby in the usual fashion.

* Another possibility is that A no longer plays with B. Perhaps some
new copy C is created as standby to B. In any case, if A is no longer
intended to play with B, but the existing database on A is going to be
activated for some reason, then issue a STOP HADR on A so that its
existing HADR configuration does not interfere with A's new role
(otherwise, A may refuse to activate without a connection to its
expected standby B, which would not be talking to A at this point).
Note that activation can be forced using START HADR .. AS PRIMARY BY
FORCE, but that would need to be done each time until HADR is stopped.

Regards,
- Steve P.
--
Steve Pearson, DB2 for Linux, UNIX, and Windows, IBM Software Group
"Portland" Development Team, IBM Beaverton Lab, Beaverton, OR, USA