升级理由一：数据分区

只有到了2005 版本SQL Server才拥有了真正的表和索引数据分区技术。这个技术一下子使SQL Server数据库从“青壮年”成长为成熟的企业级数据库产品，是一个里程碑性质的标志。数据分区技术极大加强了表的可伸缩性和可管理性，使得SQLServer 处理海量数据的能力有了质的飞跃，是我认为最值得升级的一个理由。

数据库随着硬件和业务的发展变得越来越大。五年前大多数数据库还不过是十几个GB大小，很少超过TB级别的。现在几百个GB大小的数据库系统随处可见。如果没有数据分区技术而想对大数据库进行高效管理是很困难的。SQL Server 2005以前版本的一个问题是随着时间的推移数据库越来越大，备份需要的空间越来越多，如何处理数据库中的历史数据是很棘手的事情。有些客户可能会使用DELETE语句定期定量删除大表中的历史记录，如在每个周末备份数据库后删除一个星期以前的所有数据。但是如果表有上千万行十几个GB 大小，那么使用DELETE语句删除数据库中上万行或高达20%数据的话，其性能很差。如果是在7 × 24小时运行的联机系统做这样的数据维护操作那么还会引起比较严重的阻塞问题。另外有些客户针对这个问题直接在方案设计上下功夫，比如按照年份月份星期设计表，然后定期把一些过时的历史数据表（注意是“表”）备份并DROP掉，使得数据库大小以及系统性能都能保持相对稳定。但是这种方法有一个弊端，即应用程序必须做相应的配合根据不同的时间访问对应的表，增加了数据库管理以及数据库访问逻辑的复杂性。

大表还容易带来性能问题。你也许会想到SQL Server 2000中的本地分区视图或分布式分区视图技术。是的，SQL Server2000 中的确已经有分区视图的概念，从SQL Server 7.0开始就有了。可惜分区视图的一个令人讨厌的地方是其管理、设计和开发比较困难，特别是分布式分区视图。如如何更新分布式视图就是个难题。所以尽管一个设计良好的分区视图系统会有很不错的性能改善，却因为繁琐的配置，管理和开发使得其没有在实际中得到充分应用。

现在，SQL Server 2005 引入了真正的数据水平分区技术，上面讨论的数据库增长问题和性能问题就迎刃而解。这个进步绝对不是一小步。数据库的大小不再是个问题。你可以根据字段值的范围将表和索引划分为多个分区从而可以轻松管理一个几个TB大小的数据库系统。无论数据如何增长，你都可以使用分区技术使得数据库大小保持相对稳定。其中特别值得称赞的地方是SQL Server 2005 中分区的管理和使用非常简单。分区的删除，添加，拆分、合并和移动，以及分区的数据装载等管理都非常容易。你可以对单独的分区进行维护而不是整个表。如果你需要大量装载数据，那么你可以先把数据并行的装入到一个新分区当中，建立索引，然后把该分区合并到当前分区中来。这个动作需要的时间极短。如果你需要删除历史数据，假设你已经设计好了历史数据分区，那么你仅仅需要把该分区移除即可，几乎可以一瞬间完成。分区也使得大型表的并发访问性能得到改善，特别是有多个CPU的数据库系统。那些需要交叉访问大量数据的查询将从分区技术中获益不少。



升级理由四：快照隔离



你还在为系统出现的阻塞（blocking）或死锁（deadlock）现象苦恼吗？快试试SQL Server 2005 中的快照隔离吧。通过行版本（row versioning）控制技术，SQL Server 2005 除了原来支持的四种事务隔离级别（脏读、提交读、可重复读、可串行读）外新增了一个快照（SNAPSHOT）隔离级别，有可能使阻塞或死锁成为历史。SQL Server在TEMPDB中存放不同版本的数据行，select 语句读取这些不同版本的行，读操作不阻塞写数据，写操作也不阻塞读操作，这样那些由于读/ 写争用导致的大量死锁的系统将从中获得无穷益处。如果你的系统复杂难优化，那么升级到SQL Server 2005 试试快照隔离级别，也许会有意想不到的效果。



SQL Server 2005中的快照隔离可细分为两种即READ_COMMITTED_SNAPSHOT和ALLOW_SNAPSHOT_ISOLATION。建议大家多使用前者，因为已提交读隔离可用于大多数现有应用程序，而不需要进行任何更改，其占用的TEMPDB空间也少。可以预见如果使用快照隔离级别，那么需要特别关注TEMPDB的大小和性能。你也许需要把TEMPDB放在有足够空间的单独磁盘上以提高性能。






升级理由五：数据库镜像



