Replication of Vendor Package Database in UDB v6.1

[login to unmask email]

Replication of Vendor Package Database in UDB v6.1

December 29, 1999 07:35 AM

We're being asked by our management if we can come up with a
potential solution
to the following scenario using replication:

We have a puchased application currently running at our site that
tracks
in-house problems and resolutions to those problems for our
help-desk. The help
desk is now looking to utilize our offshore resource to provide
second-shift
(their first-shift) support for the application. They can connect
to the
application running locally here in the US via our network, but
response time is
reportedly dreadfully slow. So as an alternative, they want to look
into the
possibility of maintaining two copies of the application (and the
underlying
database) via 2-way replication.

Our major concern, other than the fact that we have zero experience
with
replication in UDB, is the fact that the application (and database)
is a
purchased vendor package, and we would feel very cautious about
wanting to add
or change anything in the physical database schema that would be
needed to
enable replication.

Our environment is: UDB 6.1 running on AIX at our current (local)
site, UDB
running on NT at the offshore site. I'm not sure about what version
of UDB they
are running there. Details are very scarce right now, since this
was only
dropped on us yesterday afternoon, and management wants a proposed
solution by
early next week.

Does anybody have any experience with UDB replication with any
third-party
supplied database, any gotchas, warnings, etc.? Also, any issues
about
replication between possibly different release levels of UDB on
different
operating system platforms (i.e. AIX <--> NT)?

Thanks for any info,

Bill Gallagher, DBA
Phoenix Home Life
Enfield, CT

Jim Knisley

Bill,
You didn't say how current the replication on each end must be, but
Data
Propagator Relational (DPROPR) could easily handle the two-way
replication with
minimal changes to the database and well as manage the changes
across different
operating systems. It runs asynchronously with little impact to the
online
system. Depending upon the transaction volume, you could probably
set it up so
that the synchronization between the databases could be done every
15 minutes or
so. You can adjust that cycle to optimize performance and minimize
impact to
the online system. The Capture component captures changes from the
database
log, so no changes to the vendor supplied code is required. We have
been using
DPROPR for about three years on both OS/390 and Windows NT and it
has worked
very well.

<< We're being asked by our management if we can come up with
a potential
solution
to the following scenario using replication:

We have a purchased application currently running at our site that
tracks
in-house problems and resolutions to those problems for our
help-desk. The
help
desk is now looking to utilize our offshore resource to provide
second-shift
(their first-shift) support for the application. They can connect
to the
application running locally here in the US via our network, but
response
time is
reportedly dreadfully slow. So as an alternative, they want to look
into the
possibility of maintaining two copies of the application (and the
underlying
database) via 2-way replication.

Our major concern, other than the fact that we have zero experience
with
replication in UDB, is the fact that the application (and database)
is a
purchased vendor package, and we would feel very cautious about
wanting to
add
or change anything in the physical database schema that would be
needed to
enable replication.

Our environment is: UDB 6.1 running on AIX at our current (local)
site, UDB
running on NT at the offshore site. I'm not sure about what version
of UDB
they
are running there. Details are very scarce right now, since this
was only
dropped on us yesterday afternoon, and management wants a proposed
solution
by
early next week.

Does anybody have any experience with UDB replication with any
third-party
supplied database, any gotchas, warnings, etc.? Also, any issues
about
replication between possibly different release levels of UDB on
different
operating system platforms (i.e. AIX <--> NT)?
>>

Does management understand the cost to implement and manage a
replicated
database environment? If the only complaint is slow response time,
then
that's where the money and time should be spent, in the
network.

Fixing the slow response time is a one time expense and effort.
Replicating
the database is a constant effort and drain on resources. It will
cost more
in the long run. Besides, if the network is improved between the
two sites
then all applications will benefit not just the one
application.

These are just my personal humble opinions. Fix the true problem.
Don't try
to circumvent a problem with a more complex solution. K.I.S.S.

Jim Tonchick

Lynne Flatley

Amen! You have synchronization issues every time someone needs to
do a load
or recovery. You have additional cpu costs on both ends for the
replication
agent. It's an ugly road to go down (my humble opinion).

