Features and Benefits of AlwaysOn Availability Groups

By Ginger Daniel | SQL Administration

Apr 07

AlwaysOn is a great new feature in SQL Server 2012 and 2014 Enterprise edition. It has been described as the next evolution of database mirroring. AlwaysOn enhances the existing technologies of database mirroring and failover clustering to provide a strong layer of high availability and disaster recovery.

The way it works is that you have your production databases residing on a primary server (replica), and these databases are replicated over to secondary server(s). The databases on your secondary replicas are available to use in read only mode. With SQL Server 2012 you can have up to four secondaries, and with SQL Server 2014 you can have up to seven secondaries.


The following are some of the features and benefits of using AlwaysOn:

Combined HA / DR.   AlwaysOn provides both high availability and disaster recovery because you have live copies of your databases residing on several secondary servers. These are not just backups, but live, up-to-date copies of your databases that are usable in read-only mode.

Zero Data Loss Protection. AlwaysOn provides for zero data loss protection. This assumes that you are using synchronous data replication. Synchronous data flow is where the primary replica sends a transaction to the secondary, and it waits for the secondary to harden that transaction to the log before it (the primary) will move on to the next task. So your data is absolutely safe, even though there is some latency. You can also set up asynchronous data flow, which is where the primary replica sends a transaction to the secondary, but it does not wait for the secondary to harden the log…it moves on ahead to the next task. With asynchronous data flow, there is a possibility for data loss, but the transactions execute faster.

Failover of Multiple Databases. Databases in an AlwaysOn group will all fail over together. This is unlike database mirroring where the databases fail over individually. And it is also unlike failover clustering where the entire instance fails over.

Automatic or Manual Failover. You can set your AlwaysOn group to fail over automatically or manually. If you use automatic failover, you must also use synchronous data flow. If you are using asynchronous data flow, failover must be manual.

Local or Shared Storage. Unlike failover clustering, shared storage is not a requirement with AlwaysOn. And by not using shared storage, you remove your SAN or other shared storage device as being a possible point of failure.

Automatic Page Repair. This feature is available with AlwaysOn.

Active Use of Secondaries. The databases on your secondary replicas are not just backup copies, but usable for read-only tasks. You can query the data, and do your reporting on the secondaries.   And you can direct your end-user connections to specific secondary replicas to spread out the workload.

You can also do some of your maintenance tasks on the secondary replicas: full and log backups, and integrity checks.

Enhanced Performance. Because you can offload some of these read-only and maintenance tasks to the secondary replicas, the performance of your primary replica will be enhanced. Because a lot of these operations can consume a lot of resources, offloading them will optimize the performance of your primary replica.

About the Author

  • Jiten Pansara says:

    Good article. Thanks for sharing it.

  • >