Tech-Ed 2011 Day 3 - SQL Server Denali AlwaysOn

DBI302 Microsoft SQL Server Code-Named "Denali" AlwaysOn Series, Part 1: Introducing the Next Generation High Availability Solution
DBI404 Microsoft SQL Server Code-Named "Denali" AlwaysOn Series, Part 2: Building a Mission-Critical High Availability Solution Using AlwaysOn

The sessions on SQL “Denali” (the next unnamed SQL Server release) overlapped to a great extent, I have combined both Monday and Wednesday’s sessions into one summary. Unfortunately, both sessions suffered from the same issue of too many fast-paced demonstrations with a font size that was too small for even the people sitting in front of the screens.

SQL Denali AlwaysOn feature appears to be the best advance in the upcoming release (now available as a CTP). Highlights of AlwaysOn:

• Multiple database failover of databases within an instance by grouping them into a failover cluster (note this is not necessarily MCS though MCS can be part of this). This can be multi-site.
• Up a 4 node AlwaysOn secondaries – 2 synchronous, and 1 automatic failover pair
• Ability to do automatic failovers and manual failovers… and back. Use of a virtual name for the failover allows clients to not have to be reconfigured.
• Can set a secondary to be active and not just an unused mirror - this allows it to be used for read-only workloads such as reporting and backups. Backups on transaction logs on a secondary even preserve the log chain across all replicas. Backups must be full copy backups as differentials cannot be done.
• Logins is one are where this has fallen short. Users in a group do not replicate, though there is now functionality through making a database partially contained to have users in the database itself and not in master, thereby allowing the permissions to replicate.
• In an MCS cluster tempdb can now be local disk and does not have to be on shared storage. This could allow local SSD’s to be used for what can be the most intensive I/O in SQL.
• Removed the 26 instance drive letter limitation for clustering.
• Support for Windows Server Core - this will increase the administration overhead, but could reduce the patching frequency. I have yet to see if there’s a functional limitation, particularly around using .NET runtime if you cannot install .NET Framework on Core.
• Filestream replication – if using Filestream for remote BLOB storage, this does not have to be replicated separately.

Some resources I will be checking out for more information:
AlwaysOn blog
SQL Server AlwaysOn