Hi, Paul.

There must've been one or more other steps taken to arrive at two
"standard" databases from an HADR pair.  The "TAKEOVER .. BY FORCE"
command should leave you with both dbs in "primary" role.  To get to
"standard" would require something more drastic, such as "STOP HADR"
or some kind of restore-like activity that replaced the on disk
database with something else.

Putting your two dbs back together from the current state may be
difficult w/o resorting to reinitializing the intended new standby
from a new backup of the new primary.

You could try the following sequence to see if it may work.  Let's
call the intended new standby (presumably, old primary) as "A", and
intended new primary (presumably, original standby) as "B".

- isolate A from any potential clients
    (to avoid any transactions being performed after next step)

- issue "start hadr .. as primary by force" on A
    (make A change role from standard to primary)

- deactivate db on A

- issue "start hadr .. as standby" on A
    (now make A change role from primary to standby)

- issue "start hadr .. as primary" on B
    (make B change role from standard to primary)

If the two databases did not diverge during the prior incident, it is
possible that A will successfully reintegrate into the pair as new
standby.  Check the status of A (e.g., via "get snapshot for db")
after B starts up to see if reconnection and reintegration was
successful.  Note that the "start hadr" commands themselves will
generally report success either way as they are limited to "launching"
type activity; only after the two start dbs talking to each other can
they tell if they are able to reform the pair or not.  Status and
db2diag.log messaging can be examined to learn the outcome.

Hope it works for you.

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