|
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) 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 |
Please be aware that the content in SAP SQL Anywhere Forum will be migrated to the SAP Community in June and this forum will be retired.
Follow this question
By Email:Once you sign in you will be able to subscribe for any updates here
By RSS:Markdown Basics
- *italic* or _italic_
- **bold** or __bold__
- link:[text](http://url.com/ "title")
- image?
- numbered list: 1. Foo 2. Bar
- to add a line break simply add two spaces to where you would like the new line to be.
- basic HTML tags are also supported
Question tags:
question asked: 13 Apr '18, 11:57
question was seen: 1,229 times
last updated: 17 Apr '18, 03:40
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...
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.
Just to understand:
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)?
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.