- 15 Non-Certified IT Skills Growing in Demand
- How 19 Tech Titans Target Healthcare
- Twitter Suffering From Growing Pains (and Facebook Comparisons)
- Agile Comes to Data Integration
Page 2 of 4
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.
Another convenient, impressive and practical new SQL Server 2012 feature is replication to a Read-only Secondary. By copying database changes to the read-only secondary in a way that assures the integrity of related database contents in the secondary database, SQL Server 2012 makes backing up an active, in-use database painless and quick ... you simply make periodic backup copies of the read-only secondary database, not the primary.