Sunday, February 26, 2012

FAQ: Are there any whitepapers about building a Disaster Recovery site at a remote location

Hi,

Sorry for the wide distribution.

I'm trying to find any useful whitepapers about how to effectively build and operate a disaster recovery site at a remote location for SQL Server 2000. Does anyone know where to find such information?

I also know that one good option for my customer is using the Mirroring feature of SQL Server 2005. What are the other options? Is Replication an effective one for a mission-critical database (online banking)?

Thanks in advance

here are some articles and white papers that may be helpful to you:

SQL Server 2005 Failover Clustering White paper
http://www.microsoft.com/downloads/details.aspx?FamilyID=818234dc-a17b-4f09-b282-c6830fead499&DisplayLang=en

Database Mirroring in SQL Server 2005
http://www.microsoft.com/technet/prodtechnol/sql/2005/dbmirror.mspx

SQL Server 2000 High Availability Series
https://www.microsoft.com/technet/prodtechnol/sql/2000/deploy/harag01.mspx

SQL Server 2000 Backup and Restore
http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/sqlbackuprest.mspx

|||

I'm not trying to endorse products and I'm not claiming to know the most about this topic. There are many people that have a lot more insight into the specifics but these are intended to give you some quick and dirty information.

I haven't been able to find anything that specifically addresses the DR for SQL Server 2000 that is all encompassing. In general there are somethings that you could consider that vary in costs as your recovery techniques become more sophisticated.

Some options that are available within SQL 2000 are:

Log shipping: I believe that you send log backups and restore them at the far end without recovery. When a disaster occurs you restore the last log backup with the WITH RECOVERY option and your off and running on your backup server.

Replication: The freshness of the data at the far end will depend on the replication model chosen. Real time can be very demanding if you're planning on replicating every table in every database on your SQL Server. Generally speaking there is less overhead the more specific you could be. There are some functionality constraints that you will have to investigate to see how well they will work for you. For example if you add a column to a table that is being replicated you will have to manually add that column to the subscription for the subscribers to receive it. This is a very simple example.

Some options that are available within SQL 2005

Log shipping: Works similarly to SQL 2000.

Replication: Much improved over SQL 2000. Subscriptions automatically add columns added to tables now. Very slick.

Database Mirroring: Just had this functionality enabled with SP1. There is a lot to consider with this model. There is a primary database server, a secondary or backup database server, and a witness database server. The witnesses function is to control when the failover happens amongst other things. One of the downfalls are incorrect failovers.There are instances of the witness server incorrectly identifying a failed primary server and forcing traffic to the backup. Also I'm not sure how smooth the failback works.

Warm database server just needing to have SQL databases restored. This is a very low cost and not very real time option. This is SQL version independent.

There are several different third party High Availability/ Disaster Recovery products that are out there. Depending on how sophisticated a failover you'll need to have.

Sonasoft - Sonasafe for SQL Server - www.sonasafe.com

Neverfail - Neverfail for SQL Server - www.neverfailgroup.com

This is a very broad topic to try to address I'm sorry if this information hasn't been helpful. If you'd like to compare notes, I'd be glad to discuss some of my findings. I'm going through a very similar experience right now. Except we are a SQL 2005 only shop.

The other thing that you didn't mention is whether or not you're considering clustering. This adds a whole additional level of complexity to the considerations.

Drew Flint

No comments:

Post a Comment