Skip the navigation

Microsoft raises the bar with SQL Server 2012

By Barry Nance
July 16, 2012 12:40 AM ET

Earlier SQL Server versions offered essentially two approaches to High Availability. You could configure SQL Server to perform log shipping, which instructed the failover server to replicate the primary server, or you could use clustering to cause a standby server to assume the role of primary server upon failover.

Both approaches have their limitations. Failing over an individual database can take time, during which the database is unavailable. Cluster-based failover is costly for the extra server(s) that does no work until the primary server(s) fails.

SQL Server 2012's AlwaysOn feature borrows the concept of Database Availability Groups from Exchange Server 2010. AlwaysOn, however, implements the concept with a somewhat different architecture.

Unfortunately, AlwaysOn uses a great deal of bandwidth. In tests involving 50 clients feeding an Online Transaction Processing (OLTP) SQL Server 2012 database with an average 20 transactions per second, AlwaysOn's data replication and inter-server coordination more than doubled network utilization, from 22% to 47%.

SQL Server 2012 has other high availability enhancements. For the many applications that access multiple databases concurrently, SQL Server 2012 offers Availability Groups. You assign multiple databases to an Availability Group and, when a server dies, all the databases fail over as a cohesive unit.

Availability Groups are particularly useful for transferring database accesses from a primary site to a remote site, if a primary site suffers a catastrophic disaster. You can also set up multiple Availability Group assignments for a single SQL Server 2012 instance.

If disaster strikes, AlwaysOn will divide up the database retrievals and updates across the multiple servers you've designated in your disaster plan. A single database superserver can thus fail over to several lesser-horsepower machines. Your standby servers don't have to be expensive, idle-most-of-the-time copies of the primary.

The Availability Group concept worked well in the lab. When we "pulled the plug" on a database server, our simulated online transaction processing application kept running normally, completely unaware that it was accessing a different server.

Note that you'll have to make separate arrangements for the application itself and for any other system components and data files that the application relies on. In that vein, be aware that there are other high availability mechanisms that protect more than just the database server. For example, CA's ARCserve High Availability can perform sophisticated failovers for all of an application's computing resources. It can restart a crashed background process (i.e., Windows Service), if that's the cause of the problem. And it offers push-button failover and failback for the highest possible level of availability, plus bandwidth tuning/throttling and data compression to use the network more frugally.

Originally published on www.networkworld.com. Click here to read the original story.
Reprinted with permission from NetworkWorld.com. Story copyright 2012 Network World, Inc. All rights reserved.
Our Commenting Policies
Consumerization of IT: Be in the know
consumer tech

Our new weekly Consumerization of IT newsletter covers a wide range of trends including BYOD, smartphones, tablets, MDM, cloud, social and what it all means for IT. Subscribe now and stay up to date!