DR solution

  • Hi Folks,

    SQL2000 and SQL2005. Our user databases are bit level replicated through SAN technology to disks at a remote location (Headware replication). The disks at the secondary site are attached to a virtual server. A part from attaching the user databases, migrating MSDB and master db settings across from the primary site to a SQL instance of the same name at the secondary site, I wanted to know whether there more were options available to me in builing a DR solution for this particury setup. As it seems at the moment this SAN solution was not built with SQL inmind.

    The constants here is the SAN solution cannot change.

    Thanks in advance

  • not quite sure what you mean by options available to you in this set up.

    As you are replicating the user databases only you would treat this like logshipping or database mirroring, i.e you need methods to keep system db objects in line. I just so happens you are using SAN replication rather than SQL methods.

    Ensure the vendors guarantee database consistency (i.e. data and log file sin a consistent state on failover)

    You say an instance of the same name, do you mean the server has the same name?

    ---------------------------------------------------------------------

  • Yes, on the secondary - for want of better word - the virtual server will be renamed to match the primary machine's name (this is because of application connectivity) in the event of fail-over. Master and Msdb will be in sync by manual methods. When the secondary is renamed the secondary SQL instance will be renamed to match that of the primary. The user databases and attached and hay presto fail over to DR. I've been force down this road as the SAN has been set up as is without making use of SQL. I can't undo the SAN setup and sy to mirroring. Will it do...?

  • It will do but you will of course have to test it.

    Most important is that this 'headware' replication is guaranteed with databases.

    If you are renaming the server you will need to run sp_dropserver...sp_addserver.

    With SQL server 2005 renaming the server will orphan the local accounts SQL creates on install. Quick fix for this is to give the service account local admin. You could get away with replicating your system databases as well if the server is going to be renamed.

    Has DNS aliasing been considered to repoint the application? Its a toss up with how many objects you have in msdb that are server name specific.

    ---------------------------------------------------------------------

  • Thanks for responding,

    DNS aliasing is not an option due to inflexible application...there's a lot of cool stuff I want to use however there are tight constraints such as SPs referring to the actual SQL instance...(I know what you might be thinking...its my inheritance)

    I'm currently log shipping, and backing my databases + transaction log files, and then there is the SAN hardware replication. At the moment, the SAN element will be the primary fail over out of the 3 methods deployed, it's kind like a do it your self cluster. Acceptable? Or are there other options given the hardware SAN replication is the contraint?

    Thanks in advance

  • why do you need to log ship and san replicate? I must be misunderstanding something? You might as well use the SAN replication as your only solution to replicate data.

    As you are renaming the server you may as well replicate the system databases as well and increase the amount of automation in the failover.

    ---------------------------------------------------------------------

  • restoring the master and MSDB from one SQL Instance to another with the same name will work? What about the pointers of the user database location...orphaned users etc (SQL2000/SQL2005)...i don't think its very clean this way...but what do you think?

    Log shipping is in place for the moment until DR (SAN) is completed

  • the main reason it does not normally work is because the server name is different or the install paths are different.

    On the initial installs both servers must be built identically, (install directories, versions etc) and kept identical going forward.

    if the system dbs and user dbs have come from the same server you will not get orphaned users or database files not found.

    If you are SAN replicating your user databases they MUST be in identical locations.

    Just to be clear I am not talking about restoring the system dbs but using the SAN replication for them as well.

    Not saying you have to do this and in most cases I would not, but in your scenario it would be a viable option.

    ---------------------------------------------------------------------

  • Sure, if every thing is the same it should work. The only difference here is the SQL install of the system databases will not be on the SAN on the secondary, but a virtual drive. In DR situation, the SQL server would be put into master-only recovery mode and I would point the instance to the new location of the system databases sitting on the SAN disks...would you agree with this?

    Of course all this will be tested and proven...this was the only thing I could come up with the situation

  • Russell.Morgan-813114 (7/8/2010)


    Sure, if every thing is the same it should work. The only difference here is the SQL install of the system databases will not be on the SAN on the secondary, but a virtual drive. In DR situation, the SQL server would be put into master-only recovery mode and I would point the instance to the new location of the system databases sitting on the SAN disks...would you agree with this?

    Of course all this will be tested and proven...this was the only thing I could come up with the situation

    no I would not agree with this, the failover process is getting too convoluted, risky and time consuming. I would either go to building the two servers the same so you can replicate your system databases or use manual processes for system dbs and treat this the same as you would say logshipping but you happen to be using SAN replication to keep the user databases in-synch.

    ---------------------------------------------------------------------

  • I agree with you regarding the convoluted approach to this. As the operating system and SQL install are not replicated via the SAN...so there is no other option...at least in my minds eye. Don't forget, I'm looking for ideas...so I have an open mind to my dilemma but the constraints are obvious

Viewing 11 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic. Login to reply