cancel
Showing results for 
Search instead for 
Did you mean: 

Migrating Replicating Production Database from version 12 to version 17

0 Kudos
1,511

I'm wanting to make sure I have my arms wrapped around moving our replication environment from SQLA12 to SQLA17.

We have our production database running on our server. Every hour at the bottom of the hour, we backup the database. We use the following switches...

-r (renames the transaction log ans starts a new log. copies the current working transaction log to our backup directory)
-s (image backup)

A couple other switches are used, but those are the most critical.

The long and the short of it is this. We brought our superintendents into the offices. All systems ran replication. All internal users with replicating databases ran replication. Then we shut down our version 12 database. All outstanding replication is up to date.

Since We're basically going to be doing remote resets on everyone, and then extracting new databases, is there any reason to bring over the transaction log files that were a part of the database? Or should we not worry about that, and instead bring the main db and log file over, and then let replication start over again?

My guess is the reason that our individual log files went back about a year and a half had to do with users that had not possibly replicated that data yet.

So when copying the database over and migrating it from 12 to 17, should I have all the transaction logs with it? Or just the current one?

Hope this question makes sense. If anybody needs clarification, please let me know.

Thanks!

Jeff Gibson Intercept Solutions
Nashville, TN

VolkerBarth
Contributor
0 Kudos

Is there a need for a re-extract for every remote? I'm asking as SQL Remote is certainly capable of upgrading the cons and the remotes one by one without any re-extraction - when properly handling logs and log offsets during the migration...

0 Kudos

When we migrated from 12 to 17, that obviously brought all the new changes to SQL Anywhere into the production database. The number of replicating database is small, so we figured we would just get to 17 and start over with new databases for all the replicating users.

VolkerBarth
Contributor
0 Kudos

Since We're basically going to be doing remote resets on everyone, and then extracting new databases, is there any reason to bring over the transaction log files that were a part of the database?

Just to understand:

  1. Is this a simple SQL Remote setup with one consolidated (cons) and several remotes, or are the remotes themselves consolidated databases for a further hierarchy (forming a multi-level setup)?

  2. Ary you asking for the older logs of the cons or for those of the remotes?

In my understanding, if the message stores of all databases are empty (i.e. there are no message files waiting to be sent or applied), once you do a remote reset for all remotes, all previous logs of all databases should be irrelevant. But as always with SQL Remote setups, I would strongly recommend to test this.

Accepted Solutions (0)

Answers (0)