MicrosoftSQLServer中的关系型数据仓库分区策略Word文档下载推荐.docx
《MicrosoftSQLServer中的关系型数据仓库分区策略Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《MicrosoftSQLServer中的关系型数据仓库分区策略Word文档下载推荐.docx（33页珍藏版）》请在冰点文库上搜索。
由于微软必须对千变万化的市场情况做出相应反应，因此本文档不应视为微软的任何承诺，且微软不保证所陈述任何信息在产品发布后的准确性。
本白皮书仅供信息参考。
微软对本文件中的信息不做任何明示或默示保证。
遵守所有适用的版权法律是用户应尽的责任。
下述陈述不限制任何版权，在未获得微软公司明示书面许可的情况下，不得以任何目的复制本文档任何部分或将任何部分保存或引入检索系统、亦不得以任何形式（电子、机械、影印、录制或其他方式）进行传播。
微软在文件所述主题中拥有专利权、专利应用程序、商标、版权或其他知识产权。
除非在微软的任何书面许可协议中明示规定，否则对本文档的提供不得视为对任何专利权、商标、版权或其他知识产权许可的提供。
除非特别声明，本文中描述的示例公司、组织、产品、域名、e-mail地址、徽标、人物、地点以及事件均为虚构的，不应与任何实际的公司、组织、产品、域名、e-mail地址、徽标、人物、地点以及事件有任何的联系。
©
2005微软公司版权所有。
Microsoft和ActiveX是微软公司在美国和其他国家的注册商标或商标。
本文中实际公司和产品的名称可能是其相应所有者的商标。
内容列表
对一个关系型数据仓库进行分区1
关于关系型数据仓库1
分区的好处1
在SQLServer7.0/2000中的分区技术1
在SQLServer2005中的分区技术2
在SQLServer2005中分区的优势2
标识一个查询计划中的DemandParallelism3
从SQLServer2000的分区视图迁移到SQLServer2005分区表/索引4
影响关系型数据仓库分区的因素4
数据量4
数据导入4
索引5
数据老化5
数据存档5
查询性能5
滑动窗口实现5
交换分区的最佳实践8
将数据存储到一个性价比高I/O子系统的技术9
关系型数据仓库的分区策略9
策略I–将一个分区绑定到它自己的文件组9
策略StrategyII–将两个或更多分区绑定到同样的文件组10
哪个策略更好?
10
结论11
附录A:
性能数值12
批量插入性能12
转换性能12
索引构建性能13
数据库备份性能14
老化数据到ATA磁盘14
附录B:
平台列表14
Microsoft软件14
服务器平台14
存储15
主机总线适配卡15
存储管理软件15
附录C:
服务器体系结构15
附录D:
EMCCLARiiON存储15
拓朴16
附录E:
存储隔离17
配置你的存储18
附录F:
脚本18
对一个关系型数据仓库进行分区
以下的部份将会简要的解释关系型数据仓库的概念，为关系型数据仓库进行分区的好处，以及迁移到Microsoft®
SQLServer™2005分区的好处。
关于关系型数据仓库
关系型数据仓库提供了一个广泛的数据来源以及一个用来构建业务智能（BI）解决方案的体系结构。
另外，关系型数据仓库可以为报表应用程序以及复杂且专用的SQL查询所用。
一个典型的关系型数据仓库是由维度表以及事实表组成的。
维度表通常会比事实表小一些并且其中提供了关于解释事实的属性的详细信息。
一个维度的例子是货物，商店和时间。
事实表提供了对商业记录的描述，比如在所有商店中货物销售的信息。
事实表通过最近收集到的数据进行不断的更新。
一个成功的关系型数据仓库解决方案的实现包括细致而长期的规划。
以下列出了在构建一个关系型数据仓库时要考虑的要素：
∙数据量
∙数据导入窗口
∙索引维护窗口
∙工作负载特征
∙数据老化策略
∙存档和备份策略
∙硬件特征
这个文档后面的部份将会有对以上要素的详细讨论。
一个关系型数据仓库在实现时可以采用分区的方法或者一个（巨大）事实表的方法。
对于使用分区还是不分区方式的设计选择主要依赖于前面列出的各个要素。
关系型数据仓库可以从数据分区中获益。
以下部份着重谈到了分区为关系型数据仓库带来的好处。
分区的好处
当组织中的数据库向上扩展并且包含了大量的数据时，非常关键的是保持其高可用性并同时适应对小的数据库维护窗口的需要。
这些需求使得分区成为对于超大型数据库而言的一个量身定制的技术。
分区技术所强调的关键问题是——通过将非常大的表分解成相对较小的分区从而使诸如数据导入，老化以及存档等重要任务的管理更易于进行。
MicrosoftSQLServer通过在SQLServer7.0/2000中的分区视图以及在SQLServer2005中添加的对分区表的支持提供了分区技术。
在SQLServer7.0/2000中的分区技术
SQLServer7.0通过分区视图引入了对分区技术的支持。
在SQLServer2000中，这一功能进行了增强支持了可更新的分区视图。
当事实表可以被自然的分割或者根据数据范围划分成单独的表时，对于关系型数据仓库而言分区视图技术是再合适不过的了。
分区视图的基表可以被UNION来表示成一个统一的数据集。
分区视图大大降低成本应用程序的复杂性，原因是物理实现被从应用程序数据访问方式中抽象了出来。
在SQLServer2000中，分区视图可以被扩展到包括分布式分区视图，从而启用跨多个服务器/实例的数据库联合。
有关分布式分区视图的讨论超出了本文的范围。
对此更详细的讨论，请参阅微软开发人员网络（MSDN）上的“分布式分区视图”，地址是
在SQLServer2005中的分区技术
在SQLServer2005中通过使用表和索引的分区，可以降低在使用分区视图管理非常大的数据库时的复杂性。
SQLServer2005提供了用数据行作为最小的分区单位的水平范围分区功能。
可以被分区的对象有：
∙基表
∙索引（聚簇和非聚簇的）
∙索引视图
范围分区是通过自定义的数据范围定义的表的分区。
用户通过分界值，一个使用文件组映射的分区架构，以及映射到分区架构的表来定义分区函数。
一个分区函数决定了一个表或索引中特定的一行所属于的分区。
每个分区都是用一个通过一个分区架构映射到某个存储位置（文件组）的分区函数来定义的。
对于在SQLServer2005中实现分区的全面讨论，请参阅MSDN中的"
SQLServer2005分区表和索引"
。
以下部份阐述了SQLServer2005中分区功能的优势并提供了将分区表迁移到SQLServer2005的策略。
在SQLServer2005中分区的优势
在SQLServer2005中的表和索引的分区功能通过将其分解为更易管理的分区大大方便了对超大型数据库的管理。
这一部份涉及了一些在针对关系型数据仓库的使用中分区表相对于分区视图的优势。
管理
一个使用分区视图的缺点是当你使用它的时候，数据库操作必须对单个的对象执行而不是对视图本身。
举个例子，如果一个现存的索引必须被删除并且要创建一个新的索引，这些操作必须在每个相关的基表上执行。
在SQLServer2005中，诸如索引维护这样的数据库操作是对分区表本身而不是底层的相关分区上进行的，因而在管理索引过程中大大减轻了负担。
更好的Parallelism机制
在SQLServer2000中，操作是在单个表上执行的并且数据在一个分区视图的级别进行聚合。
来自于基表中的行通过使用串联运算符进行汇集并显示视图。
然后再在结果集数据上执行聚合。
在SQLServer2005中，对分区表执行的查询使用了一个被称为demandparallelism的新的运算符。
Demandparallelism受到系统资源和MAXDOP设置的影响。
使用分区表的查询将会比使用分区视图进行的同样查询更快的进行编译。
当使用分区视图时查询的编译时间是与分区的数量成正比的，而使用分区表时查询的编译时间不会受到分区数量的影响。
在某些情况下，对分区视图进行查询可能会更好一些。
以下描述了这样的情况：
∙当优化器选择使用demandparallelism时，parallelism的最小单位是一个分区。
在SQLServer2005中对一个分区表中的单个分区进行查询的性能可能不太好，原因是parallelism的级数被限制到了1。
同样的查询如果对一个分区视图进行可能会好一些，原因是在一个分区内更好的parallelism
∙当分区的数量少于处理器的数量时使用分区视图会更好一些，原因是通过parallelism可以更好的使用处理器资源。
当分区的数量大于处理器数量，而数据并不是在分区间平均分布时，对分区表查询的性能可能仍旧不太好
∙当分区中的数据分布不均时使用对分区视图的查询也会更好一些
标识一个查询计划中的DemandParallelism
下面是一个查询计划的示例，它是由一个加法聚合查询产生的
划了红圈的部份标明了在查询计划中出现的demandparallelism。
嵌套循环运算符左边的子demandparallelism是用分区ID来表示的。
嵌套循环运算符右边的子demandparallelism是用分区表自身来表示的。
在这张图表中，对于由左边的子demandparallelism所返回的每一个分区ID，一个并行的索引查找运算符对来自对应的分区中的行进行反复扫描。
所有在嵌套循环运算符上进行的操作也受到由demandparallelism所建立的并行线程的数量的影响。
左边的子demandparallelism表示了仅当分区剪切生效时，也就是当查询通过分区筛选结果时，被查询所影响的分区ID，。
图表1.标识demandparallelism
从SQLServer2000的分区视图迁移到SQLServer2005分区表/索引
一个现存的基于单个巨表或者分区视图的应用程序可以被重构或者迁移到一个基于分区的SQLServer2005解决方案。
要作出是重构还是迁移应用程序的决定，必须详细分析在性能，可管理性，以及可用性方面存在的需求。
一个将SQLServer2000的分区视图迁移到SQLServer2005分区表的简单路径将包括以下步骤：
∙创建一个分区函数和架构以确定每个分区的分界点和物理存储位置。
分界点应当和分区视图的基表的差不多
∙在新建的分区架构上创建一个分区表。
该表应当指定与分区视图的基表同样的物理结构，包括索引
∙将分区视图的每个基表交换为新建的分区事实表的一个分区。
分区架构所关联的文件组必须与被交换进来的表所属的文件组相匹配。
另外，要迁移的表必须符合交换提示的要求。
举个例子，目标表不能是一个与架构绑定的视图的部件。
关于交换提示的要求列表，请参阅SQLServer2005联机丛书中的“使用分区交换有效的传递数据”
影响关系型数据仓库分区的因素
对于一个分区的关系型数据仓库的成功实现而言，包括了对数据库增长和易管理性的规划。
接下来的部份阐述了影响关系型数据仓库分区的因素以及滑动窗口实现的详细信息。
数据量
当事实表的大小比较小时，分区只会添加更多的管理复杂性而不会带来更多的价值。
事实表的大小是基于应用程序的特点并且由每一种实现方式所决定的。
通常用户需要事实表在他们实施分区之前至少有100GB。
数据导入
数据导入是一个数据仓库的核心部份。
几乎所有的数据仓库都会周期性的处理最近收集的数据。
是否成功的管理数据仓库取决于批量导入进程的效率以及导入过程中现有的数据能否继续使用。
在构建你的事实表时有两个选择：
∙建立一个巨大的表，或者
∙使用分区的方式
使用单个巨表这种方式与使用分区相比会导致较低的可用性，原因是在典型的关系型数据仓库环境中批量导入操作是步进执行的。
例如，步进式的批量导入会从对目标表的锁定中获得巨大的好处。
当使用单个表时，这样做就会阻止所有其它的用户在表导入的过程中访问它。
对于步进导入数据的最佳工作方式是使用一个规划维护窗口。
对于使用单个巨表这种方式中批量导入的全面讨论请参阅在上的“SQLServer2000步进批量导入案例学习”!
href（
分区方式让数据被批量导入到单个的分段表中，每一段都代表了一个确定的分区范围。
分段表随后被添加到分区视图当中或者被当作一个新的分区交换到分区表中。
由于每一个分区逻辑上都是由一个单独的分段表来代表的，因此步进的批量导入不会对任何针对现有数据的查询造成可用性和性能上的影响。
一个典型的数据仓库解决方案应当包括在批量导入数据的同时进行数据转换的功能。
转换包括对源数据的清除和/或者聚合以产生目标库。
一个转换典型情况下是通过使用象微软系统集成服务这样的工具来完成的。
如果过程中不需要一个复杂的工作流，用户可以选择使用SELECT/INTO来完成转换。
索引
在把数据导入到一个关系型数据仓库后，一般就要创建索引来为用户查询提供支持。
在对关系型数据仓库体系结构造成影响的各个要素中创建和维护索引扮演了主要角色。
在没有索引时对事实表的查询性能通常比较差。
对于使用单个巨大事实表的情况，一个最佳的解决方案是删除所有的索引，导入数据，然后重建索引。
这种方法导致可用性的降低并且有一个不断增长的维护窗口，当表的大小增长到一定程度时这种方法可能就不太现实了。
在SQLServer2000中当在基表上创建索引时，分区视图有效的处理了这个问题。
SQLServer2005支持在单独的分区上重建和重组索引，因而便于更好的管理分区索引。
数据老化
老化的数据被访问的频率比新的数据低一些。
与日俱增的法律和规定需要业务保证老化的数据在线并能够被立即访问到。
因而，在维护现有的数据的高可用性以及方便快速导入新的数据的同时有效的管理老化的数据对于一个企业是非常关键的。
数据老化可以通过一个滑动窗口来有效的处理。
如果数据被分区了，一个滑动窗口的实现就成为了可能。
要查看更多的细节，请参阅本文后面的“滑动窗口实现”
数据存档
对于一个几T规模的数据仓库的成功实现并不以构建一个良好性能以及线性扩展的系统而结束。
它也依赖于对一个高度可用的系统的维护。
如果数据被分区了，在SQLServer中的零散备份就可以实现。
在SQLServer中的零散备份以及还原操作为分区的管理提供了更大的灵活性。
零散备份备份意味着单个的分区，在被限制到它们自己的文件组时，可以被单独的备份和还原而不会影响整个数据库。
在一个简单恢复模型中为了零散备份可以工作文件组必须设置为只读模式。
在使用大容量日志恢复模型或者完全恢复模型的情况下，有必要备份事务日志-这样做主要是为了成功的还原文件组。
关于这些限制的更多细节，请参阅在SQLServer联机丛书中的“备份（Transact-SQL）”
查询性能
专用的查询是关系型数据仓库解决方案的一个主要部份。
应用程序的特点以及查询所产生的结果的性质对于关系型数据仓库的分区有着极大的影响。
例如，如果查询中有一个对应到分区键的筛选键，与对单个巨表进行的同样查询相比有更快的响应速度。
这是因为对分区的使用促进了并行操作的使用并且在查询中的分区键意味着对数据的剪切更容易了。
滑动窗口实现
滑动窗口是影响对关系型数据仓库分区的一个关键要素之一因而值得用上一个单独的部份对其具体实现的细节进行讨论。
滑动窗口的场景包括将新的分区滑动进去以及将老化的分区从分区表或者视图滑动出来。
当老化的数据存档时新的数据就可以用来让用户查询了。
在滑动分区时的关键是最小化down机时间。
老化的数据可以被存档并且可以通过还原相应的备份在必要时取回，或者它也可以被移动到一个更低持久性，但更大I/O承受能力的始终可用以进行用户查询的子系统。
下面的图表展示了一个来自我们的测试场景的滑动窗口具体实现。
在我们的测试场景中，从分布在全国的商店那里收集与消费者相关的销售数据。
数据被导入，纯化，以及聚合来为商业决策提供支持。
在我们的测试场景中，一个分区逻辑的代表了一周的有效数据。
当前，八周的有效数据被标识为活动的。
活动的数据比老化的数据的查询频率高很多。
当有新的数据进来，老化的数据就会移出。
这儿有一条业务规则表明老化的数据应当保持在线但是应当存储在一个经济有效的I/O子系统中。
图表2.滑动窗口方案
在SQLServer2000中，滑动窗口可以使用分区视图来实现。
缺点是分区视图必须被重新绑定来包括进在UNION视图中的新生成的数据。
重新绑定需要一个元数据锁并且可能会被任何对现存视图或者基表的访问所阻塞。
通过对使用Transact-SQL语句将分区交换进和交换出的支持SQLServer2005提供了一个对滑动窗口方案的更佳实现。
交换分区需要在分区表上放置一个架构锁。
当没有其它的进程在分区表上获取了一个表级别的锁时分区可以被交换进和交换出。
如果分区被其它的进程使用或者如果其它的进程已经在分区表上获取了一个表级别的锁，交换分区的构建进程将会等待直到其它进程已经释放了锁。
分区交换是一个对元数据的操作因而非常快速。
下面的步骤可以用来在SQLServer2005中使用分区表实现一个滑动窗口方案：
∙创建分区函数，架构以及带有适当分界点和关联文件组的表。
然后按照下面描述的四个步骤来执行初始导入
∙创建代表单个分区的表
∙分别地填充表
∙向表中添加约束检查来将数据值绑定到对应的范围上并且创建适当的索引。
SQLServer2005在创建分区表后创建初始索引时提供了一个额外的选项
∙将新近填充好的表交换进分区表的每一个分区
∙在初始导入之后，在一个表中任何新导入和交换进来的数据都不会成为分区表的一部份。
一旦数据已经就绪，在设置好适当的分界点后表就可以被交换进分区表
∙类似的，老化数据可以被移动到更经济有效的I/O子系统但是仍然在线并保持可用状态
接下来的部份涉及了一些针对分割分区表以及将分区交换进分区表的最佳实践。
交换分区的最佳实践
只有当目标表或者分区是空的时滑动窗口方案才工作。
例如，如果一个分区“P”属于分区表“PT”，它必须被交换出到表“T”，随后目标表“T”必须被清空。
类似的，当将表“T”交换进分区表“PT”的分区“P”，目标分区“P”应当是空的。
当跨分区的数据移动被最小化时，滑动窗口方案工作最佳。
下面的代码定义了分区函数和分区架构。
当在这个分区架构上创建一个表时，分区表将会包括三个分区。
第一个分区将会包含带有<
=200401的键值的数据；
第二个带有>
200401且<
=200403的键值；
第三个带有>
200403的键值。
CREATEPARTITIONFUNCTIONSALES_MONTHLY_PARTITION_FUNCTION（INT）
ASRANGELEFTFORVALUES（200401,200403）
GO
CREATEPARTITIONSCHEMESALES_MONTHLY_PARTITION_SCHEMEASPARTITIONSALES_MONTHLY_PARTITION_FUNCTIONALLTO（[PRIMARY]）
CREATETABLEt
（
col1INT
）ONSALES_MONTHLY_PARTITION_SCHEME（col1）
当使用ALTERPARTITION函数的分割功能添加一个值为200402的新分界时，行会在相应的分区间移动。
ALTERPARTITIONFUNCTIONPARTITION_FUNCTION（）
SPLITRANGE（200402）
通过在原始的位置删除行以及在新的位置添加行，行可以在分区间移动。
和此次交换有关的分区在这一期间是不可访问的。
在这个例子中，新建的第二个分区将会拥有在键值范围>
=200402内的数据。
带有对应键值的数据被从第二个分区中删除并且插入到新的分区。
新的分区（>
=200402）以及第三个分区（>
200402且<
=200403）在这一期间是无法访问的。
在我们的消费者场景中，新的数据是通过在活动的结尾处分割分区函数来添加的。
老的数据是通过在老化的结尾处合并分区函数来删除的。
这种实现滑动窗口的方式消除了在交换进和交换出分区时的跨分区的数据移动，也就是说，新的数据被批量的导入到一个表中并且随后通过在活动的结尾处分割它来交换进分区表，具体如下所示：
ALTERTABLEN
升级会员 