SQL Server 2005的负载均衡

  SQL Server 2005仍然不直接地支持负载均衡——但是它为以前SQL Server版本中可用的所有负载均衡方法提供了令人激动的改善和支持。
  目录
　　1、端到端拓扑的事务性复制
2、表分割
3、备份和重新存储上的改善(片段式重新存储)
4、数据库镜像和快照
　　端到端拓扑的事务性复制
对端到端(P2P)的拓扑结构上的事务性的复制加强了支持。
SQL Server 2000支持双向的复制，这就可以让两台服务器同时对彼此发布和订阅数据。服务器可以更新同一个共享数据，但是在这样的拓扑中你被限制在两台服务器上。
P2P的拓扑结构支持无限的发布服务器，他们彼此之间可以互相交换事务。当然，当参加的发布者的数量增加之后，事务性的延迟也就更大了。虽然在你的拓扑结构中对节点的数量没有理论上的限制，但是只有在某个确定的数字之下才可以提供可接受的性能。微软推荐低于12个节点，以保证性能的优化。
　　无论怎样，拓扑都是的一个巨大进步：现在，多端点服务器可以更改数据，并且向其他的发布者复制事务。这就是说，订阅服务器不再被限制在主要的报告环境中。你可以通过事务性负载全球共享的方式将服务器分布开来。当用户的数量增加的时候，只要简单地向这个群体中添加服务器即可。
　　除了将负载分布之外，这个拓扑结构还增加了可用性。如果任何一个点的服务器不可达，则池中其它的服务器就会共享这个负载，因为每个服务器都有其它所有服务器上可获得的全部数据集合。
　　以下的表列出了使用拓扑结构来进行负载均衡的优点和缺点。       

对等拓扑的优缺点
优点	缺点
·                                 所有参与的服务器都有完全的数据集合。 用户可以连接到任何一个点的服务器上来读取或者修改数据。 由于负载在服务器之间进行了均衡，读取的性能得到了很大程度的改善。	多个服务器会修改同一个数据，这会导致冲突。事务性复制不支持具有超出常规的冲突解决方案。你必须找出解决或者防止潜在冲突的解决方法。 当端点服务器的数量增加的时候，性能会大幅下降。 写活动重复，因为所有的数据都在同一台服务器上。

　　注意：复制在处理数据库计划无缝修改方面也进行了加强。在以前的发布中，修改复制的对象的计划需要关机时间。但是在中就不是这样的情况了。
表分割
　　分布式分区视图的工作方式在中与以前版本中的工作方式相同。然而，还支持表分区，这可以让你通过分布读写负载到多个磁盘或者磁盘阵列)上来改善性能。
　　对于分区表，你必须识别分区要用的是哪一个卷，还有每个分区的范围。例如，一个标识字段的数值可以定义分区范围;一个分区内可以允许从到百万的数值，在第二个分区内可以允许百万到百万，以此类推。分区范围可以通过分区函数来指定.然后你还必须创建一个分区计划来讲分区函数中定义的每个范围值映射到分离的文件组上去。每个文件组都可以放在不同的磁盘上。
　　以下的表给出了表分区的优缺点：

表分区的优缺点
使用分区计划和函数很容易建立 简化了对大表的维护(有几十亿行记录) 允许为每个分区创建独立的索引	分区字段支持的数据类型有一定限制 必须为每个单独的分区建立一个表都，但是你可以在多个表上重复使用同一个分区函数。 表分区可以让你将负载扩展到磁盘上去。然而，所有的数据都必须被同一个服务器管理。如果你的性能瓶颈与CPU或者内存有关，那么这种方法看起来不是你最好的选择。

备份和重新存储方面的改善(片段式重新存储)
的备份和重新存储特性没有很大的改变，但是微软确实添加了一些新的函数来允许用户比以前更快地访问被重新存储的数据库。
现在支持片段式数据库重新存储。片段式重新存储可以让你首先重新存储主要的文件组，然后将数据库启动，处于在线状态。然后，可用的第二个文件组也可以被重新存储。只要第一文件组被重新存储了，那么用户就可以连接到数据库了。其他的文件组可以继续重新存储，与此同时，数据库也可以为查询和事务提供服务。正在重新存储的文件组标记为离线。　　假设你有一个100GB的数据库，其中的75GB是历史性数据，很少被访问到。你可以将这些历史性数据放在它自己的文件组里面，然后让那些频繁访问的数据放在另外一个文件组。如果你将最近的数据放在第一文件组中，那么你就只需要重新存储25GB的数据就可以让用户连接到你的数据库上。然后你再重新存储其它的保留历史性数据的文件组。　　以下的表列出了这个备份和重新存储解决方案的优缺点：

备份和重新存储的优缺点：
实现和维护非常简单 允许对报告数据库进行读取和写入	不能提供最新的数据 在重新存储的时候，数据库不能访问。这就意味着报告无法生成。

数据库镜像和快照
引入了数据库镜像的概念来帮助获得高可用性。特别提醒的是，只要它正是发布了，数据库镜像就可以在上使用。然而，只有到SQL Server 2005 Service Pack 1才会支持镜像，暂定在2006年年初发布。
　　从本质上来说，镜像的工作方式与日志传输类似。
、事务日志记录可以应用在两个服务器中的数据库文件上。与日志传输不同的是，数据库镜像不需要你备份事务日志，也不需要拷贝备份到备份服务器上。
、数据库镜像连续两次写入数据。与日志传输不同，备份的数据库必须保持在非恢复的模式中，这可以防止对数据的访问，即使是只读的方式。然而，镜像允许对备份数据库进行快照。
　　数据库快照是中引入的另一项特性。快照是某一个时间点上的数据库的克隆。只要你的镜像的数据库进行了快照，你就可以让用户查询快照。快照的生成通常只需要几秒钟，因为它实际上在这个过程中拷贝任何数据。因此，要把负载分布到你的主服务器和备用服务器上，你可以将你的数据库镜像，然后阶段性地对备份服务器进行快照。你还可以使用快照在主服务器上进行报告。
　　以下的表列出了数据库镜像和快照的优缺点：

数据库镜像和快照的优缺点
从镜像数据库中生成快照非常快 数据是最新的，因为它是持续写入镜像 在同一个数据库上可以生成多个快照	快照提供了对数据的只读访问. 拥有快照，会增加服务器的负担，对性能产生负面影响 如果你正好对镜像服务器进行错误恢复，那么事务和报告活动都会指向同一个服务器（但是不同的数据库）。