Hadr, Congestion, Recover-Pending

[bwmiller16]

Folks -

OpSys: RH Linux, AS3
DB: UDB 8.2.0 (FP7 Stinger)
HW: 2 X-series

We setup a HADR pair and they went into PEER state (after we backed-up
the DB on primary and restored the DB on the standby).
We created our tables and started importing thousands of rows into on
the primary-side.
We imported fine for a while and then the primary-side went into
Congested-state.
We looked at the Standby-side and we saw that the DB was:

** DB: p_xyz
**
** HADR database role = STANDBY
** Backup pending = NO
** Rollforward pending = DATABASE
** Restore pending = YES

Was the Standby-state put into Restore Pending state by some action on
the Primary-side because it was congested? I say that the reverse
might be true: that somehow we were able to get into HADR Standby and
the Restore-pending forced the Primary into congested state...

More Curious in Colorado, USA

Bruce and Dave

[Jean-Marc Blaise]

<bw********@yahoo.com> a écrit dans le message de
news:11*********************@o13g2000cwo.googlegro ups.com...

Folks -

OpSys: RH Linux, AS3
DB: UDB 8.2.0 (FP7 Stinger)
HW: 2 X-series

We setup a HADR pair and they went into PEER state (after we backed-up
the DB on primary and restored the DB on the standby).
We created our tables and started importing thousands of rows into on
the primary-side.
We imported fine for a while and then the primary-side went into
Congested-state.
We looked at the Standby-side and we saw that the DB was:

** DB: p_xyz
**
** HADR database role = STANDBY
** Backup pending = NO
** Rollforward pending = DATABASE
** Restore pending = YES

Was the Standby-state put into Restore Pending state by some action on
the Primary-side because it was congested? I say that the reverse
might be true: that somehow we were able to get into HADR Standby and
the Restore-pending forced the Primary into congested state...

More Curious in Colorado, USA

Bruce and Dave

Could it be linked to IY62632: log file can be removed before it is archived
after hadr takeover ? Would a missing log place the standby DB in Restore
pending state ?

Btw, this apar is very poorly described:

"Log file can be removed before it is archived and cause HADR failure during
takeover". I would like to know if it is AFTER or DURING, and if the
description can be somewhat enhanced. This is fixed in FP8.

HTH,

JM

[Serge Rielau]

bw********@yahoo.com wrote:

Folks -

OpSys: RH Linux, AS3
DB: UDB 8.2.0 (FP7 Stinger)
HW: 2 X-series

We setup a HADR pair and they went into PEER state (after we backed-up
the DB on primary and restored the DB on the standby).
We created our tables and started importing thousands of rows into on
the primary-side.
We imported fine for a while and then the primary-side went into
Congested-state.
We looked at the Standby-side and we saw that the DB was:

** DB: p_xyz
**
** HADR database role = STANDBY
** Backup pending = NO
** Rollforward pending = DATABASE
** Restore pending = YES

Was the Standby-state put into Restore Pending state by some action on
the Primary-side because it was congested? I say that the reverse
might be true: that somehow we were able to get into HADR Standby and
the Restore-pending forced the Primary into congested state...

More Curious in Colorado, USA

Bruce and Dave

Comments from backstage:
The standby states are correct. The standby db is put into permanent
rollforward, thus it shows rollfwd and restore pending. This is expected.

Congestion is usually caused by slow network or standby machine. Use
"db2 get snapshot for db on dbName" to check if the standby LSN is
moving. As long as it's moving, it may just be a slow standby/network.
If it is stuck at a position, then it's a different matter.
Cheers
Serge

--
Serge Rielau
DB2 SQL Compiler Development
IBM Toronto Lab