SPC11: AlwaysOn in SQL Server Denali and SharePoint


This is a cross-post of my article on SharePointEduTech.

Bill Baer (@williambaer) gave an excellent presentation on the next version of SQL Server, codenamed Denali that will feature AlwaysOn. AlwaysOn is a new high-availability solution for SQL Server.

AlwaysOn provides both database and instance level protection. So how does AlwaysOn provide an “integrated, flexible, solution?”

There are 2 components for AlwaysOn:

  1. Availability Groups (database protection – like resource groups in clustering) which includes active secondaries (where you can read data).
  2. FCI (Failover cluster instances) – Provides instance level protection.

AlwaysOn is cost effective because the secondary can be used for backups, reporting, active farms that provide read-only content, etc (any read only operation).


  • Must have Windows Failover Cluster service enabled (for distributated state, and inter-node health detection). SQL boxes don’t have to be clustered.
  • Must be joined to the same AD domain andd use a domain account to create the failover cluster.
  • KB 2494036 hotfix is recommended for Windows 2008 R2. (allows a specified node to have more votes/weight than another node).
  • SharePoint Server 2010 with Service Pack 1


  • Server instances must reside on Win Server Failover Clustering, must all be in the same cluster
  • Must use same SQL Server system collation (SharePoint has restrictions that comply with this already).

Availability Group

  • Essentially combines log shipping and database mirroring.
  • Compression & Encryption built-in
  • Multiple secondaries
  • Synchronous and Asynchronous
  • Automatic or manual failover
  • Automatic Page Repair (can ask Secondary for copy of page if torn)

With AlwaysOn, connections are re-tried (instead of failed) when there is a failover.

My notes:

AlwaysOn can span subnets so content can be replicated and used elsewhere on a read-only secondary (such as high I/O backups). Roles can be changed manually or automatically, without reconfiguration. This means, no DNS changes or changing connection strings.

Easy transition from either database mirroring or log shipping to AlwaysOn; just a few minor configuration changes.

A flexible failover policy allows control over the condition when a failover should be initiated. This will prevent false failovers. There’s also increased detail in logging that will allow admins to determine why a failover occurred.

AlwaysOn provides the best RTO and RPO, over Failover Clustering, Log Shipping and Restore from backup.

Learn more about SQL Server High-Availability and AlwaysOn on microsoft.com.

0 comments… add one

Leave a Reply