对于那些要求高可用性的用户来说，数据库镜像也许是考虑升级的唯一理由。SQL Server 2005的前版本在高可用性方面提供了故障转移群集（Failover Cluster）和Log shipping方案。群集方案的一个好处是在一台机器发生问题时它可以提供极快的故障转移能力，在备份服务器上联机数据库，应用程序只需重新连接即可。群集方案的一个缺点是数据库放在共享盘上，有单点失效这个缺点，一旦共享盘失败将导致整个系统崩溃。所以群集方案一般都要结合严紧的备份方案一起使用。而logshipping系统有一个时间上的延迟，且如果日志备份很大，传送速度也是个问题。SQL Server 2005引入的数据库镜像可作为故障转移群集或Log shipping 的替代或补充方案来提高数据库的高可用性。镜像的主要优点是它比前两者更容易管理，没有群集的单点失效缺点,也没有log shipping 的时间延迟。镜像服务器可以放在很远的地方，提高了作为备份服务器的高可用性。


数据库镜像需要两台或三台服务器。主服务器通过传送事务日志中的每个事务到镜像服务器来进行数据同步。每当数据库commit一个事务，该事务就会被同步到镜像服务器。如果事务安全设置为FULL，传送操作将为同步操作。同步操作可以确保将提交的事务提交给两个服务器，但可能会增加事务提交的时间。如果事务安全设置为OFF，操作将为异步操作。事务会在不等待镜像服务器的情况下提交，这将不影响主服务器事务的提交时间，但不能确保镜像也提交了该事务，所以在出现故障那一刻有可能有部分日志丢失。对于需要严格同步数据的镜像系统可以采取同步模式。而仅仅希望有个备份服务器又不影响性能的情况下可以使用异步模式（高性能模式）。无论那种模式，一旦主服务器出现问题，你可以手动实现故障转移或配置系统实现自动故障转移。



升级理由七：全文搜索增强




相对前版本SQL Server 2005中性能提升最多的部分当数全文检索。SQL Server 2000 中的全文本检索和SQL Server 7.0中的差别不大，处于能用的水平。在SQL Server 2000中使用全文检索一个最大的痛苦是建立全文索引的性能不好，需要的时间太长，特别是在表很大的情况下。一个几千万行数据的表也许需要数个小时到数天时间才能完成全文索引的建立。SQL Server 2005全文检索在开发的时候就集中于三点：性能，集成，和可扩展性。据开发小组人员的简单测试，原来在SQL Server 2000中建立全文索引需要14天的表，现在只需要几个小时！几乎有上百倍的性能提升，只能用“惊异”来形容。其相关的全文检索语句也有30％～50％甚至更高的性能提高。性能方面的提高得益于全新设计的全文检索引擎。其中关键的一点设计是全文检索引擎现在使用共享内存和SQL Server 进行数据大规模并发交互，而不是原来基于逐行的方式，使得性能上了好几个数量级。



除了性能，SQL Server 2005 中的全文索引的集成性也大大加强。在SQL Server 2000 中很难对全文检索进行备份。一旦有数据库恢复或移动，你得重新重建索引。对于几百个GB的数据库，重建索引几乎是不能接受的恶梦。现在终于可以和数据库一起备份和恢复全文索引了。你不再需要在恢复数据库后重建全文索引了！恶梦终于成为历史。除了可以备份外，你也可以方便的改变全文索引的磁盘位置。你甚至可以在一个热备机器上把全文索引建立好，然后copy 这个索引到生产服务器上使用。




升级理由十：异步处理能力



SQL Server 2005 通过引入全新的Service Broker 提供了革命性的异步处理能力。Service Broker提供了一个功能强大的异步编程模型。它为数据库应用程序增加了可靠、可扩展、分布式异步功能异步编程，允许程序仅仅在资源可用时才去执行占用大量资源的任务，以此来缩短响应时间，提高吞吐量。在我看来，Broker的最大好处一是异步执行能力，提高了可伸缩性，二是可靠执行，三是集成于数据库中，备份数据库就备份了broker 的消息队列。SQL Server 2005 中的查询通知就是基于Service Broker的应用。你可以使用查询通知功能来发送一个命令到SQL Server请求在查询结果发生变化时接收SQL Server的通知。这样就可以只有在程序以前检索的结果发生变化时，才需要重新查询数据库。一个可以预见的应用是在使用缓存的Web 站点中。Web站点首先发送语句到数据库服务器，获得数据，缓存到本地，然后只有在收到查询通知的时候才清理缓存，重新查询数据。这个机制避免了重复轮询SQL Server，大大减轻了服务器的负载，也提高了Web 站点的伸缩性。