> -----Original Message-----
> From: [login to unmask email] [SMTP:[login to unmask email]
> Sent: Wednesday, December 29, 1999 11:07 AM
> To: [login to unmask email]
> Subject: Re: Replication of Vendor Package Database in UDB
v6.1
>
> In a message dated 12/29/1999 7:38:32 AM Central Standard
Time,
> [login to unmask email] writes:
>
> << We're being asked by our management if we can come up
with a potential
> solution
> to the following scenario using replication:
>
> We have a purchased application currently running at our site
that tracks
> in-house problems and resolutions to those problems for our
help-desk.
> The
> help
> desk is now looking to utilize our offshore resource to
provide
> second-shift
> (their first-shift) support for the application. They can
connect to the
> application running locally here in the US via our network,
but response
> time is
> reportedly dreadfully slow. So as an alternative, they want to
look into
> the
> possibility of maintaining two copies of the application (and
the
> underlying
> database) via 2-way replication.
>
> Our major concern, other than the fact that we have zero
experience with
> replication in UDB, is the fact that the application (and
database) is a
> purchased vendor package, and we would feel very cautious
about wanting
> to
> add
> or change anything in the physical database schema that would
be needed
> to
> enable replication.
>
> Our environment is: UDB 6.1 running on AIX at our current
(local) site,
> UDB
> running on NT at the offshore site. I'm not sure about what
version of
> UDB
> they
> are running there. Details are very scarce right now, since
this was
> only
> dropped on us yesterday afternoon, and management wants a
proposed
> solution
> by
> early next week.
>
> Does anybody have any experience with UDB replication with
any
> third-party
> supplied database, any gotchas, warnings, etc.? Also, any
issues about
> replication between possibly different release levels of UDB
on different
> operating system platforms (i.e. AIX <--> NT)?
> >>
>
> Does management understand the cost to implement and manage a
replicated
> database environment? If the only complaint is slow response
time, then
> that's where the money and time should be spent, in the
network.
>
> Fixing the slow response time is a one time expense and
effort.
> Replicating
> the database is a constant effort and drain on resources. It
will cost
> more
> in the long run. Besides, if the network is improved between
the two
> sites
> then all applications will benefit not just the one
application.
>
> These are just my personal humble opinions. Fix the true
problem. Don't
> try
> to circumvent a problem with a more complex solution.
K.I.S.S.
>
> Jim Tonchick
>
>
>
>
>

[login to unmask email]

I don't have an answer specifically to your question but here is
one for you to think a about ... "Software Piracy!" Does your
vendor allow you to run an unlicensed copy at a remote location.
I'm willing to bet they aren't. Ask them
about suggestions for data replication, I'm willing to bet they've
already had to answer that question from other sites.

Bill,
You didn't say how current the replication on each end must be, but
Data
Propagator Relational (DPROPR) could easily handle the two-way
replication with
minimal changes to the database and well as manage the changes
across different
operating systems. It runs asynchronously with little impact to the
online
system. Depending upon the transaction volume, you could probably
set it up so
that the synchronization between the databases could be done every
15 minutes or
so. You can adjust that cycle to optimize performance and minimize
impact to
the online system. The Capture component captures changes from the
database
log, so no changes to the vendor supplied code is required. We have
been using
DPROPR for about three years on both OS/390 and Windows NT and it
has worked
very well.

Jim Knisley
DBA

[login to unmask email]

We're well aware of the potential licensing issues with doing this,
and I'm sure
the appropriate people will address and resolve those issues with
the vendor as
part of the overall evaluation of whether or not this is an
appropriate approach
to solve this situation. I'm just looking at the purely technical
aspects of
how to do it from a DBA point-of-view, and any advice of what to
do/not do, what
to look out for, etc.

I don't have an answer specifically to your question but here is
one for you to
think a about ... "Software Piracy!" Does your vendor allow you to
run an
unlicensed copy at a remote location. I'm willing to bet they
aren't. Ask
them
about suggestions for data replication, I'm willing to bet they've
already had
to answer that question from other sites.

Bill,
You didn't say how current the replication on each end must be, but
Data
Propagator Relational (DPROPR) could easily handle the two-way
replication with
minimal changes to the database and well as manage the changes
across different
operating systems. It runs asynchronously with little impact to the
online
system. Depending upon the transaction volume, you could probably
set it up so
that the synchronization between the databases could be done every
15 minutes or
so. You can adjust that cycle to optimize performance and minimize
impact to
the online system. The Capture component captures changes from the
database
log, so no changes to the vendor supplied code is required. We have
been using
DPROPR for about three years on both OS/390 and Windows NT and it
has worked
very well.