HADR primary to standby

paul

Hi,
I have two databases in hadr, this morning i issued a "takeover ... by
force" because the normal takeover didn't worked. Now i have two standard
databases, and if i try to put the old primary database in standby mode i
can't but it's not in rollforward pending state.
How can i put this database in rollffoward pending state without
backup/restore from the new primary dabatase ?

Thanks
Paul

Sign this for them
http://www.mobilize-humanity.org/

Aug 22 '07 #1

Steve Pearson (news only)

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

Aug 24 '07 #2

paul

Hi Steve,
thanks for your advices but it didn't worked
I had to restore a backup.
In fact the two databases diverged during the incident.
And effectively i issued a stop hadr command on two databases because i
could not connect to them before this.

Regards


"Steve Pearson (news only)" <st*******@my-deja.coma écrit dans le message
de news: 11**********************@l22g2000prc.googlegroups. com...

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

Aug 28 '07 #3