472,119 Members | 2,085 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 472,119 software developers and data experts.

SQL Replication Migration from V8 to V9

Hi,

Our SQL Replication is between DB2 databases on Windows servers.
I'm searching for the document which tells me how to migrate our SQL
Replication environment from V8 to V9 (we also need to migrate from V7
to V8 but that's fully described so that's no problem).
The PDF 'Migrating to Replication Version 9' doesn't contain a
description about migrating SQL Replication, only Q replication. I found
some links to PDF manuals which should contain the needed information
but I couldn't find them.

TIA, Gert
Nov 28 '06 #1
3 4390
Hi Gert,
You got me thinking there, as I'm considering this myself. Hunting and
reading, I found this in the online doco. It appears dataPropagator is
now called Websphere Replication Server. Most of the page relates to Q
replication, but does have a bit on SQL.

Page: Migrating to replication and event publishing Version 9
SubHeading: Migrating to SQL replication Version 9

The SQL replication control tables for Version 9 are identical to the
SQL replication control tables for Version 8. Because of this, you do
not need to migrate the control tables after you install WebSphere
Replication Server for z/OS Version 9.1 or WebSphere Replication Server
Version 9.1.
....
If you are upgrading to Version 9 replication from DataJoiner® Version 2
or DB2 Universal Database for Linux, UNIX, and Windows Version 7, you
need only to migrate your replication environment to Version 8 to begin
using the Version 9 replication programs....

Version 8 and Version 9 SQL replication are completely compatible. You
can use either the Version 8 or Version 9 ASNCLP command-line program or
Replication Center to work with your Capture and Apply programs. The
Version 8 Capture program works with the Version 9 Apply program without
restriction. The Version 9 Capture program works with the Version 8
Apply program without restriction.
---------------------

That makes me happy, as our iSeries is usually a year or two behind our
Windows DB2 and replication versions.
I did see a note about archiving all logs used by dpr capture before
upgrading to v9, though I expect that's mostly about recoverability &
continuity of replication without doing a full refresh.

regards
Greg

Gert van der Kooij wrote:
Hi,

Our SQL Replication is between DB2 databases on Windows servers.
I'm searching for the document which tells me how to migrate our SQL
Replication environment from V8 to V9 (we also need to migrate from V7
to V8 but that's fully described so that's no problem).
The PDF 'Migrating to Replication Version 9' doesn't contain a
description about migrating SQL Replication, only Q replication. I found
some links to PDF manuals which should contain the needed information
but I couldn't find them.

TIA, Gert
Nov 28 '06 #2
In article <tO*******************@news-server.bigpond.net.au>,
gn***@namoicotton.com.au says...
Thanks, Greg
Nov 28 '06 #3
Having said that, I now have a problem since upgrading..
One of my replica sets is generating SQL-803 errors on ASN.IBMSNAP_SIGNAL
-803 is violation of a constraint. The only constraint on
IBMSNAP_SIGNAL is a unique index on the SIGNAL_TIME column, which is of
type TIMESTAMP and WITH DEFAULT CURRENT TIMESTAMP.

The general v9 upgrade notes say
"In DB2(R) Version 9, the value returned from the CURRENT TIMESTAMP
special register might not be unique, even for requests from the same
application on a single database partition. There has never been a
documented guarantee that requests return unique CURRENT TIMESTAMP
values and changes in DB2 Version 9 increase the possibility that two
requests might return the same value. This change in behavior will not
impact an application unless the application uses the CURRENT TIMESTAMP
special register value with an expectation that two requests would never
return the same value."

Can't change it to use TIMESTAMP(GENERATE_UNIQUE()) as that's not a
valid DEFAULT clause. I'm thinking of trying an insert trigger. I've
also pondered removing the constraint, but guessing it's probably unique
for a reason..
Has anyone had to deal with this?

Greg Nash wrote:
>

Page: Migrating to replication and event publishing Version 9
SubHeading: Migrating to SQL replication Version 9

The SQL replication control tables for Version 9 are identical to the
SQL replication control tables for Version 8.
...
Version 8 and Version 9 SQL replication are completely compatible. You
can use either the Version 8 or Version 9 ASNCLP command-line program or
Replication Center to work with your Capture and Apply programs. The
Version 8 Capture program works with the Version 9 Apply program without
restriction. The Version 9 Capture program works with the Version 8
Apply program without restriction.
---------------------
Jan 24 '07 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Cherrish Vaidiyan | last post: by
2 posts views Thread by Martin McNally | last post: by
3 posts views Thread by dlesandrini | last post: by
9 posts views Thread by David W. Fenton | last post: by
1 post views Thread by Liam Lesboch | last post: by
reply views Thread by Odd Bjørn Andersen | last post: by
reply views Thread by leo001 | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.