Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion Groups
Database Servers
DB2InformixIngresMS SQLOraclePervasive.SQLPostgreSQLProgressSybase
Desktop Databases
FileMakerFoxProMS AccessParadox
General
General DB TopicsDatabase Theory
Related Topics
Java Development.NET DevelopmentVB DevelopmentMore Topics ...

Database Forum / DB2 Topics / April 2007

Tip: Looking for answers? Try searching our database.

HADR and Databases with default db container paths

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Pat - 15 Mar 2007 17:42 GMT
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!
Mark A - 15 Mar 2007 17:59 GMT
> Hi -
>
[quoted text clipped - 11 lines]
>
> 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.
Steve Pearson (news only) - 09 Apr 2007 19:56 GMT
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
Mark A - 09 Apr 2007 20:14 GMT
> Yes, HADR can be set up between two such databases.
>
[quoted text clipped - 20 lines]
> 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.
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.