The current environment is a consolidated database replicating to 34 remote databases. During migration a full extract of the consolidated database will be made and converted to ASA 12. This ASA12 consolidated database will replicate with the ASA 8 consolidate database for the entire migration period. When the last remote database is converted to ASA 12 and the last application rewrite is completed the ASA 8 consolidated database needs to be decommissioned and the ASA 12 database needs to become the only consolidated database. My question is what do I need to do, to complete this final step? My first thought was that all I had to do is go to the SQL Remote property page and uncheck ‘This database has as corresponding consolidated database” and stop running the dbremote process the synced the ASA 8 consolidated to the ASA 12 Consolidated Is this correct or are there more things I need to do? I need the two consolidate database to support applications that only run in this environment that will be being rewritten. This configuration also allows easy fall back to the old environment if any issues arise.

asked 05 May '11, 17:30

Jturner's gravatar image

accept rate: 66%

edited 06 May '11, 03:48

Volker%20Barth's gravatar image

Volker Barth

[Note: This is gonna be a counter-question, not an answer...]

Is there really no possibility to migrate the cons from v8 to v12, and then use the v12 db as the only consolidated - and then migrate remotes lateron?

I've lately done that (after very thorough testing, obviously), and would think it is much easier than your plan.

Part of the my task was to make sure all related apps run with v8 and v12 unchanged or have to be changed (in a few cases, fortunately) to run with both. That included a few program updates and a few modifications in the database, say, by using STPs in v8 and v12 with minor differences.

Another part were intense tests to make sure SQL Remote works with both versions, because - as you state - I won't be able to go back to a v8 cons without having to re-extract some hundred remotes (which is a no-go, apparently): Migrating the v12 cons back to v8 would be doable with some effort, but the v12 logs created in the meantime won't be readable by the v8 software making the necessary log scans impossible.

Making tests with some v12 remotes in the production system were a third part - partly becuase the risk to re-extract those was affordable.

So, in a way, I have done that "month-long migration period" on test systems before the real migration of the consolidated - omitting a month-long migration there.

permanent link

answered 06 May '11, 03:47

Volker%20Barth's gravatar image

Volker Barth
accept rate: 32%

edited 06 May '11, 07:28

Volker, yes I think that it would be easier to do this but the client is nervous and conservative. They require at least a 2 month pilot before committing to the upgrade to ASA 12. This change is also involved in a conversion project that will have the entire application set rewritten in a new language. Finally the issue of resources rears its head , there is a limit to the number of testers available and programmers to maintain the old system while the new is being completed. The year period mention also involves the length of time that it will take to roll out the new application to the remote locations, again resource issues. As I reread the above I realize that it would be better to do as you suggested but at the moment I am unable to convince the customer to this path. So can you answer my question?

(06 May '11, 12:38) Jturner
Replies hidden

What do you exactly want to do when the v8 cons is going to be abandoned:

  1. Should the v12 remote become the cons, and then all remotes are going to be re-extracted from that cons?

  2. Or is there a need to switch the normal remotes to use the new v12 cons instead of the v8 cons (some kind of "hot-plugging the cons")?

The first approach would mean you are allowed to break the existing replication once the old cons can be put down, and start over from scratch. So you would just have to turn the v12 from remote status to cons status. (I guess those steps are doable with common SQL Remote configuration.)

The latter approach is no official way, methinks. For that road, I would highly recommend to get an answer from SQL Remote gurus like Reg. - At least, that's way beyond my personal experience...

(06 May '11, 13:02) Volker Barth

The process is as proposed is like this, remotes that were previously extracted from the 8 cons would be converted to being extracts from 12 cons until all remotes have been converted. At this time if all of the application changes have been made (there are two paths here one that only uses the cons database, the other the remote databases) the 12 cons becomes the only cons and 8 cons is decommissioned.

To put it another way a new layer is to be inserted between the current cons and its remotes so that when all of the remotes are replicating through this new layer then the root of the tree is removed making the inserted layer the new root.

(06 May '11, 15:41) Jturner
Replies hidden

Ah, now the process is getting clearer (and obviously different as I had thought so far):

  1. Situation so far:
    v8 cons <-> v8 remotes

  2. Situation during migration
    v8 cons <-> v8 remotes
    v8 cons <-> v12 cons <-> v12 remotes

  3. Final situation
    v8 cons <-> v12 cons <-> v12 remotes

I assume you using different publications for the "v8 replication" and the "v12 replication"?

Then I guess you would just have to do the following inside the v12 cons:

  1. revoke consolidate from the v8 cons publisher and
  2. drop publication for the appropiate v8 publications.

The latter will also remove the subscriptions the v12 has w.r.t. the v8 cons.

(07 May '11, 16:36) Volker Barth
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • 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: 05 May '11, 17:30

question was seen: 1,138 times

last updated: 07 May '11, 16:45