SQL server & disaster recovery

  • I wish to setup a hot DR facility for a number of SQL databases. Fortunately i have access to a high end EMC storage frame that is able to synchronously mirror to a remote location (about 60 miles). I plan to place database files on individual volumes & synchronously mirror these to the remote site. At the DR site I have servers waiting with all necessary software. When we enter DR the volumes become available at the DR site & appear online to the servers.

    I now want to pick up the DBs on these volumes & run them. the issue I'm unsure of is logons. Any one done this type of DR? It is very common on mainfarmes & large UNIX - I suspect the Windows environment is less simple!

  • I am currently at a client that is using HP SANs and is using disk mirroring for DR. Mirroring is at the partition level. I performed a DR test 2 weeks ago without any problems.

    The Production Server Partitions are:

    C: is not mirrored and houses Windows, SQL Server software and any other software. This partition does not contain the text logs for SQL Server or the SQL Agent services. This drive is not mirrored since the hardware of the production and DR servers could be, and are, different.

    D: mirrored - system databases (both data and log) and user database data files (*.mdf) and the error text logs.

    E: mirrored - transaction logs for user databases.

    F: not mirrored - tempdb mdf and ldf. Since tempdb is rebuilt on SQL Server startup, there is no need to mirror and this can reduce bandwith usage.

    R: mirrored - backups of database and tranaction log.

    For Windows logins:

    Service Accounts are granted their appropriate rights on both servers.

    Individual users are never granted any rights directly but instead are always granted to Active Directory groups (i.e. the DBA group is granted local adminitrator rights). As group membership changes, the Active Directory replication insures that these changes are available at the DR site.

    It is a manual process to insure any changes in local group privileges or adding/removing groups is performed on both servers.

    For SQL Server logins, since the master database is replicated, the SQL Server logins are also replicated.

    One situation that was overlooked, was when a SQL Server patch or service pack is applied to the production server, how to replicate the changes to DR server. Since patchs do make changes to the registry, which is on a non-mirrored drive, extra steps need to occur. No proven solution yet but we are considering this approach:

    On the DR server, when the initial install is performed, install the system databases on the C: drive and not on another drive.

    Patch installation then needs to occur twice, once on the real server and then again on the DR server.

    When switching to the DR server and after the mirrored drives become available,

    then the SQL Server startup parameters, which are stored in the registry, need to be changed, using regedit.exe, to point to the mirrored drive, which in this senario is D:

    SQL = Scarcely Qualifies as a Language

Viewing 2 posts - 1 through 2 (of 2 total)

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