DB2 HADR state for DB2 v9.1

[Laurence]

Hi folks,

Anyone knows what do these mean?

Primary log position(file, page, LSN) = S0000009.LOG, 0,
00000000036B0000
Standby log position(file, page, LSN) = S0000008.LOG, 357,
000000000342D073
Log gap running average(bytes) = 2633608

Is HADR state real peer when the HADR state is peer but the above
primary/standby log position are not the same? May I takeover the HADR
at that time, or shall wait the primary/standby log position are the
same?
Thanks in advance~

[Mark A]

Laurence wrote:

Hi folks,

Anyone knows what do these mean?

Primary log position(file, page, LSN) = S0000009.LOG, 0,
00000000036B0000
Standby log position(file, page, LSN) = S0000008.LOG, 357,
000000000342D073
Log gap running average(bytes) = 2633608

Is HADR state real peer when the HADR state is peer but the above
primary/standby log position are not the same? May I takeover the HADR
at that time, or shall wait the primary/standby log position are the
same?
Thanks in advance~

I always see this log mis-match when I do an online backup, and no
subsequent changes to the database have occured since the backup. I
include the logs with the backup, but I don't know if that is reason
for the mis-match. If you were to do an insert, update, or delete, I
think you would see them in synch right after that.

I have never tried to do a takeover in that state, but I assume it
would not be a problem.

[Steve Pearson (news only)]

Whenever DB2 "truncates" a log file, there may be a relatively large
apparent log gap shown for this HADR snapshot monitor element. This is
mentioned in HADR documentation, for example here:
http://publib.boulder.ibm.com/infoce...c/r0011478.htm

What happens is that DB2 effectively jumps over a range of unused LSNs
(log sequence numbers), which fools HADR into thinking the distance
between the primary and standby is greater than it really is. The
extra gap vanishes once the standby moves to the next log file; that
occurs once there is some operation on the primary subsequent to the
operation that cause the log file truncation. Online backup is a
typical "culprit"; the ARCHIVE LOG command also has this effect. The
artificial log gap may trigger a related health monitor alert as well.

We anticipate making some changes in a future release to help with log
gap accuracy in the presence of a truncated log file.

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

[Steve Pearson (news only)]

Anyone knows what do these mean?

See other posts.

Is HADR state real peer when the HADR state is peer but the above
primary/standby log position are not the same? May I takeover the HADR
at that time, or shall wait the primary/standby log position are the
same?

The difference in log position (LSN) and apparent log gap do not affect
the HADR state nor the HADR takeover semantics. If you are running in
SYNC or NEARSYNC mode, then the standby should be able to fail over
with no transaction loss assuming the usual fine print (e.g., in
NEARSYNC, the standby didn't also fail). If you are running in ASYNC
mode, it is possible that there is some real lag between the primary
and standby in addition to the artificial lag described in my other
post. More often someone performed an online backup while things were
otherwise idle on the primary, resulting in the primary log position
being the LSN of the start of log file N+1 while the standby log
position is the LSN of the end of log file N, in which case all log
records of file N already made it to the standby.

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