1. Business Continuity Planning with SQL Server HADR options
Prem Mehra
Program Manager
Microsoft Corporation

2. Key Takeaways of the Session
SQL Server 2008 and SQL Server 2008 R2 can meet very high HA and DR requirements
Upgrades to SQL Server 2008 and to SQL Server 2008 R2 can be achieved with downtime limited to minutes
Demanding HA and DR deployments require very good documented operational procedures and highly skilled staff

3. App/User Error Recovery
Current Technologies
Database Mirroring
Hot
Standby
Warm
App/User Error Recovery
Log Shipping
Log Shipping With Restore Delay
Production
Database
Replication
Scale Out
For Queries
Failover Cluster
Failover Clustering
Local server redundancy
Database Mirroring
Local server & storage redundancy
Disaster recovery
Log Shipping
Additional disaster sites for databases
App/user error recovery
Replication
Database reporting and read scale out with redundancy
Always On Partner Solutions
Highest hardware reliability

4. Proven HA / DR Architectures: Successfully Deployed by Customers#
Architecture
Key Distinguishing
Scenario Use & Deployment Characteristics
Examples 1
Failover Clustering for HA and Database Mirroring for DR
Single data copy for HA sufficient
Positive experience with Failover clustering
Comfortable deploying two different technologies for HA & DR
ServiceU and CareGroup 2
Synchronous Database Mirroring for HA/DR and Log Shipping for additional DR
Require deploying fewer (only one) technology for HA & DR
Avoid costs associated with Failover clustering
For HA, remote data center execution acceptable
bwin 3
Geo-Cluster for HA/DR
Positive experience with Geo-Clustering
Edgenet 4
Failover Clustering for HA and SAN-based Replication for DR
Require deploying single DR technology across multiple DBMSs
A third party DR technology acceptable
MySpace 5
Peer-to-Peer Replication for HA and DR (and reporting)
Simultaneous data manipulation from multiple sites
Potential data loss acceptable
Enterprise in Travel Industry
Keep Myspace and Agoda greyed out (faded) and talk that these will not be discussed during this session.

5. SQL Server Infrastructure
DNS
Memphis Primary Data Center
Atlanta Standby Data Center
WEB FARM
WEB FARM
DNS
DNS
PRINCIPAL
Preferred
DB Connection to Memphis for Regular Test Exercise
MIRROR
Asynchronous Database
Mirroring
Windows 2008 SQL 2008
Windows 2008 SQL 2008

6. Upgrade Process
Setup a temporary cluster (Windows Server 2008 and SQL Server 2008) in the primary data center
Establish log shipping to temporary cluster
Break DBM to the DR data center
Establish DBM from production cluster to temporary cluster (convert LS to DBM)
Failover to temporary cluster. Temporary cluster is now production
Break DBM to old production cluster, and rebuild the old production cluster with Windows Server 2008 and SQL Server 2008
Establish DBM from temporary production cluster to the newly built cluster
Failover to newly built cluster. New cluster is now production
Rebuild the old DR cluster with Windows Server 2008 and SQL Server 2008
Establish log shipping to the newly build DR cluster
Break DBM to temporary cluster in the primary data center
Establish DBM from production cluster to new DR cluster (convert LS to DBM)
Too verbose. Rewrite to convey the message with fewer bullet points.

7. SQL Server Disaster Recovery
Applications:
1- SharePoint
2- SSRS
3- BlackBerry
4- Citrix Server
5- VMware VC
Cisco Global Site Selector (GSS)
DNS
Alias Name = Green
Active IP:
Connect to: Green\SQL1
SQL Server Cluster
SQLNetworkNameA\SQL1
Active IP:
SQLHostNameB\SQL1
Passive IP:
Principal Server
Mirroring
DR Site
Mirror Server

