I’ve had situations come up a number of times over the years, where a target replica machine’s SQL Server application install was done the same as the production machine. The solution depends on how far off you were, but what you’re really trying to achieve are matching drive letters and paths. That’s the really cool thing about SQL Server, it doesn’t get crazy about assigning machine names and file GUIDs or any other such nonsense that make recovery of many other applications such a pain. (Note: That is one of the biggest reasons that we made Double-Take Full Server Fail-over, by the way) If the install is too different, I usually reinstall and re-service pack the offending machine, because frankly it’s just a whole lot easier. But not always!
I just spoke with Bill T. about a common scenario that he was facing while doing a big rollout of SQL Server targets and I thought I’d take a few minutes to pass on the knowledge to you. They install SQL and like any good IT group, they move their databases and transaction logs from C:\ to different disks for protection; R:\Data and T:\Logs respectively. They began their database replication with Double-Take and populated the R:\Data and T:\Logs folders with database replicas from the production machine just fine and dandy. However, they had not already moved the target server’s SQL Server instance database and transaction logs to R:\ and T:\. Thus the SQL configuration was looking for Master on C:\; and the make matters worse there was already a ton of data that had already been replicated from the production SQL Servers. Therefore, they couldn’t just use the SQL 2005 Surface Area Configuration tool and just move the databases over; they would overwrite all that good data.
Like our tag line says, “Breathe Easy”. This is a common issue and a very easy one to solve. We’re going to swap the data and logs directories.
First things first, you’re going to have to do a re-mirror of the data, so let’s just stop the Double-Take Connection or “Disable Protection” if you’re using DTAM. We’ll reconnect once we get the target SQL’s configuration corrected.
Next, rename the target directories to something else. R:\Data.Replica and T:\Logs.Replica. Now you can safely move the SQL System Databases and Logs to their appropriate volumes and directories. I would even start up SQL on the target to make sure that it works fine. Remember, I’m naturally paranoid. Once that looks good, then stop SQL and rename those directories to R:\Data.Original and T:\Logs.Original. Then you can rename the Replica directories back to R:\Data and T:\Logs, then boot the target SQL Server and they should mount just fine.
Finally, stop SQL on the target so that it doesn’t grab an exclusive lock and disable writing for Double-Take. Then you can re-establish the Double-Take Connection or “Enable Protection” in DTAM and DON’T forget to make sure that “Diff Mirror with Checksum” is enabled since you don’t need to send all the data back over the wire.
Easy and Apple Pie!
Nicholas Schoonover
Filed under: Product Information, SQL Server | Tagged: Double-Take, sql server
