41068.htm

一本很基础的SQL讲解

<P>以下部份阐述了SQL Server 2005中分区功能的优势并提供了将分区表迁移到SQL Server 2005的策略。</P>
<P><STRONG>在SQL Server 2005中分区的优势</STRONG></P>
<P>在SQL Server 2005中的表和索引的分区功能通过将其分解为更易管理的分区大大方便了对超大型数据库的管理。这一部份涉及了一些在针对关系型数据仓库的使用中分区表相对于分区视图的优势。</P>
<P><STRONG>管理</STRONG></P>
<P>一个使用分区视图的缺点是当你使用它的时候，数据库操作必须对单个的对象执行而不是对视图本身。举个例子，如果一个现存的索引必须被删除并且要创建一个新的索引，这些操作必须在每个相关的基表上执行。</P>
<P>在SQL Server 2005中，诸如索引维护这样的数据库操作是对分区表本身而不是底层的相关分区上进行的，因而在管理索引过程中大大减轻了负担。</P>
<P><STRONG>更好的Parallelism机制</STRONG></P>
<P>在SQL Server 2000中，操作是在单个表上执行的并且数据在一个分区视图的级别进行聚合。来自于基表中的行通过使用串联运算符进行汇集并显示视图。然后再在结果集数据上执行聚合。</P>
<P>在SQL Server 2005中，对分区表执行的查询使用了一个被称为demand parallelism的新的运算符。Demand parallelism受到系统资源和MAXDOP设置的影响。</P>
<P>使用分区表的查询将会比使用分区视图进行的同样查询更快的进行编译。当使用分区视图时查询的编译时间是与分区的数量成正比的，而使用分区表时查询的编译时间不会受到分区数量的影响。</P>
<P>在某些情况下，对分区视图进行查询可能会更好一些。以下描述了这样的情况：</P>
<P>◆当优化器选择使用demand parallelism时，parallelism的最小单位是一个分区。在SQL Server 2005中对一个分区表中的单个分区进行查询的性能可能不太好，原因是parallelism的级数被限制到了1。同样的查询如果对一个分区视图进行可能会好一些，原因是在一个分区内更好的parallelism<BR>◆当分区的数量少于处理器的数量时使用分区视图会更好一些，原因是通过parallelism可以更好的使用处理器资源。当分区的数量大于处理器数量，而数据并不是在分区间平均分布时，对分区表查询的性能可能仍旧不太好<BR>◆当分区中的数据分布不均时使用对分区视图的查询也会更好一些</P>
<P><STRONG>标识一个查询计划中的 Demand Parallelism</STRONG> </P>
<P>下面是一个查询计划的示例，它是由一个加法聚合查询产生的。</P>
<P>划了红圈的部份标明了在查询计划中出现的demand parallelism。嵌套循环运算符左边的子demand parallelism是用分区ID来表示的。嵌套循环运算符右边的子demand parallelism是用分区表自身来表示的。在这张图表中，对于由左边的子demand parallelism所返回的每一个分区ID，一个并行的索引查找运算符对来自对应的分区中的行进行反复扫描。所有在嵌套循环运算符上进行的操作也受到由demand parallelism所建立的并行线程的数量的影响。左边的子demand parallelism表示了仅当分区剪切生效时，也就是当查询通过分区筛选结果时，被查询所影响的分区ID。</P>
<P><A href="/files/uploadimg/20070227/1712310.jpg" target=_blank><IMG height=361 alt="" src="/files/uploadimg/20070227/1712310.jpg" width=450 border=0></A>&nbsp;</P>
<P><STRONG>图表1：标识 demand parallelism</STRONG></P>
<P><A href="/files/uploadimg/20070227/1712311.jpg" target=_blank><IMG height=157 alt="" src="/files/uploadimg/20070227/1712311.jpg" width=382 border=0></A>&nbsp;</P>
<P>#p#</P>
<P><STRONG>从SQL Server 2000的分区视图迁移到 SQL Server 2005 分区表/索引</STRONG></P>
<P>一个现存的基于单个巨表或者分区视图的应用程序可以被重构或者迁移到一个基于分区的SQL Server 2005解决方案。要作出是重构还是迁移应用程序的决定，必须详细分析在性能，可管理性，以及可用性方面存在的需求。</P>
<P>一个将SQL Server 2000的分区视图迁移到SQL Server 2005分区表的简单路径将包括以下步骤：</P>
<P>◆创建一个分区函数和架构以确定每个分区的分界点和物理存储位置。分界点应当和分区视图的基表的差不多<BR>◆在新建的分区架构上创建一个分区表。该表应当指定与分区视图的基表同样的物理结构，包括索引<BR>◆将分区视图的每个基表交换为新建的分区事实表的一个分区。分区架构所关联的文件组必须与被交换进来的表所属的文件组相匹配。另外，要迁移的表必须符合交换提示的要求。举个例子，目标表不能是一个与架构绑定的视图的部件。关于交换提示的要求列表，请参阅SQL Server 2005联机丛书中的“使用分区交换有效的传递数据”</P>
<P><STRONG>影响关系型数据仓库分区的因素</STRONG></P>
<P>对于一个分区的关系型数据仓库的成功实现而言，包括了对数据库增长和易管理性的规划。接下来的部份阐述了影响关系型数据仓库分区的因素以及滑动窗口实现的详细信息。</P>
<P><STRONG>数据量</STRONG></P>
<P>当事实表的大小比较小时，分区只会添加更多的管理复杂性而不会带来更多的价值。事实表的大小是基于应用程序的特点并且由每一种实现方式所决定的。通常用户需要事实表在他们实施分区之前至少有100 GB。</P>
<P><STRONG>数据导入</STRONG></P>
<P>数据导入是一个数据仓库的核心部份。几乎所有的数据仓库都会周期性的处理最近收集的数据。是否成功的管理数据仓库取决于批量导入进程的效率以及导入过程中现有的数据能否继续使用。</P>
<P>在构建你的事实表时有两个选择：</P>
<P>◆建立一个巨大的表，或者 <BR>◆使用分区的方式</P>
<P>使用单个巨表这种方式与使用分区相比会导致较低的可用性，原因是在典型的关系型数据仓库环境中批量导入操作是步进执行的。例如，步进式的批量导入会从对目标表的锁定中获得巨大的好处。当使用单个表时，这样做就会阻止所有其它的用户在表导入的过程中访问它。对于步进导入数据的最佳工作方式是使用一个规划维护窗口。对于使用单个巨表这种方式中批量导入的全面讨论请参阅在<A href="http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/incbulkload.mspx">http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/incbulkload.mspx</A> 上的“SQL Server 2000步进批量导入案例学习”</P>
<P>分区方式让数据被批量导入到单个的分段表中，每一段都代表了一个确定的分区范围。分段表随后被添加到分区视图当中或者被当作一个新的分区交换到分区表中。由于每一个分区逻辑上都是由一个单独的分段表来代表的，因此步进的批量导入不会对任何针对现有数据的查询造成可用性和性能上的影响。 </P>
<P>一个典型的数据仓库解决方案应当包括在批量导入数据的同时进行数据转换的功能。转换包括对源数据的清除和/或者聚合以产生目标库。</P>
<P>一个转换典型情况下是通过使用象微软系统集成服务这样的工具来完成的。如果过程中不需要一个复杂的工作流，用户可以选择使用SELECT/INTO来完成转换。<BR>&nbsp;<BR><STRONG>索引</STRONG></P>
<P>在把数据导入到一个关系型数据仓库后，一般就要创建索引来为用户查询提供支持。在对关系型数据仓库体系结构造成影响的各个要素中创建和维护索引扮演了主要角色。</P>
<P>在没有索引时对事实表的查询性能通常比较差。对于使用单个巨大事实表的情况，一个最佳的解决方案是删除所有的索引，导入数据，然后重建索引。这种方法导致可用性的降低并且有一个不断增长的维护窗口，当表的大小增长到一定程度时这种方法可能就不太现实了。 </P>
<P>在SQL Server 2000中当在基表上创建索引时，分区视图有效的处理了这个问题。SQL Server 2005支持在单独的分区上重建和重组索引，因而便于更好的管理分区索引。</P>
<P><STRONG>数据老化</STRONG></P>
<P>老化的数据被访问的频率比新的数据低一些。与日俱增的法律和规定需要业务保证老化的数据在线并能够被立即访问到。因而，在维护现有的数据的高可用性以及方便快速导入新的数据的同时有效的管理老化的数据对于一个企业是非常关键的。数据老化可以通过一个滑动窗口来有效的处理。如果数据被分区了，一个滑动窗口的实现就成为了可能。要查看更多的细节，请参阅本文后面的“滑动窗口实现”</P>
<P><STRONG>数据存档</STRONG></P>
<P>对于一个几T规模的数据仓库的成功实现并不以构建一个良好性能以及线性扩展的系统而结束。它也依赖于对一个高度可用的系统的维护。</P>
<P>如果数据被分区了，在SQL Server中的零散备份就可以实现。在SQL Server中的零散备份以及还原操作为分区的管理提供了更大的灵活性。零散备份备份意味着单个的分区，在被限制到它们自己的文件组时，可以被单独的备份和还原而不会影响整个数据库。在一个简单恢复模型中为了零散备份可以工作文件组必须设置为只读模式。在使用大容量日志恢复模型或者完全恢复模型的情况下，有必要备份事务日志-这样做主要是为了成功的还原文件组。关于这些限制的更多细节，请参阅在SQL Server 联机丛书中的“备份(Transact-SQL)”</P>
<P><STRONG>查询性能</STRONG></P>
<P>专用的查询是关系型数据仓库解决方案的一个主要部份。应用程序的特点以及查询所产生的结果的性质对于关系型数据仓库的分区有着极大的影响。例如，如果查询中有一个对应到分区键的筛选键，与对单个巨表进行的同样查询相比有更快的响应速度。这是因为对分区的使用促进了并行操作的使用并且在查询中的分区键意味着对数据的剪切更容易了。</P>
<P>#p#</P>
<P><STRONG>滑动窗口实现</STRONG></P>
<P>滑动窗口是影响对关系型数据仓库分区的一个关键要素之一因而值得用上一个单独的部份对其具体实现的细节进行讨论。</P>
<P>滑动窗口的场景包括将新的分区滑动进去以及将老化的分区从分区表或者视图滑动出来。当老化的数据存档时新的数据就可以用来让用户查询了。在滑动分区时的关键是最小化down机时间。</P>