有时很久没上来写东西了，过年前都是开会，然后过年，回来之后继续开会，最近还好终于开始写代码了。 SQL Server 2012就要发布了，里面太多新功能，尤其是BI方面的功能，要不是这样微软也不会单独提供一个BI的版本。在数据管理上，SQL Server 2012里面提供了一个HADR的解决方案，将之前的很多技术集中整合到一个功能里，降低了高可用的实施的成本及实现方案的复杂性，当然功劳也不全是SQL Server的，Windows的贡献也很大，毕竟HADR是要基于Windows Cluster的，而且多站点群集也非常的实用。 这里我要说的是HADR中一个很重要的功能和参数，就是对于数据库负载均衡的功能。SQL Server一直以来都没有这种在数据库级的负载均衡功能，但是在SQL 2012里面可一看到一部分这样的实现。在HADR中，有一个Primary的副本可以用于应用程序对于数据库的读写操作，其他的一些副本可以设置为接受只读操作。所有对于只读数据库内表的非只读操作都会被拒绝。对于应用来说提供一个只读副本就可以将一些查询和报表的查询放到只读副本上，虽然说起来容易，做起来可就是还需要考虑一些其他的了。因为HADR中的任何副本都有可能称为Primary副本，尤其是可以自动切换的副本，我们需要让应用程序知道哪个是只读副本，哪个是读写副本，这样才不会把查询发错了方向。在HADR中，可以提供一个虚拟名称VNN，通过虚拟名称连击过去的肯定是读写副本，当发生故障转移的时候，这个名称也会随着数据库的转移移动到响应的服务器上，这样我们就可以确定读写副本的地址。对于只读副本来说，SQL Server 2012的Native Client中提供了一个新的连接字符串参数ApplicationIntent，把这个参数设置为READONLY就可以声明，当前的这个应用是只读的，当然这个只是程序的声明，你必须保证程序里面只会发出只读的查询。只要把这个参数设置好，同时在HADR的数据库上设置好只读数据库路由列表，当带有ApplicationIntent＝READONLY的连接发到VNN的时候，SQL Server 2012会自动将指引连接到配置好的只读副本上，这样应用中的读、写负载就可以分开。同时当发生故障转移的时候，还可以保证这个操作是分开的，如果没有只读路由列表，这个功能实现将相当的复杂。 通过一些测试，我还发现HADR对于连接池需要一些特殊注意的地方。当Primary副本发生故障的时候对于读写操作的连接池将被Clear，毕竟连接的物理服务器已经无法进行读写操作的连接。但是对于READONLY的连接来说，这就是一个问题了，因为连接池里缓存的连接并没有失效，执行只读操作的Secondry副本依然可以工作，对于连接池来说连接就不会被Clear，这样就可能出现读写／只读操作都在一台机器上执行的情况。对于这种情况来说需要实用连接字符中Connection Lifetime或者Load Balance Timeout关键字，当一个连接被Close之后Pool将对比当前时间及该连接的创建时间，如果大于该参数，将把该连接抛出连接池，否则还放到连接池里面。通过适当设置这个参数就可以解决问题，对于一些性能敏感的应用来说尤其重要。 这些功能需要SQL Server Native Client支持，如果你的程序是用ADO.NET你还需要 KB2544514