Availability Enhancements (Database Engine)

For protecting application databases in an enterprise environment from both planned and unplanned downtime, SQL Server 2012 introduces the AlwaysOn Availability Groups feature and a number of other high-availability enhancements.

In This Topic

  • New or Enhanced Features in SQL Server 2012 SP1

  • AlwaysOn SQL Server Failover Cluster Instances

  • AlwaysOn Availability Groups

  • Online Operations

New or Enhanced Features in SQL Server 2012 SP1

For a summary of all SQL Server 2012 SP1 enhanced features, see New or Enhanced Features in SQL Server 2012 SP1.

Cross-Cluster Migration of AlwaysOn Availability Groups for OS Upgrade

SQL Server 2012 SP1 introduces support for cross-cluster migration of AlwaysOn Availability Groups for deployments to a new Windows Server Failover Clustering (WSFC) cluster. A cross-cluster migration moves one AlwaysOn availability group or a batch of availability groups to the new, destination WSFC cluster with minimal downtime. The cross-cluster migration process enables you to maintain your service level agreements (SLAs) when upgrading to a Windows Server 2012 cluster. SQL Server 2012 SP1 must be installed and enabled for AlwaysOn on the destination WSFC cluster. The success of a cross-cluster migration depends on thorough planning and preparation of the destination WSFC cluster.

For more information, see Cross-Cluster Migration of AlwaysOn Availability Groups for OS Upgrade.

Arrow icon used with Back to Top link[Top]

AlwaysOn SQL Server Failover Cluster Instances

  • Multi-subnet failover clusters: A SQL Server multi-subnet failover cluster is a configuration where each failover cluster node is connected to a different subnet or different set of subnets. These subnets can be in the same location or in geographically dispersed sites. Clustering across geographically dispersed sites is sometimes referred to as Stretch clusters. As there is no shared storage that all the nodes can access, data should be replicated between the data storage on the multiple subnets. With data replication, there is more than one copy of the data available. Therefore, a multi-subnet failover cluster provides a disaster recovery solution in addition to high availability. For more information, see SQL Server Multi-Subnet Clustering (SQL Server).

  • Flexible failover policy for cluster health detection: In a SQL Server failover cluster instance, only one node can own the cluster resource group at a given time. The client requests are served through this node for that failover cluster instance. In the case of a failure, the group ownership is moved to another node in the failover cluster. This process is called failover. The improved failure detection introduced in SQL Server 2012, and addition of failure condition level property allows you to configure a more flexible failover policy. For more information, see Failover Policy for Failover Cluster Instances.

  • Indirect checkpoints: The indirect checkpoints feature provides a database-specific alternative to automatic checkpoints, which are configured by a server property. Indirect checkpoints implements a new checkpointing algorithm for the Database Engine. This algorithm provides a more accurate guarantee of database recovery time in the event of a crash or a failover than is provided by automatic checkpoints. To ensure that database recovery does not exceed allowable downtime for a given database, you can specify the maximum allowable downtime for that database.


    An online transactional workload on a database that is configured for indirect checkpoints could experience performance degradation.

    For more information, see Database Checkpoints (SQL Server).

Arrow icon used with Back to Top link[Top]

AlwaysOn Availability Groups

Deploying AlwaysOn Availability Groups involves creating and configuring one or more availability groups. An availability group is a container that defines a set user databases (availability databases) to fail over as a single unit, and a set of availability replicas to host copies of each availability database. Each availability group requires at least two availability replicas: the primary replica and one secondary replica.

AlwaysOn Availability Groups provides a rich set of options that improve database availability and that enable improved resource use. The key components are as follows:

For more information, AlwaysOn Availability Groups: Interoperability (SQL Server).

AlwaysOn Availability Groups Tools

AlwaysOn Availability Groups provides an integrated set of tools to simplify deployment and management of availability groups, including:

Arrow icon used with Back to Top link[Top]

Online Operations

  • Extended support for online index builds

    Indexes that include columns of large object (LOB) data—varchar(max), nvarchar(max), varbinary(max), or XML data—can now be built, rebuilt, or dropped online. For information about online index operations, see Guidelines for Online Index Operations and Perform Index Operations Online.

  • Reduced downtime for application upgrade

    Adding table columns that contain default values is now a metadata-only operation, so only a brief exclusive lock needs to be taken on the object, typically lasting for less than a second. Long-term exclusive table locks are no longer needed. For information about adding table columns, see Add Columns to a Table (Database Engine).

Arrow icon used with Back to Top link[Top]

See Also


What's New (Database Engine)

AlwaysOn Availability Groups (SQL Server)

AlwaysOn Failover Cluster Instances (SQL Server)

Windows Server Failover Clustering (WSFC) with SQL Server