Hello everyone,
We are upgrading (actually a side-by-side migration) a SQL2000 instance which is a transactional replication subscriber in Australia over to SQL2008R2.I'll describe here the names of the servers involved:
1. USACO3 - This the SQL2000 Publisher in the US. It will be upgraded to SQL2008R2 in a few months, but it is on SQL2000 for now. It has a publication which is published to AUSQL2000. USACO3 is always being updated and we don't want to stop updates even for a few minutes (if we can help it).
2. AUSQL2000 - This is the old SQL2000 instance which lives in Australia which we are MIGRATING FROM. It is updated locally and it is a subscriber of USACO3. During its migration AUSQL2008R2 we can stop all local (Australia) updates.
3. AUSQL2008R2 - This is the new SQL2008R2 instance which lives in Australia that we are MIGRATING TO - replacing AUSQL2000. Our goal during the migration from AUSQL2000 is to effectively *move* the subscription from USACO3 to AUSQL2000 over to AUSQL2008R2 without missing any updates in the replication stream.
This is the timeline of what we did during the migration of AUSQL2000 to AUSQL2008R2:
0600 - Stop all local (Australia) application updates to the old AUSQL2000 server.
0600 - Stop the replication distribution agent job running on USACO3 that is replicating to AUSQL2000 - This is because we - from this point forward - do not want to update AUSQL2000 ever again.
0600 - Start the backup of the replicated-to DB on AUSQL2000.
0700 - Backup ends on AUSQL2000.
0705 - We start the restore onto AUSQL2008R2.
0900 - The restore onto AUSQL2008R2 completes.
0900 - We run the initial CHECKDB, etc. on the newly restored DB on AUSQL2008R2.
1000 - The CHECKDB completes and we are now ready to move replication.
1000 - On USACO3 we DROP the SUBSCRIPTION which replicates to AUSQL2000.
1005 - On USACO3 we CREATE a new SUBSCRIPTION which replicates to AUSQL2008R2.
1005 - We now start data verification on AUSQL2008R2.
What we found was that all updates that were created on USACO3 between 0600 and 1005 *were not* replicated to AUSQL2008R2. We effectively lost all of these updates.
We were thinking (wishfully) that replication would queue all updates created during this time on USACO3 because the AUSQL2000 replication job was stopped. This did happen (USACO3 DID queue updates because the AUSQL2000 distribution agent was stopped), but these updates never made it to the new AUSQL2008R2 server. I have a theory on why these updates never made it to AUSQL2008R2, but I would like to hear it from an expert - you :) .
Ideally, we would like for the updates to queue up from 0600 - 1005 and then magically flow over to the new server, but … I can see that something is wrong with our plan. We do not want to re-snapshot anything. We do have programs that will find data differences (it will find what SHOULD be in Australia if replication is working), and we even have a way to re-push missing rows. However we would like for this migration to include all data - with no data-repair required after the migration - if possible.
Any ideas?
Thanks in advance.