This is just like buses, nothing for a month, then 3 at once:-)
Stamey (3/25/2009)
Here are a couple of possibilities.1. Set up DB mirroring from primary to DR server. If there is a primary server failure, make the DR server the principal and rename it. This should only take a few minutes. As far as I can tell, SQL 2005 does not store the server name inside and will allow renaming of the server OS.
Got to be SRDF I am afraid, for quick failover AND failback. No time for reinitialising from full database backup\restores
2. Make the server itself a VM, even if it is the only guest OS on that box, and stored the VM virtual disk files on the SAN, replicating them the same way as the SAN volumes the VM server uses for the data. What I am saying here is that the VM virtual disk is only for the C: drive. The SQL DB and transaction files will exist on their own SAN volumes, as you see fit.
This method should allow the VM to use the underlying host server resources as if their were no host in the middle, if the VM software will perform. I understand they have worked out the performance issues they had with SQL Server a few years ago.
Chris
We have some SQL on vmware, and SRDF in place for these, they are fine. Most of our apps don't perform on vmware though and this requirement is to get SRDF up and running on the physical boxes, some of which support multiple applications.
---------------------------------------------------------------------