用SQL Server 2005构建高性能的数据仓库（一）

关注

转载最新推荐文章于 2026-04-01 02:42:06 发布 1.5k 阅读 AI 写同款· GEO 优化 ›

sql server下的数据仓库的构建 SQL Server2008/R2 下的数据仓库的构建本文详细介绍在SQL Server下如何做数据仓库的构建和如何利用数据仓库进行有效的分析，假设读者已经具备相关的理论知识，由于在SQL Server上都是实践过程，因此主要以截图来展示，这样做的好处是读者可直接按照该步骤进行操作，由于之前作者是写在word中的，因此直接截图，好了，话不多说，直接开始。上面的全部内容是利用数据仓库... 阅读详情

http://hi.baidu.com/susan_jony/blog/item/e732e0deef04645cccbf1aa2.html

摘要：本文主要讨论当架构一个很大的、高性能的数据仓库，特别是对那种无法预知有多少查询量的系统时要考虑的一些东西。这个讨论包括SQL Server 2005的一些新的特性以及在使用这些特性的时候需要考虑的一些东西。它同时也包括了创建或存储一个聚合的数据集来使得主流的查询和报表更加容易。

一．介绍

有一些具有访问数据权限的“超级用户”已经学会了专业的Transact-SQL。SQL Server 2005 报表服务（SSRS）中的报表构造器的便利性扩展到了强大的Transact-SQL查询的创建，使得更多的用户使用它时更加容易。他们这种消耗系统资源的能力是无法超越的，在保持一致的性能方面对数据库管理员（DBA）构成了挑战。但是，当SQL Server的分析服务（SSAS）被提及的时候，需要用不可预知的方式访问数据的用户可能感到他们的查询效率受到阻碍。因此，你怎样使得你的商业用户查询到他们所需要的东西，也跟给予他们性能很好地查询以及始终满足服务级别的协议（SLA）一样重要。

在过去的几年中，大量的信息都是围绕数据仓库和商业智能（BI）开展的。很大一部分信息聚焦于构建一个数据仓库或者数据市场来满足或者超过与制定策略决定相关的商业目标。随着SQL Server 2005的发布，1000GB范围内的相关数据仓库的实现在它附加的功能中提供了支持。这份白皮书说明了在SQL Server 2005上用一个性能的视角架构一个相关的数据仓库或者数据市场时包括的最佳实践。

在这份白皮书中也讨论了围绕硬件选择方面的一些显而常见的问题、SQL Server实例和数据库配置和table/index的设计，它还介绍了为了交付一个数据市场或数据仓库来平衡查询性能时的整体的策略。

相关的数据仓库的性能常常在更新数据库和查询时感觉到。更新操作需要对新的数据进行更多的提取、转换和载入。DBA有责任尽可能更有效率的设计和维护数据库。查询操作也以很多种方式出现，例如终端用户的查询、报表服务等。既然分析服务在各种查询中是最可预测的，白皮书主要聚焦于对相关数据库仓库的直接的查询。

在继续讲之前，我们对已提及到的一些东西做一些假设。用来存储信息的一些相关的数据仓库通常是非常大的。数据仓库和数据市场常常被可替换的使用。但是，数据仓库更多的跟信息在所有的企业的信息存储有关。这些数据被清空，并且是以一种正常的方式和很少的直接查询。相反，它常常使用一致的数据源来为一种或多种面向主题的数据仓库直接的服务用户。在数据市场中的数据虽然能够以各种方式来设计，但是常常是用一种空间的方式。在工业中，“数据市场”结合在一起变成了“数据仓库”。

但是，从一致性方面考虑，在这份白皮书中，我们使用“数据仓库”这个概念作为包含数据市场的一个通用的概念。

这份白皮书假设读者已基本熟悉数据仓库的概念、空间建模、SQL Server 2005表的分离以及索引化的视图。其中很多的查询结果比较测试是在项目REAL的数据库中进行的。项目REAL是一个在SQL Server 2005上的真实的数据仓库的参考实现。

二、创建一个可靠的基础

创建一个高性能的数据仓库的关键是懂得那些数据，以及知道用户是怎样查询数据库的。后者常常有着很大变化，因此很有必要根据查询模式的改变来持续的进行一些调整。有一些基础组织的决定对系统的性能产生巨大影响。

1. 硬件方面的考虑

硬件方面的决定常常做得早于系统的任何一个重要的方面。为相关的数据仓库选择硬件是很具有技巧的一件事。这对于满足那些超级用户的报表需求变得更加常用。

64位的平台因为它的可扩展的存储架构给数据仓库提供了很多的优点。数据仓库支持读取GB级和TB级数据级的存储要求。这种平台消除了32位的平台上的一些顾虑，但是又具有32位平台的所有优点。对于数据仓库来说更加是这样，因为数据仓库存储和查询非常大的数据库。

