我们推荐本文的读者已经阅读并且理解以下的文章：
◆使用一个Microsoft SQL Server 2000数据仓库中的分区- http://msdn.microsoft.com/library/default.asp URL=/library/techart/PartitionsInDW.htm
分区的好处
当组织中的数据库向上扩展并且包含了大量的数据时，非常关键的是保持其高可用性并同时适应对小的数据库维护窗口的需要。这些需求使得分区成为对于超大型数据库而言的一个量身定制的技术。分区技术所强调的关键问题是——通过将非常大的表分解成相对较小的分区从而使诸如数据导入，老化以及存档等重要任务的管理更易于进行。Microsoft SQL Server通过在SQL Server 7.0/2000中的分区视图以及在SQL Server 2005中添加的对分区表的支持提供了分区技术。
在 SQL Server 7.0/2000中的分区技术
SQL Server 7.0通过分区视图引入了对分区技术的支持。在SQL Server 2000中，这一功能进行了增强支持了可更新的分区视图。当事实表可以被自然的分割或者根据数据范围划分成单独的表时，对于关系型数据仓库而言分区视图技术是再合适不过的了。分区视图的基表可以被UNION来表示成一个统一的数据集。分区视图大大降低成本应用程序的复杂性，原因是物理实现被从应用程序数据访问方式中抽象了出来。
在SQL Server 2000中，分区视图可以被扩展到包括分布式分区视图，从而启用跨多个服务器/实例的数据库联合。有关分布式分区视图的讨论超出了本文的范围。对此更详细的讨论，请参阅微软开发人员网络（MSDN）上的“分布式分区视图”，地址是：http://www.microsoft.com/sql/evaluation/features/distpart.asp!href(http://www.microsoft.com/sql/evaluation/features/distpart.asp.
在SQL Server 2005中的分区技术
在SQL Server 2005中通过使用表和索引的分区，可以降低在使用分区视图管理非常大的数据库时的复杂性。SQL Server 2005提供了用数据行作为最小的分区单位的水平范围分区功能。可以被分区的对象有：
◆基表
从SQL Server 2000的分区视图迁移到 SQL Server 2005 分区表/索引
一个现存的基于单个巨表或者分区视图的应用程序可以被重构或者迁移到一个基于分区的SQL Server 2005解决方案。要作出是重构还是迁移应用程序的决定，必须详细分析在性能，可管理性，以及可用性方面存在的需求。
一个将SQL Server 2000的分区视图迁移到SQL Server 2005分区表的简单路径将包括以下步骤：
◆创建一个分区函数和架构以确定每个分区的分界点和物理存储位置。分界点应当和分区视图的基表的差不多
索引
在把数据导入到一个关系型数据仓库后，一般就要创建索引来为用户查询提供支持。在对关系型数据仓库体系结构造成影响的各个要素中创建和维护索引扮演了主要角色。
在没有索引时对事实表的查询性能通常比较差。对于使用单个巨大事实表的情况，一个最佳的解决方案是删除所有的索引，导入数据，然后重建索引。这种方法导致可用性的降低并且有一个不断增长的维护窗口，当表的大小增长到一定程度时这种方法可能就不太现实了。
在SQL Server 2000中当在基表上创建索引时，分区视图有效的处理了这个问题。SQL Server 2005支持在单独的分区上重建和重组索引，因而便于更好的管理分区索引。
数据老化
老化的数据被访问的频率比新的数据低一些。与日俱增的法律和规定需要业务保证老化的数据在线并能够被立即访问到。因而，在维护现有的数据的高可用性以及方便快速导入新的数据的同时有效的管理老化的数据对于一个企业是非常关键的。数据老化可以通过一个滑动窗口来有效的处理。假如数据被分区了，一个滑动窗口的实现就成为了可能。要查看更多的细节，请参阅本文后面的“滑动窗口实现”
数据存档
对于一个几T规模的数据仓库的成功实现并不以构建一个良好性能以及线性扩展的系统而结束。它也依赖于对一个高度可用的系统的维护。
假如数据被分区了，在SQL Server中的零散备份就可以实现。在SQL Server中的零散备份以及还原操作为分区的管理提供了更大的灵活性。零散备份备份意味着单个的分区，在被限制到它们自己的文件组时，可以被单独的备份和还原而不会影响整个数据库。在一个简单恢复模型中为了零散备份可以工作文件组必须设置为只读模式。在使用大容量日志恢复模型或者完全恢复模型的情况下，有必要备份事务日志-这样做主要是为了成功的还原文件组。关于这些限制的更多细节，请参阅在SQL Server 联机丛书中的“备份(Transact-SQL)”
查询性能
专用的查询是关系型数据仓库解决方案的一个主要部份。应用程序的特点以及查询所产生的结果的性质对于关系型数据仓库的分区有着极大的影响。例如，假如查询中有一个对应到分区键的筛选键，与对单个巨表进行的同样查询相比有更快的响应速度。这是因为对分区的使用促进了并行操作的使用并且在查询中的分区键意味着对数据的剪切更容易了。
滑动窗口实现
滑动窗口是影响对关系型数据仓库分区的一个关键要素之一因而值得用上一个单独的部份对其具体实现的细节进行讨论。
滑动窗口的场景包括将新的分区滑动进去以及将老化的分区从分区表或者视图滑动出来。当老化的数据存档时新的数据就可以用来让用户查询了。在滑动分区时的关键是最小化down机时间。
老化的数据可以被存档并且可以通过还原相应的备份在必要时取回，或者它也可以被移动到一个更低持久性，但更大I/O承受能力的始终可用以进行用户查询的子系统。
下面的图表展示了一个来自我们的测试场景的滑动窗口具体实现。在我们的测试场景中，从分布在全国的商店那里收集与消费者相关的销售数据。数据被导入，纯化，以及聚合来为商业决策提供支持。在我们的测试场景中，一个分区逻辑的代表了一周的有效数据。当前，八周的有效数据被标识为活动的。活动的数据比老化的数据的查询频率高很多。当有新的数据进来，老化的数据就会移出。这儿有一条业务规则表明老化的数据应当保持在线但是应当存储在一个经济有效的I/O子系统中。
图表2：滑动窗口方案
在SQL Server 2000中，滑动窗口可以使用分区视图来实现。缺点是分区视图必须被重新绑定来包括进在UNION视图中的新生成的数据。重新绑定需要一个元数据锁并且可能会被任何对现存视图或者基表的访问所阻塞。
通过对使用Transact-SQL语句将分区交换进和交换出的支持SQL Server 2005提供了一个对滑动窗口方案的更佳实现。交换分区需要在分区表上放置一个架构锁。当没有其它的进程在分区表上获取了一个表级别的锁时分区可以被交换进和交换出。假如分区被其它的进程使用或者假如其它的进程已经在分区表上获取了一个表级别的锁，交换分区的构建进程将会等待直到其它进程已经释放了锁。分区交换是一个对元数据的操作因而非常快速。
下面的步骤可以用来在SQL Server 2005中使用分区表实现一个滑动窗口方案：
◆创建分区函数，架构以及带有适当分界点和关联文件组的表。然后按照下面描述的四个步骤来执行初始导入
交换分区的最佳实践
只有当目标表或者分区是空的时滑动窗口方案才工作。例如，假如一个分区“P”属于分区表“PT”，它必须被交换出到表“T”，随后目标表“T”必须被清空。类似的，当将表“T”交换进分区表“PT”的分区“P”，目标分区“P”应当是空的。
当跨分区的数据移动被最小化时，滑动窗口方案工作最佳。下面的代码定义了分区函数和分区架构。当在这个分区架构上创建一个表时，分区表将会包括三个分区。第一个分区将会包含带有<=200401的键值的数据；第二个带有>200401 且 <=200403的键值；第三个带有>200403的键值。
结论 本白皮书讨论了影响分区的因素，以及对于设计分区可使用的两个主要策略的正反两面的对比。这里所提供的信息可能会对通过分区更有效的管理你的关系型数据仓库有所帮助。 有关的更多信息，请访问:http://www.microsoft.com/sql/ 本文档展示了SQL Server 2005的一些与关系型数据仓库分区的相关特殊的功能。需要更多的信息，请参阅： ◆SQL Server 2005联机丛书提供了一些关于这个主题的有价值的信息，并且它可以作为使用SQL Server 2005实现数据分区的一个不错的起点。 转换性能 在我们的测试中，批量导入的过程后面跟着一个转换过程。转换过程包括将源数据和维度表联接在一起，其目的是为了使用提取的维度键值来填充目标仓库。下面是一段在我们的测试场景中使用的示例代码：
|
