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

HADR and Databases with default db container paths

P: n/a
Pat
Hi -

We're trying to set up an HADR pair on two databases on instances with
different names on separate servers. The databases were defined as
follows:

CREATE DATABASE database1 ON '/db2home/instanceA';

CREATE DATABASE database2 ON '/db2home/instanceB';

Are the resulting container paths for USERSPACE1 considered relative?

Can HADR be set up between the two?

Thanks in advance!

Mar 15 '07 #1
Share this Question
Share on Google+
3 Replies


P: n/a
"Pat" <pa********@yahoo.comwrote in message
news:11*********************@y80g2000hsf.googlegro ups.com...
Hi -

We're trying to set up an HADR pair on two databases on instances with
different names on separate servers. The databases were defined as
follows:

CREATE DATABASE database1 ON '/db2home/instanceA';

CREATE DATABASE database2 ON '/db2home/instanceB';

Are the resulting container paths for USERSPACE1 considered relative?

Can HADR be set up between the two?

Thanks in advance!
I can't tell you that you will definitely have a problem (depending on what
statements/commands you submit that are attempted to be replicated), but all
paths should be the same on both primary and standby server. Otherwise, you
are asking for big trouble.
Mar 15 '07 #2

P: n/a
Yes, HADR can be set up between two such databases.

For simplicity, we recommend that the two sides of an HADR pair be set
up as identically as possible. However, the actual restrictions are
somewhat looser than that. Certainly you can have different users/
instance names, host names, and db paths.

HADR does require that tablespace container path names match (i.e.,
that the container path used on the primary also exists on the
standby). This is not explicitly verified by HADR, but replication
will fail if the necessary path is not found during an attempt to
replay a container operation on the standby.

If you use relative container paths, i.e., default container paths or
explicit relative container path names (path *not* starting with "/"
on UNIX/Linux nor with a drive letter on Windows), the full container
path includes the db path as a prefix, and that part need not be the
same on primary and standby. What needs to exist on both sides is any
part of the path name supplied by the user during container creation,
either the relative path that will follow the db path, or the full
explicit path name (if starting with "/" or a drive letter).

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

Apr 9 '07 #3

P: n/a
"Steve Pearson (news only)" <st*******@my-deja.comwrote in message
news:11**********************@e65g2000hsc.googlegr oups.com...
Yes, HADR can be set up between two such databases.

For simplicity, we recommend that the two sides of an HADR pair be set
up as identically as possible. However, the actual restrictions are
somewhat looser than that. Certainly you can have different users/
instance names, host names, and db paths.

HADR does require that tablespace container path names match (i.e.,
that the container path used on the primary also exists on the
standby). This is not explicitly verified by HADR, but replication
will fail if the necessary path is not found during an attempt to
replay a container operation on the standby.

If you use relative container paths, i.e., default container paths or
explicit relative container path names (path *not* starting with "/"
on UNIX/Linux nor with a drive letter on Windows), the full container
path includes the db path as a prefix, and that part need not be the
same on primary and standby. What needs to exist on both sides is any
part of the path name supplied by the user during container creation,
either the relative path that will follow the db path, or the full
explicit path name (if starting with "/" or a drive letter).

Regards,
- Steve P.
There is a problem with using different instance names in a HADR pair. If
you have a C UDF (supplied by IBM) that is invoked by an SQL Stored
Procedure, then DB2 will not find the UDF on the standby database because
the library for such functions will be in a different path name (in the
instance path). Strangely enough, I the UDF was executed outside of the SP
(in a regular SQL statement), there is no problem (maybe it only affects
statically bound statements).

There may also be some other similar combinations of UDF's or SP's that
might cause a problem, especially if any of them are using static SQL.

I opened an PMR on this about a year ago, but I solved it myself by copying
over the DB2 library with the C code to a directory on the standby with the
instance name of the primary. Of course, this is only a stop gap measure,
and makes upgrading FP's a problem.

The initial version of the HA scripts for TSA supplied with DB2 required
that instance names be different for an HADR pair, but I believe that is not
the case anymore if you have TSA 2.1 and the latest 8.1 FP (or 9.1). Of
course, if you don't use TSA, then it never was a problem to make the
instances the same.
Apr 9 '07 #4

This discussion thread is closed

Replies have been disabled for this discussion.