8. Give back to Server Team Borrowed from Server Team
Upgrading Failover Cluster: To Windows Server 2008 R2 and SQL Server 2008 R2
Windows Server 2003
SQL Server 2005
6 nodes Cluster
Each SQL instance has two preferred owners
Windows Server 2008 R2
SQL Server 2008 R2
Mirroring
Mirroring
Mirroring
Evict
Evict
Evict
Mirroring
Mirroring
Mirroring
Give back to Server Team
Borrowed from Server Team
Rebuild
Rebuild

9. Infrastructure Scale Up & Zero Data Loss
Principal
Mirror
Log Shipping
2nd copy
Log Shipping
1h delay
All Log Backups and
Full Backups Days 1,3,5…
All Log Backups and
Full Backups Days 2,4,6…

10. HA Zero Data Loss Solution Remarks
Zero data loss is higher priority than Availability, so if we can’t harden the transaction to disk in two datacenters, we put our application offline
If “Principal” fails, we put our application offline, failover to “Mirror”, break the mirror and promote “Log Shipping Copy 2” to be the new mirror.
If “Mirror” fails, we put our application offline, let “Log Shipping” catch up and promote it to be the new mirror
If either of the log shipping secondaries fail, we continue operation
One of the log shipping secondaries has the one hour delay to be able to fix human or applications errors (like deleting data) quickly, if we do not detect deleted data within an hour we have to restore on of our backups
Backup Infrastructure: Each datacenter has one file server optimized to hold large files (but just a few < 10,000) and one to hold small files (but many of them > 1,000,000)

11. Infrastructure Scale Up and High Availability
Principal
Mirror
Log Shipping
2nd copy
Log Shipping
1h delay
All Log Backups and
Full Backups Days 1,3,5…
All Log Backups and
Full Backups Days 2,4,6…

12. High Availability Solution Remarks
Priority is Availability but with the theoretical ability of loosing some data
“Principal” does sync database mirroring to “Mirror” and a Witness watches them both
If “Principal” fails, we automatically failover to the mirror, a scheduled SQL Server Agent script will then assess the situation and if the failed server does not come online within a few minutes it will break the mirroring session, and promote “Log Shipping Copy 2” to be the new mirror.
If the second data center fails we go offline, a scheduled SQL Server Agent script will then assess the situation and if the failed server does not come online within a few minutes (we give it more than the principal) it will break the mirroring session and let “Log Shipping” catch up and promote it to be the new mirror.

13. Cluster Diagram

14. Moving Databases to New Datacenter
Preparation
Old Data Center
New Data Center
Still Live in Production!
Snap
Replicate Data
On the Target Server
Add the SAN snapped drives as mount points
Eliminates the Drive Letter limitation by allowing as many drives as needed
Install SQL Server on the local drive
Place the System Databases on the SAN Drive under a mount point
Attach the User Databases , create the jobs, monitoring scripts, etc.
Verify connectivity by running all the SELECT Stored Procedures
Add the Target Server to the cluster
Run the verification procedure on the snapped drives
Saw a saving of over 2 hours per server

15. Moving Databases to New Datacenter
After the Prep is Done
Make another Copy of the volumes on the Source Server and replicate them to the Target Server
Here is the Tricky Part
Stop SQL Server
Remove the volumes used to prep the server
Add the latest volumes with EXACTLY the same layout as the prep volumes
Start SQL Server
Test connectivity, call the SPROCS which run SELECT Statements

16. Moving Databases to New Datacenter
Why Does This Work?
Trickery & Shenanigans
The sys.sysDatabases stores only where the MDF file is located so as long as the MDF is where sys.sysDatabases says, no issues will exist
Since the sys.sysFiles data is stored in each database the switch can take place seamlessly

17. Topology Deployed P2P Reference Tran Financial ASIA Web Tran Reference
America Web
P2P Financial
ASIA CORE 1
America CORE 1
Web Publication
Asia Core: IBM x x6 64 GB
Data Warehouse
Asia DW: IBM x x6 128 GB
America Core: HP DL380 G5’s 2x4
64GB
Read Only Copy
ASIA CORE 2
America CORE 2
Web Servers: IBM x x 4 8GB
America Web
ASIA Web

18. © 2011 Microsoft Corporation. All rights reserved
© 2011 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.