在选择64位平台时，还需要考虑是使用x64还是IA64。做考虑之前需要考虑很多因素。在SQL Server中完全支持x64，并且为数据仓库提供了很多好的选项。目前，IA64硬件提供更多的可量测性，但是x64平台很快赶上了它。记住IA64是完全不同的一种芯片结构（它支持数据仓库中常见的平行化和改善计算逻辑）是非常重要的。既然这两种芯片架构很快的发展，因此最好还是好好地学习一下当前的提供情况。在TPC的网址（http://www.tpc.org/tpch/results/tpch_perf_results.asp）上提供了参考。

除了芯片架构之外，处理机的数量和速度也是很重要的一个方面。数据仓库需要很大数量的平行化的需求，这与处理器的速度和时钟速度是有很大关系的。在实现数据从仓库之前很难估计实际的需求。一个很好的方法是不仅仅确立一个开始的基线，也要识别硬件和架构。

2. 磁盘的配置

数据仓库的磁盘的配置也是很重要的一个因素。数据仓库动辄就需要TB级的I/O操作。如果这些信息恰好很少查询，I/O在我们的环境中将会是一个很大的因素。I/O仍然是硬件系统中的一个最慢的方面，因此为了能够正确的购买和配置磁盘子系统，需要进行周密的计划。存储范围网络（Storage Area Network：SAN）仍然是大型数据库（例如数据仓库）的一个理想的选择。在考虑SAN时需要考虑不同的文件类型（tempdb、数据文件和日志文件等）的特征，以便磁盘子系统能够得到正确的设计。磁盘配置的一些基本的最佳实践如下：

(1) 创建更多的SAN磁盘组来支持来自SQL Server的多重的和平行的I/O。每一个磁盘组由不同的磁盘数组组成并且基于数据的类型（工作的数据、历史数据、日志和Tempdb）配置；

(2) 考虑SAN卖方基于I/O等级的推荐；

(3) 为了保证在每一部分失败时能够恢复的分离，需要将数据和日志文件放在不同的磁盘组中进行；

(4) 将tempdb数据文件和日志文件放在不同的磁盘组中；

(5) 保证数组从大数量的物理磁盘中构建，但是没有充满在控制器中；

l 大表通常经历了大范围的读取，从大数量的磁盘到均匀的分配I/O。

当定义RAID需求的时候，OLTP的对于数据仓库环境的一些最佳实践派上了用场。Tempdb是一些重要的数据库，这些数据库必须与在RAID序列的其他的数据库文件分开存放。

当你架构一个数据仓库的时候，需要富有创造力的考虑这些数据。特别是当你具有OLTP背景的时候。记住，即使数据库巨大，也很少一部分是很规则的被更新。

为了决定创新性的架构需要看看用户的查询需求。

网络需求常常有很大不同。虽然查询能在很大数据范围内得到过滤，返回给客户端的最终结果集常常是很小的。当一个分离的应用程序在相关的数据仓库和终端用户数据之间被插入时会发生异常。这个应用程序可能是OLAP服务器，例如分析服务等。这些应用程序趋向于从SQL Server中请求大数量的数据，在两个服务器见请求高速度的网络连接。

3. SQL Server的配置

一旦购买了合适的硬件，为了充分的发挥SQL Server的潜能，对其进行配置变得很重要。SQL Server是被设置为自和谐的，因此，在很多情况下，要做的事情只是留下不同的配置值。但是这个规则中也有一些例外的情况，例如在数据库布局方面的一些建议等，这些在本小节中将进行讲述。

将数据仓库的服务器与其它的应用程序或数据库共用一个服务器是不明智的。资源利用的不一致使得很难对应用程序数据库提供一致的性能。

首先考虑一些存储器的配置。在很多情况下，通常选择的是64位的平台，因为相关数据仓库的存储量的高需求。AWE(Address Windowing Extensions)能从逻辑上增加32位平台的存储条，但是它引入了存储映射，这在64位平台上是被避免的。

“Max Degree of Parallelism”选项告诉SQL Server在一次单独的查询执行操作中平行化程度的最大程度。默认值0告诉SQL Server在运行时才决定其值。当一个平行化的计划为了一个查询产生时，查询优化器基于当前在运行时所获得的处理器决定。

一个经常被忽略的SQL Server选项是“query governor cost limit”，这个属性表示当查询超过多少时将拒绝执行。默认值0表示所有的查询都将被执行。

CPU和I/O也常常由SQL Server实例指定。不像在服务器上的共享服务资源的其它应用程序，它们必须不使用。这个配置在一些很小的数据仓库中是强烈推荐不使用的。

4. Tempdb

tempdb数据库是数据仓库中的重要组件。数据仓库查询趋向于执行分组的、排序的和聚合的大数量的行。依赖于存储资源、索引和查询结构，很多需求是在tempdb上的。

配置tempdb的第一步是尽可能的将其置于最有效的磁盘上。

第二步是为tempdb确定一个合适的磁盘容量，使得其能够在查询环境中适应。

5. 数据库配置