SQL Server 2012 made huge improvements to the available HA\DR technologies in its flagship RDBMS and they have been widely reported on and documented. This post is not meant to recreate those that provide instructions for installing or setting up the newest features but is an effort to provide my perspective as someone who has been working closely with this platform since 1998. I have also included a few thoughts on the upcoming release of SQL Server 2014.

AlwaysOn is really just a fancy marketing term for 2 great legacy features of SQL Server that have been taken to the next level; Failover Clustering and Database Mirroring. The distinction is important as Failover Clustering is designed to provide protection against the failure of the Operating System, SQL Services, and the underlying hardware while database mirroring is designed to offer protection at the granularity of the database. For the purposes of this post I want to concentrate on the changes to Database Mirroring but will touch on Failover Clustering in several different areas.

<strong>AlwaysOn - Availability Groups</strong>

This is the term given to the added Mirroring functionality in SQL Server 2012. Traditional mirroring is still available but Availability Groups takes it to another level. This is because in a simple Mirroring setup one must rely on an external technology to determine which database is healthy at any given time and perform the failover. Examples of this would be newer versions of the Windows ODBC Client, Citrix NetScaler (<a href="http://www.citrix.com/products/netscaler-application-delivery-controller/features/app-delivery/database-load-balancing.html">DataStream</a>), custom application functionality, etc. Additionally, Availability Groups allow the secondary replicas (up to 4) to be placed into a configuration that allows read-only access for items such as reporting and backups. It is important to note that automatic failover requires the use of Synchronous or "High Safety" mode.

SQL Server 2012 abstracts the detection of a failover and subsequent re-routing of database activity using Windows Failover Clustering. Just as it does in SQL Server Failover Clustering, Windows takes on the task of providing a single connection point (<a href="http://technet.microsoft.com/en-us/library/hh213080.aspx">Availability Group Listener</a>) and directs incoming connections to whichever database is serving the desired role (i.e. primary, read-only, etc.)

Another nice feature of Availability Groups is that it takes some of the complexity out of setting up with primary and replica by only requiring a full backup to be taken of the primary database. Previously one would need to take the backup(s), create the secondary database, restore the backup, etc. before synchronization could occur - this is no longer the case.
<p style="text-align: center">Example of High Availability Across Individual SQL Server Instances</p>
<p style="text-align: center"><a href="http://egroup.jasonmangone.com/wp-content/uploads/2013/08/AG.gif"><img class="aligncenter  wp-image-8385" alt="AG" src="http://egroup.jasonmangone.com/wp-content/uploads/2013/08/AG.gif" width="464" height="185" /></a></p>
<p style="text-align: center"></p>
<p style="text-align: center">Image courtesy of msdn.microsoft.com</p>
&nbsp;

<strong>AlwaysOn - Failover Clustering</strong>

There are several new features in SQL Server 2012 Failover Clustering but the essence remains the same as it allows the protection against failures at the Operating System, SQL Server Service, and hardware layers. Coupled with AlwaysOn High Availability Groups it provides layers of protection at every critical point in the SQL Server solutions stack.
<p style="text-align: center">Example of High Availabil</p>
<p style="text-align: center"><img class="aligncenter  wp-image-8386" alt="AGCluster" src="http://egroup.jasonmangone.com/wp-content/uploads/2013/08/AGCluster.gif" width="499" height="347" /></p>
<p style="text-align: center">Image courtesy of msdn.microsoft.com</p>
<p style="text-align: left"></p>