AlwaysOn Failover Clustering Microsoft’s premier high-availability technology, AlwaysOn Failover Clustering, is designed to reduce unplanned downtime by allowing clustered services such as SQL Server to automatically fail over to a backup node when a hardware or software failure makes the primary node unavailable. The SQL Server 2012 Business Intelligence and Standard editions are limited to two node failover clusters. SQL Server 2012 Enterprise edition can have up to 16 node clusters on Windows Server 2008 R2 and up to 64 on Windows Server 2012.

AlwaysOn Availability Groups A new option for SQL Server 2012, AlwaysOn Availability Groups is essentially the next evolution of database mirroring. Designed to protect against unplanned and planned downtime, AlwaysOn Availability Groups can replicate multiple databases to as many as four replica systems with a mix of both synchronous and asynchronous replication of the transaction log. It fully supports automatic failover. AlwaysOn Availability Groups are found only in the SQL Server 2012 Enterprise edition.

Database Mirroring Although I expect it will be eventually replaced by AlwaysOn Availability Groups, database mirroring is still available in SQL Server 2012. Database mirroring is limited to two systems: a principal and a mirror, with an optional witness that enables automatic failover. Database mirroring works by forwarding transaction log entries from a principal to a mirrored database, and it can be set up either synchronously for high availability or asynchronously across a WAN for disaster recovery. The SQL Server 2012 Business Intelligence and Standard editions can operate only in the synchronous full safety mode.

Log Shipping Designed to protect against disasters at the system and site levels, log shipping works by periodically running a stored procedure that forwards transaction log entries to one or more destination systems Unlike database mirroring, which works in real time and is capable of automatic failover, log shipping requires manual failover and failback processes. Log shipping is supported by all SQL Server 2012 editions.

Database Snapshots Database Snapshots are a point-in-time metadata-based copy of a given database, and they can be used for reporting purposes or to restore a database to previous state. For instance, database snapshots could be an effective protection against data corruption caused by user error. Database snapshots are supported only in the SQL Server 2012 Enterprise edition.

Fast Recovery Fast recovery helps a database to be available more quickly following a restore operation. With Fast Recovery, the database is available as soon as the committed transactions are reapplied following a restore operation, with no need to wait for the uncommitted transactions to be rolled back. Like many of the other high availability options, Fast Recovery is available only in the SQL Server 2012 Enterprise edition.

Live Migration While not technically a part of SQL Server 2012, Live Migration is a Windows Server technology that can help reduce planned downtime for virtualized SQL Server systems by allowing the SQL Server virtual machines (VMs) to be moved to a different host, with no end-user downtime. This enables maintenance to be performed on the virtualization host. All editions of SQL Server 2012 support live migration.

SQL Server on Server Core Again, while not strictly a high-availability technology, SQL Server 2012’s support for running on Server Core can also boost SQL Server 2012’s availability by reducing the amount of patching that’s required by the host Windows Server OS. All editions of SQL Server 2012 support running on Windows Server Core.

Discuss this Article 4

H Paul,
>>It absolutely does not apply to restore operations.
your comments is making me more confused. Are you saying that RESTORE does not do Crash Recovery. I though REDO and UNDO are also part of RESTORE.

What is it about crash recovery that makes Fast Recovery possible, and that isn't true for a normal restore?
BOL tells us "Fast recovery is possible because transactions that were uncommitted when the crash occurred reacquire whatever locks they held before the crash". This makes it sound as if the transactions with uncommitted changes at crash time are reconstituted, grab the same locks as they had before the crash to prevent freshly-logged-on users from making changes to those resources, and then complete their UNDO operation anyway.
So, why is that true during crash recovery/mirroring failover and not true for a database restore?

No - I'm saying that Fast Recovery does not apply to restores. Fast Recovery allows db access after REDO and before UNDO. Don't confuse crash recovery with recovering a database during a database restore.

From the Blogs

Many organizations today cannot use public cloud solutions because of security concerns, administrative challenges and functional limitations. However, they still need a centralized platform where end users can conduct self-service analytics in an IT-enabled environment....More

It is crucial to move away from data and analytics stored on individual desktop computers. Today’s solutions must promote holistic, collective intelligence. The strong, continued alliance between Microsoft and Pyramid Analytics helps make all this possible....More

To become a truly data-driven enterprise, many business leaders recognize that they must extend the capabilities of self-service business intelligence (BI) and analytics to more of their business users. Many BI tools tackle part of this need, but they don’t offer a complete enterprise solution....More