By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,007 Members | 1,237 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,007 IT Pros & Developers. It's quick & easy.

HADR primary connection failure tryin to communite to standby

P: n/a
Folks -

Linux RH3, UDB 8.2 FP9.

I've got two tiny test boxes that I'm setting up to get a simple HADR
configuration built. When I start the primary I get the famous SQL1768
RC=7 and also this on the db2diag.log.

This looks to me to be more than a simple firewall issue (which I've
checked).

Can somebody explain the concept of HADR seeds to me, please?

Regards,

Bruce Miller

2005-06-07-07.39.33.389552-300 I62062G470 LEVEL: Error
PID : 1094 TID : 3006257664 PROC : db2hadrp
(PSFTPROD) 0
INSTANCE: db2inst1 NODE : 000
FUNCTION: DB2 UDB, High Availability Disaster Recovery,
hdrVerifySystem, probe:15590
MESSAGE : The local HADR database seed 0xcbcadebc does not match the
remote database seed 0x6ad95c24.
DATA #1 : Hexdump, 4 bytes
0xBFFF88E4 : 4001 8087

Nov 12 '05 #1
Share this Question
Share on Google+
1 Reply


P: n/a
<<Miller's note: This was my response from IBM and I'm posting here it
for others. It sounds to me like the 'seed' is somewhat equivalent to
a mainframe DBID value.>>

IBM's Answer:

DB2 associates a unique number ("seed") with a database. It is used,
for example, to distinguish database "A" I create today from database
"A" I created yesterday. It's probably something like a sampled system
clock value; I couldn't verify the source quickly so am not certain
what it is.

In this case, it is one of the meta data that HADR validates when
forming a pair. Apparently the database on the standby has the same
name as the primary, but is not from the same instantiation/lifetime of
that database.

It sounds like you're saying the servers are the same. That's not the
issue. The databases don't smell the same to HADR. This is to prevent
an attempt to pair a standby that is not a true copy of the primary to
that primary. For example, if I create db A and restore it on standby,
then I drop db A on primary and recreate new db A on primary. Now the
databases have the same name (A) but different seeds as they are not
really the same database. This is the kind of condition we're prevent
with this check. Another way to get into this is by doing create db on
the standby instead of restore db.

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

Linux RH3, UDB 8.2 FP9.

I've got two tiny test boxes that I'm setting up to get a simple HADR
configuration built. When I start the primary I get the famous SQL1768
RC=7 and also this on the db2diag.log.

This looks to me to be more than a simple firewall issue (which I've
checked).

Can somebody explain the concept of HADR seeds to me, please?

Regards,

Bruce Miller

2005-06-07-07.39.33.389552-300 I62062G470 LEVEL: Error
PID : 1094 TID : 3006257664 PROC : db2hadrp
(PSFTPROD) 0
INSTANCE: db2inst1 NODE : 000
FUNCTION: DB2 UDB, High Availability Disaster Recovery,
hdrVerifySystem, probe:15590
MESSAGE : The local HADR database seed 0xcbcadebc does not match the
remote database seed 0x6ad95c24.
DATA #1 : Hexdump, 4 bytes
0xBFFF88E4 : 4001 8087


Nov 12 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.