This latest release of the SQL Server presents new features and improvements that increase the power and efficiency of architects, developers, and administrators who design, develop, and maintain data storage systems.
This article will walk you through all new features that are introduced in SQL Server 2012 especially high availability. For guarding application databases in an enterprise environment from both downtimes, the main features AlwaysOn Availability Groups (AAG) feature is introduced in MS SQL Server 2012 and a number of other HA features.
Always-On Availability Groups (AAG)
As for some Exchange administrators this feature is very similar to Database Availability Groups (DAG) in Exchange 2010. Configuring SQL 2012 AlwaysOn Availability Groups involves creating and constructing one or more availability groups. An availability group is a global container that defines a set user DBs (availability databases) to fail-over in case of disaster, and a set of database replicas to host multiple copies of each DB. An each group requires at least two replicas exist: the primary replica and one secondary replica. AlwaysOn Availability Groups offers a rich set of choices that increase database availability and that assist improved resource use. Below are a few feature sets of AAG:
- Numerous secondary replica copies: up to four secondary db copies.
- It allows control over the automatic failover process using flexible failover policy for each availability group.
- Provides secure, high performing transport to replicas via Encryption and compression.
- Other availability modes: Asynchronous-commit mode and Synchronous-commit mode
- Several failover modes: automatic failover, planned manual failover, and forced manual failover. For more information
- Through better source utilization of spare hardware permits Active secondary which increase IT efficiency and reduce cost.
- Provides fast application-failover via Availability group listeners.
- Automatic page healing for protection against page corruption.
- Forcing WSFC quorum
Always-On SQL Failover Cluster
Failover clusters across subnets
A SQL Server multisubnet failover cluster is a design where all failover cluster node is connected to a different networks or different set of networks. These networks can be in the same physical location or in phsicallydispersed . Clustering across global sites is sometimes referred to as Stretch-clusters. As there is no need for shared storage that all the nodes can access, data should be replicated among the data storage on the multiple networks. With data replication, there is further than one copy of the data available. Therefore, a multi-subnet failover cluster offers a disaster recovery solution in addition to HA.
Flexible policy for cluster health detection
In a SQL Server failover-cluster instance, only one node can own the cluster which is sometimes known as a single copy cluster. The client demands are served through this primary node for that failover cluster instance. In the case of a hardware failure, the group ownership is moved to another node in the failover cluster node. In this case the process is called failovering over a cluster.
This new feature offers a database-specific substitute to automatic checkpoints, which are shaped by a server property. An indirect checkpoint implements a new checkpointing formula for the DB Engine. This offers a more accurate assurance of database recovery time in DR event or a failover than is provided by automatic-checkpoints. To guarantee that database recovery does not top allowable downtime for a given db, you can stipulate the maximum acceptable downtime for that database.