Cool Features in SQL Server Denali HADR

If you haven’t been following the slowly oozing information spigot from the next SQL Server version, code name project “Denali”, then you may not be familiar with some really cool, new features implemented around high-availability or what is sometimes currently being referred to as HADR (High availability disaster recovery).

SQL Server has had log-shipping since I don’t remember when, database mirroring since SQL Server 2005 and Windows Clustering has been available to cluster SQL Server for many releases, too.

But these have existed as somewhat independent technologies which an administrator needed to learn about separately and an architect needed to design a SQL Server solution understand the risks, benefits and costs of each. Also, DBAs don’t always have the skills, experience, or network & system access to set-up and configure clustering software.

A lot of this has been consolidated and improved in Denali and I’ve been going through the latest features and roadmap leading us to the Always On HADR feature set in the next SQL Server. Below is my own compiled list of what I perceive to be the greatest benefits that a SQL Server DBA will receive from SQL Server Denali around high availability:

  1. You can have multiple mirrored databases from a single primary DB, known as failover replicas.
  2. You can now report from the mirrored database by connecting directly to the replica. Not need to take snapshots any longer.
  3. Geo-clustered SQL Server now supports multiple subnets
  4. Once you have a configured cluster, SQL Server can interop with the cluster software from T-SQL using the cluster API, keeping your hands clean from touching the Windows Cluster


For more details on the latest of the Denali high availability features, click here. BTW, straight-up mirroring, log shipping & Clustering will still exist by themselves, too, in SQL Server post R2.


One thought on “Cool Features in SQL Server Denali HADR

  1. Hi,

    I don’t think it’s a great idea to embed features really should belong to OS network and storage stacks (transactions, distributed cache, geo-clusters, HA and so on) directly to application. Instead of knowing how to configure OS properly and having clustering working for EVERYTHING running inside guest OS we’ll end with knowing how to rip SQL server. Very nice 🙂

    Anton Kolomyeytsev,

    CTO, StarWind Software

    Proud member of iSCSI SAN community.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s