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

SQL Replication Migration from V8 to V9

P: n/a
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
Share this Question
Share on Google+
3 Replies


P: n/a
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

P: n/a
In article <tO*******************@news-server.bigpond.net.au>,
gn***@namoicotton.com.au says...
Thanks, Greg
Nov 28 '06 #3

P: n/a
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.