HADR incompatibility between the two databases

[m0002a]

I have sucessfully set up an HADR pair of databases. Everthing works
fine for the primary and secondary HADR databases, and manual takeover
works fine.

When I try to set up the second pair of databases for HADR in the same
instance, I get the following error message (I already sucessfully
started the standby database):

$ db2 start hadr on db tdsapp as primary
SQL1768N Unable to start HADR. Reason code = "99".

In the Messages and Codes manual, Reason code 99 says:

"The primary and standby databases are able to connect via TCP/IP, but
the connection had to be closed due to an incompatibility between the
two databases. Refer to the Administration Notification log for details
of the incompatibility."

I cannot find the "Administration Notification log" but here is the
contents of the db2diag.log:

2005-11-02-17.18.52.343701+000 I1041212G318 LEVEL: Warning
PID : 13542 TID : 4063074816 PROC : db2hadrp
(TDSAPP) 0
INSTANCE: db2inst8 NODE : 000 DB : TDSAPP
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrEduP,
probe:20301
MESSAGE : Info: Primary Started.

2005-11-02-17.18.52.343997+000 E1041531G432 LEVEL: Error (OS)
PID : 13542 TID : 4063074816 PROC : db2hadrp
(TDSAPP) 0
INSTANCE: db2inst8 NODE : 000 DB : TDSAPP
FUNCTION: DB2 UDB, oper system services, sqloPdbBindSocket, probe:20
MESSAGE : ZRC=0x810F001B=-2129723365=SQLO_ADDR_IN_USE "Address already
in use"
CALLED : OS, -, bind OSERR: EADDRINUSE
(98)

Is there a problem in setting up 2 HADR databases in the same instance?
Any other things I should check for?

[m0002a]

Does each database on a server that is configured for HADR need its own
hadr_local_svc port in /etc/services? Or can all databases on the same
server share the port?

I am not talking about the port for the instance, but for the HADR
service (hadr_local_svc).

[m0002a]

I tried setting up separate ports for the hadr_local_svc for each
database on the same machine that participates in HADR, and it worked.

So each DB2 database that uses HADR on a given physical server needs
its own hadr_local_svc port in /etc/services.

[Steve Pearson (news only)]

Yes, that's correct. Unfortunately, that information is not yet in the
main HADR documentation topics.
A documentation update exists, with the following statement:

Value restrictions for the HADR local host and local service
parameters

When specifying values for the high availability disaster recovery
(HADR) local host and local service parameters
(HADR_LOCAL_SVC and HADR_REMOTE_SVC) while preparing
an update database configuration command, the values must be
ports that are not in use for any other service. If the parameters
are being configured using the UNIX or Linux command line,
the values should be also set in the /etc/services file.

(ref:
http://publib.boulder.ibm.com/infoce...e/r0012049.htm)

Regards,
-Steve P.
------------------------------------------
Steve Pearson
DB2 UDB for LUW Development
Portland, OR, USA

[Mark A]

"Steve Pearson (news only)" <st*******@my-deja.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...

Yes, that's correct. Unfortunately, that information is not yet in the
main HADR documentation topics.
A documentation update exists, with the following statement:

Value restrictions for the HADR local host and local service
parameters

When specifying values for the high availability disaster recovery
(HADR) local host and local service parameters
(HADR_LOCAL_SVC and HADR_REMOTE_SVC) while preparing
an update database configuration command, the values must be
ports that are not in use for any other service. If the parameters
are being configured using the UNIX or Linux command line,
the values should be also set in the /etc/services file.

(ref:
http://publib.boulder.ibm.com/infoce...e/r0012049.htm)

Regards,
-Steve P.
------------------------------------------
Steve Pearson
DB2 UDB for LUW Development
Portland, OR, USA

The updated doc still does not seem quite clear to me. I think you need to
explicitly state that each database must have its own port for
HADR_LOCAL_SVC. So if you have two databases defined for HADR on a given
server, they each must have their own port.

[Steve Pearson (news only)]

Here's a sneak peek at the text used in the next major docs revision,
i.e., where the document update referred to above will be taken up into
the main docs topics.

When you specify values for the high availability disaster recovery
(HADR) local service and remote service parameters
(HADR_LOCAL_SVC and HADR_REMOTE_SVC) while preparing
an update database configuration command, the values you specify
must be ports that are not in use for any other service, including
other DB2 components or other HADR databases. In particular,
you cannot set either parameter value to the TCP/IP port used by
the server to await communications from remote clients (the
SVCENAME database manager configuration parameter) or the next
port (SVCENAME + 1).

Let me know if this is still unclear, in which case I will open a
follow-up defect report to ensure that it is revisited by the
information development folks.

Thanks.

Regards,
-Steve P.
------------------------------------------
Steve Pearson
DB2 UDB for LUW Development
Portland, OR, USA

[Mark A]

"Steve Pearson (news only)" <st*******@my-deja.com> wrote in message
news:11*********************@g44g2000cwa.googlegro ups.com...

Here's a sneak peek at the text used in the next major docs revision,
i.e., where the document update referred to above will be taken up into
the main docs topics.

When you specify values for the high availability disaster recovery
(HADR) local service and remote service parameters
(HADR_LOCAL_SVC and HADR_REMOTE_SVC) while preparing
an update database configuration command, the values you specify
must be ports that are not in use for any other service, including
other DB2 components or other HADR databases. In particular,
you cannot set either parameter value to the TCP/IP port used by
the server to await communications from remote clients (the
SVCENAME database manager configuration parameter) or the next
port (SVCENAME + 1).

Let me know if this is still unclear, in which case I will open a
follow-up defect report to ensure that it is revisited by the
information development folks.

Thanks.

Regards,
-Steve P.
------------------------------------------
Steve Pearson
DB2 UDB for LUW Development
Portland, OR, USA

I think the reference to "or other HADR databases" is more clearly spelled
out and is satisfactory.