This is another follow-up to this question. At the risk of pushing the limits of the "personal questions per day" ratio I would like to know whether a SQL Remote instance (consolidated or remote) needs all relevant files have equally encrypted. With relevant files, I'm refering to the database file(s), the current translog (and mirror) and all old log files that may be used to resend messages. I'm citing from an older NNTP thread ("Questions about encryption of existing databases in a SQL Remote setup" started 2006-09-19)
And the answer that Reg has given:
Question: According to current tests with a 12.0.1 cons (strongly encrypted) and a 8.0.3 remote that has incidentally lost old messages, the cons can use their old (and simply encrypted) v8 logs without problems when having to re-scan them to re-send messages. So it seems unnecessary to change the encryption of those old log files (which is fine, as it seems not even possible to do so - see the question above). So I would need to know whether the answer to point 3 is not valid (or no more valid in the combination v12/v8). For obvious reasons, I would need a clear statement as I do not want to risk to have lots of remotes re-extracted in case messages get lost. And we do have lots of old log files still waiting to be confirmed... (Sidenote: I'm aware that scanning pre-v10 logs is done in a different way then scanning v10+ logs. May this be the reason that there is possibly no need to use the same encryption here?) |
When changing your encryption scheme on a database involved in synchronization or replication, there are some things that will work, and some things that won't.
I've attached a ZIP file that shows this in action. Just unzip the contents into an EMPTY directory, then edit the rep.bat file and change the following two lines to point to v8 and v12 SA installs on your computer.
Next, open a DOS prompt, CD into the directory when the files exist, and type "rep". The sample will set up a V8 replicating environment, and then upgrade the simply encrypted v8 databases to strongly encrypted v12 databases, ensuring that there are operations in the offline simply encrypted v8 transaction logs and offline strongly encrypted v12 transaction logs that still need to replicate. Finally, the v12 dbremote process will run and process operations from all the offline logs. Well, if you call that a "non-immediate" answer, how fast are your responses usually? Thanks a lot for clarifying the behaviour of my tests. I won't be able to do some tests currently but do understand the situation. From your answer, I conclude that only if I would change from one strong encryption key to another one, then I would have to re-encrypt the old logs. And that would be doable with V8/V9 logs, too, whereas encrypting them from simple to strong is doomed to fail, as Graeme has stated.
(20 Apr '11, 14:13)
Volker Barth
Reg, I have tested and studied your sample today. Big thanks for putting this together - and a fine example in batch programming, too... Now I fell confirmed to go on with my migration. (Yes, I felt obliged to answer with a (fine?) example in "visual commenting":)
(26 Apr '11, 08:26)
Volker Barth
|
Any words to confirm or correct my assumptions are still very welcome... I won't migrate (or might have to keep on with simple encryption) until this topic is clarified:(
Volker, I'll need a bit of time to answer this. If you need an immediate answer, you should open a tech support case.
Reg, I don't need an immediate answer - a timely one should do:)
Thanks for looking after that issue! (And somehow I knew you would be the one...)