Replication of Vendor Package Database in UDB v6.1

[login to unmask email]

Replication of Vendor Package Database in UDB v6.1
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

Re: Replication of Vendor Package Database in UDB v6.1
(in response to BILL_GALLAGHER@PHL.COM)
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



Jim Tonchick

Re: Replication of Vendor Package Database in UDB v6.1
(in response to Jim Knisley)
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



Lynne Flatley

Re: Replication of Vendor Package Database in UDB v6.1
(in response to Jim Tonchick)
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]

Re: Replication of Vendor Package Database in UDB v6.1
(in response to Lynne Flatley)
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.





Jim Knisley <[login to unmask email]> on 99/12/29 07:42:43 AM

Please respond to DB2 Data Base Discussion List <[login to unmask email]>

To: [login to unmask email]
cc: (bcc: Rohn Solecki/MTSCommunications/MTS)
Subject: Re: Replication of Vendor Package Database in UDB v6.1




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]

Re: Replication of Vendor Package Database in UDB v6.1
(in response to Rohn.Solecki@MTS.MB.CA)
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.

Bill Gallagher, DBA
Phoenix Home Life
Enfield, CT





[login to unmask email] on 12/29/99 11:19:57 AM

Please respond to DB2 Data Base Discussion List <[login to unmask email]>


To: [login to unmask email]
cc: (bcc: BILL GALLAGHER/Phoenix Home Life Mutual Insurance)
bcc: BILL GALLAGHER/Phoenix Home Life Mutual Insurance
Subject: Re: Replication of Vendor Package Database in UDB v6.1



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.





Jim Knisley <[login to unmask email]> on 99/12/29 07:42:43 AM

Please respond to DB2 Data Base Discussion List <[login to unmask email]>

To: [login to unmask email]
cc: (bcc: Rohn Solecki/MTSCommunications/MTS)
Subject: Re: Replication of Vendor Package Database in UDB v6.1




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