聚合最大化
所谓的聚合，就是预先计算好汇总数据，并将汇总数据物理的存储，这样在查询时就可大大提高性能。更确切地说，一个聚合单元就是与维度属性关联的汇总的度量值。(※注，原文使用的是Aggregation，在汉语中为了跟动词区别开来，翻译时使用了聚合单元，不要跟Cube中的单元Cell搞混)
聚合设计是在所有的聚合单元中挑选出一部分进行物化的过程。虽然物化的聚合单元越多（※注，下文中如无特别说明，聚合单元既是物化后的聚合单元），查询效率越高，但还要考虑创建和更新聚合所花的时间，过多的聚合单元会增加处理时间。所以必须权衡利弊。
因为可以对每个分区进行独立的聚合设计，所以下面讨论的聚合最大化技术适用于一个或多个分区的情况。在这部分文档中，如不是特别说明，聚合针对Cube的单一度量值组和单一分区。关于使用多分区来提供性能的信息，参考“使用多分区增强查询性能”章节。
聚合如何优化查询
你应该能理解通过预聚合可以提升查询性能，不过你可能还不清楚聚合如何实际的让Analysis Services 更高效地满足查询。答案很简单，聚合减少了查询时存储引擎需要扫描磁盘的数据量。要进一步说明，我们可以先讨论在没有聚合的情况下，存储引擎如何满足查询。
之前你可能会认为度量值和事实表数据是影响聚合最重要的因素，但实际上数据聚合中维度扮演着最关键的角色，维度决定着数据如何汇总。举个例子，图7展示了包含三个维度的销售Cube。
图 7 产品, 顾客, 和订单数据维度
图中每个维度有4个属性。Cube最低粒度（叶级别）包含有200个独立的产品，5,000个独立的客户，和1,095个订单。所以Cube中，叶级别的数据数量会是笛卡尔乘积：200 * 5000 * 1095，即三个维度会产生109,500,000个理论上的成员组合。但是只有当所有的这些顾客，每个人在每一天都购买了所有品种的产品时，才可能达到这一理论值，所以实际存在的组合数量会比理论数量少若干个级别。这里我们假设实际的成员数是1,095,000。
通常的情况是，终端用户不会经常查询Cube的叶级数据，很少会用到如此大的数据集（1,095,000个单元）。对非叶级的查询，存储引擎必须通过维度属性即时汇总明细级单元，从性能上看，代价太大了。为了优化汇总，Analysis Services在cube处理时，将预先计算和汇总的数据存储到聚合单元中。如果查询中能用到聚合数据，性能将大大提高。
继续上述例子的讨论，如果Cube包含了由月和产品子类别属性定义的销售聚合数据，那么在按月和产品子类别查询销售数据时，就不需要通过扫描事实数据，而是使用聚合数据满足查询。此聚合单元中理论最大的成员组合数量是720（20个产品子类别成员乘以36个月成员）。因为实际的属性成员组合数会小于720个，那么通过聚合单元远比汇总1,095,000个叶级别的成员组合高效。
而且，除了直接命中聚合单元的查询能提高性能外。存储引擎会试图使用任何可用的聚合来满足查询，存储引擎不用汇总叶级数据，而是简单的汇总聚合数据来满足查询。例如，如果你要按月和产品类别查询销售数据外，存储引擎可以通过简单汇总月和产品子类别的聚合单元来实现查询，而不需要再次汇总叶级别的数据。要利用这一查询优化机制，需要设计合适的维度属性关系和自然层次。关于维度设计的信息，参考“优化维度设计”章节。
存储引擎如何使用聚合
为了进一步理解存储引擎如何使用聚合，你可以使用SQL Server Profiler察看查询事件。命中聚合的数据请求事件是Get Data From Aggregation。图8展示了一个查询的示例和查询返回的结果集。
图8 查询例子和结果集
如图8所示，你可以使用SQL Server Profiler比较以下两种场景下，Analysis Services是如何实现查询的：
· 场景1—聚合满足查询
· 场景2—聚合不能满足查询
图9 场景1：SQL Server Profiler跟踪到命中聚合数据查询事件
图9显示了SQL Server Profiler跟踪使用聚合满足查询的事件。你可以看到存储引擎产生查询结果集的操作：
1. 查询被提交后，在Get Data From Aggregation事件中可看到存储引擎从Aggregation C 0000, 0001, 0000获取数据。
Aggregation C是聚合单元的名称。Analysis Services为聚会分配16进制的唯一名称。注意，从早期版本导入的聚合会有不同的命名方式。
2. 图9中，除了看到Aggregation C外，聚合名称中还包括标量000, 0001, 0000，此标量描述了聚合的内容。关于此标量的实际意义，参考“如何解释聚合单元命名”章节。
3. 聚合数据被装载到存储引擎的度量组缓存中。
4. 一旦数据在度量组缓存中，查询执行引擎从缓存中查找数据，并返回结果到客户端。
图１０ 场景２：SQL Server Profiler跟踪到非聚合命中查询事件
图10显示的是SQL Server Profiler跟踪没有使用聚合的查询事件，执行的操作如下：
1. 在查询提交后，存储引擎访问分区中的叶级别数据，而不是查找聚合数据。
2. 之后的操作过程就与图９中的一样了。数据被装载到存储引擎度量值组缓存。
3. 一旦数据在度量组缓存中，查询执行引擎从缓存中查找数据，并返回结果到客户端。
总结这两个场景，当SQL Server Profiler显示Get Data From Aggregation时，意味着查询命中聚合单元。这样存储引擎就能使用聚合数据满足全部或部分查询需要，而不用从叶级别数据中汇总数据。聚合命中比响应时间更能说明聚合设计是否成果。
为了帮助你有效设计聚合，Analysis Services提供了帮助创建聚合的工具和手段，详细信息，参考“哪些聚合将被创建”章节。一旦创建并部署了聚合，可以使用SQL Server Profiler在应用程序生命周期内监控聚合使用情况。
为什么不创建所有可能的聚合
因为聚合能显著的提高性能，你可能想知道为什么不创建所有理论上可能的聚合单元。回答这个问题前，先从理论的角度考虑创建所有可能的聚合意味着什么。
注意，理论讨论的目标仅是为了让你理解基于属性构架的聚合的运作方式，而非Analysis Services实际建立聚合的方式。关于更多信息，参考“哪些聚合将被创建”章节。
聚合数据用于汇总属性组合关联的度量值。每个属性有两级数据：属性自身和All属性。图11显示了产品维度每个级别明细数据。
图11 产品维度的属性级别
产品维度有四个属性，每个属性两个级别（All和属性自身），则此维度的属性组合总共会产生2^4 = 16个标量或聚合单元。
图12 三个维度，每个维度带有四个属性
如果像图12那样，所有可能的聚合单元数如下：
聚合单元总数
2 (product key) *2 (color) *2 (product subcategory) * 2 (product category)*
2 (customer key) *2 (gender) *2 (city) *2 (state/province) *
2 (order date key) * 2 (month) * 2 (quarter)* 2 (year)
= 2^12
= 4096
从这个例子中，可知任何Cube的聚合单元数量等于2^ (属性个量)。带有12个属性的Cube理论上会产生4,096个聚合。更大的Cube可能包含有上百个属性，聚合数量会指数级别增加。拥有100个属性的Cube，理论上会有1.26765E+30个聚合。
庆幸的是，这只是理论上的讨论。Analysis Services只评估小部分的聚合单元，并最终挑选出更少的聚合单元实现物化存储。通常情况，有效的聚合设计只包括几十或几百的聚合单元，不会有上千个聚合单元。
理论上的讨论提醒我们在Cube中加入更多的属性，会增加Analysis Services必须要评估的聚合单元数量。而且，因为聚合在Cube处理时创建，太多的聚合单元会影响处理性能，且需要更多磁盘空间。最终可能还会导致处理时间超出数据更新的期限。
如何解释聚合单元命名
当Analysis Services创建一个聚合单元时，维度用标量命名，表明属性是属性自身还是All级别。属性级别用1表示，All级别用0表示。例如，考虑下面产品的聚合例子：
· ProductKey属性的聚合 = [Product Key]:1 [Color]:0 [Subcategory]:0 [Category]:0 或者 1000
· Category属性的聚合 = [Product Key]:0 [Color]:0 [Subcategory]:0 [Category]:1 或者 0001
· ProductKey.All, Color.All, Subcategory.All, Category.All的聚合 = [Product Key]:0 [Color]:0 [Subcategory]:0 [Category]:0 或者 0000
为了识别聚合，Analysis Services用一个长串标量记录一组维度标量，在长串标量中使用逗号分隔每个维度标量。标量中维度的顺序由Cube中维度的顺序决定。如果你要知道Cube中维度的顺序，可以使用下面两种方法之一，在SQL Server Business Intelligence Development Studio中Cube Structure栏显式了Cube的结构，在维度面板的Hierarchies栏和Attributes栏都可以看到维度的顺序；另一种方法是在Cube的XML文件中查看维度顺序。
标量中属性的顺序就是维度中属性的顺序。你可以通过查看维度XML文件中属性顺序来了解属性顺序。
例如，一个subcube定义为(0000, 0001, 0001)代表着这样的聚合：
Product – All, All, All, All
Customer – All, All, All, State/Province
Order Date – All, All, All, Year
知道如何解读这些标量后，你就可以在SQL Server Profiler中监控查询的聚合命中信息。在In SQL Server Profiler中，你可以通过启用Query Subcube Verbose事件了解标量如何映射到特定的维度属性。
哪些聚合将被创建
为了判断创建哪些聚合单元，Analysis Services使用一套聚合成本/收益分析算法评估每个聚合备选单元。
· 聚合单元成本—聚合单元的成本主要受聚合大小的影响。为了计算聚合数据的容量大小，Analysis Services收集源数据、成员的统计数量，以及维度、度量、属性数等元数据。一旦计算好一个聚合单元的成本，Analysis Services会执行一系列的测试，将此聚合单元的成本与其它聚合单元的成本作比较，并判断成本是否超出了成本上限。
· 聚合单元收益—聚合收益依赖于其在查询时减少数据扫描的量。例如，1,000,000个数据汇总到只包含50个值的聚合单元，这个聚合单元将大大提高查询性能。你应该记得Analysis Services可以使用聚合数据满足查询，或者仅汇总低级别聚合数据。当Analysis Services要决定建立哪些聚合时，算法需要知道属性是否相互关联，以便能够检测出哪些聚合单元提供最大的查询覆盖，同时确定哪些聚合单元是不需要的。
为了帮助你建立聚合，Analysis Services提供了两个工具：聚合设计向导和基于使用优化向导。
· 聚合设计向导依据你的Cube设计和数据分布设计聚合。它在幕后使用成本/收益算法选择聚合，算法以Cube设计和数据分布的信息作为算法的参数。你可以在Business Intelligence Development Studio或SQL Server Management Studio中使用聚合设计向导。
· 基于使用优化向导依据用户的查询模式设计聚合。基于使用优化向导使用了同样的成本/收益算法，此外它还评估出现在Analysis Services查询日志中的聚合备选单元。你可以在Business Intelligence Development Studio (BIDS)或SQL Server Management Studio中使用基于使用优化向导。要使用基于使用优化向导，你必须捕获终端用户的查询记录，并将查询记录存储在查询日志中。要配置Analysis Services实例的查询日志，可以在SQL Server Management Studio中进行几步操作以控制查询采样频率和日志保存位置。
某些情况下，你可能需要更精细的控制聚合设计，SQL Server Service Pack 2的样例中包括了一个高级聚合工具，使用这个工具，可以不通过聚合设计算法，自主地创建聚合。关于此聚合工具的信息，参考附录C。
如何影响聚合设计
要帮助Analysis Services成功应用聚合设计算法，你可以使用下述的优化手段来影响和增强聚合设计（后面的章节将详细讨论这些手段）。
提供聚合备选单元–当Analysis Services设计聚合时，聚合设计算法不会评估每个属性是否适合创建聚合。所以，在你设计Cube时，确定哪些属性自动作为聚合备选，接受聚合设计算法评估的，哪些是需要你指定为聚合备选单元的。
提供Cube数据的统计信息–为了智能评估聚合成本，聚合设计算法分析Cube中每个聚合备选单元的统计信息。例如包含成员数和事实表数据量的元数据。确保及时更新元数据，以改进聚合设计。
采用合理的聚合设计策略–为了帮助你设计最有效的聚合，在开发生命周期的不同步骤，利用不同的聚合设计方法。
提供聚合备选单元
当Analysis Services设计聚合时，聚合设计算法不会自动评估所有的属性，判断它们是否合适建立聚合。还记得之前讨论过理论可能的聚合数量吗？如果Analysis Services要评估每个属性，那么它将花费过长的时间设计聚合，而评估的过程是不会干扰向聚合单元中填充数据的。所以为了使此过程能流水线处理，Analysis Services提供了Aggregation Usage参数让你决定哪些属性作为聚合备选而接受评估。对每个度量值组，确定哪些属性自动接受聚合设计算法评估，哪些是需要你指定为聚合备选单元的。
聚合使用规则
聚合备选单元是Analysis Services需要评估是否需要创建聚合的属性。存储引擎通过Aggregation Usage参数决定一个特定的属性是否要作为聚合备选。Cube中每个属性都有Aggregation Usage参数，所以属性的这个参数是全局的，对Cube中所有相关的度量值组和分区都会有影响。Aggregation Usage参数可以是这四个值：Full、None、Unrestricted、和Default。
· Full—聚合包括属性和相关属性链的下级属性。例如，产品维度有属性链：产品、产品子类别、产品类别。如果你设置产品类别的Aggregation Usage参数为Full，Analysis Services可能会创建包括产品子类别的聚合，这将子类别关联到类别，且用来计算类别总计量。
· None—不会创建包括此属性的聚合单元。
· Unrestricted—不限制在聚合设计中使用此属性，但仍要满足一些条件后才能确定属性是有价值的聚合。
· Default—根据属性和维度的类型应用默认的规则来判断是否作为聚合备选。如你所想，这是Aggregation Usage参数的默认值。
默认规则是非常保守的设置，所以你必须要很好的理解它。默认规则可分成四个约束条件：
1. 默认约束1—粒度和All属性应用Unrestricted设置 – 维度中的粒度属性和All属性应用Unrestricted设置。粒度属性是用于与度量值组关联的属性，当维度通过键属性关联到度量值组时，粒度属性就是键属性。
为了使你明白默认约束1，图13显示的产品维度包括6个属性，每个属性显示为属性层次。还有三个用户层次，其中两个显示为蓝色的是自然层次，显示为灰色的是非自然层次。Product Key是用来关联度量值组的粒度属性，因此在默认约束条件1下，它是唯一的聚合备选。
图 13 应用默认约束1后产品维的聚合备选
2. 默认约束2—特殊维度类型应用None设置 – 所有的多对多、非物化引用维度、数据挖掘维度中的所有属性（除了All属性），使用None设置。图13中的产品维度是标准维度，因此不受约束2的影响。关于多对多和引用维度的信息，参考“复杂维度关系”章节。
3. 默认约束3—自然层次应用Unrestricted设置 – 对所有的用户层次，使用特殊的扫描过程识别属性是否包含在自然层次中。如之前所述，自然层次是一种用户层次，在此层次中所有级别的属性都有属性关系。
为了识别自然层次，Analysis Services从用户层次顶级开始向下扫描，检查每一级属性是否通过直接属性关系或非直接属性关系联接到下一级。除了IsAggregatable参数设置为False的属性会应用Full外，通过自然层次检验的属性应用Unrestricted设置。
4. 默认约束4—其他属性应用None。对维度中其他属性应用None设置。在图13的例子中，color属性就使用None设置，因为此属性只在属性层次中使用。
图14显示了产品维度应用了默认规则后，维度中属性的约束条件。黄色的属性是用于聚合备选的。
· 按照默认约束1，Product Key和All属性作为备选。
· 按照默认约束3，Size, Size Range, Subcategory和Category属性作为备选。
· 按照默认约束4，Color不会参与任何聚合。
图 14 应用了默认约束后产品维度的聚合备选
因为图表让你能很方便的了解默认规则的影响，所以你可以在设计聚合时，可以使用聚合设计向导查看特定的聚合备选。
图15显示的是聚合设计向导中对象计数页面。在这个向导页面中，你可以图14中聚合备选属性用粗体字标出。关于对象计数的讨论会在“提供Cube元数据统计信息”章节进行，会详细讨论如何更新统计信息以便让你改进聚合设计。
图 15 聚合设计向导中的聚合备选
影响聚合备选
依据Aggregation Usage参数设置，下面是一些关于影响聚合备选的建议。注意这些修改只是影响聚合备选，不是实际的聚合，在创建聚合前仍要经过成本/收益评估。下面会分三种情况讨论：
· 没有用户层次的维度—如果你的维度只有属性层次，默认地只有粒度属性被用作聚合备选。那么你可能需要增加一些自然层次，不光是因为受Aggregation Usage的影响，而且还可以通过预定义的导航路径让你的用户有更好的分析体验。
· 只用于属性层次的属性—如果一个属性只用于属性层次，如图14中的属性Color，你可能需要更改Aggregation Usage参数：
· 如果一个属性经常被使用，或者有特殊的要求用来旋转和钻取数据，你就可以将Aggregation Usage由Default 改成Unrestricted。例如，如果你有一个高度汇总的记分卡样式报表，需要通过减少初始查询的响应时间来提供用户的体验，那么你就可以更改Aggregation Usage参数的设置。
· 在某些场合，将某个特殊属性的Aggregation Usage设置为Unrestricted是可行的，但不要试图将所有的属性层次都设置为Unrestricted，否则你会发现向导需要花掉大量的时间评估所有可能的聚合备选。在大型的cube中，向导可能会花掉一个多小时去完成聚合设计，之后还需要更多的时间去处理聚合。反之，你应该将经常查询的属性层次设置为Unrestricted。通常可以将维度中一半的属性设置为Unrestricted。
· 只有当你确实需要优化查询时，才将Aggregation Usage参数改成Full。不过应该尽量避免这样做，且只有当属性含有相对较少成员时才改成Full。
· 不常使用的属性—如果自然层次中的属性用户很少使用，你需要将Aggregation Usage设置为None。这样就可以帮你节省聚合数据所占的空间，并确保维度中不超过一半的属性是Unrestricted的。例如，某些属性只被少数的高端用户使用，这些用户能接受轻微的查询延迟。在这种情况下，你可以强制聚合设计算法仅为那些被大部分用户使用的属性建立聚合。还有一种情况，你可能会考虑将Aggregation Usage设置为None：自然层次中某个属性成员的数量与它下一级属性成员的数量几乎一致。例如，产品维有20个子类别，18个类别，将20个成员汇总到18个成员的IO代价几乎可以忽略。普遍来说，如果级别间成员比不超过2：1，你可以考虑将Aggregation Usage设置为None。
提供Cube数据的统计信息
当聚合设计算法确定了聚合备选单元后，它会对聚合备选单元执行成本/收益分析。为了智能评估聚合成本，聚合设计算法分析每个聚合备选单元的统计信息。例如分析聚合备选单元的成员数量和事实表数据行数等元数据。通过更新元数据以增强聚合设计的效果。
你可以通过度量组的EstimatedRows参数定义源事实表的数据行数，也可通过维度属性的EstimatedCount 参数定义属性成员的数量。
你可以在聚合设计向导的Specify Counts页面修改这些数量，如图16所示。
图 16 在聚合设计向导中提供对象计数
如果数量为空（例如你没有在设计Cube的时候定义）点击Count按键计算每个聚合备选和事实表的大小。如果数量已经存在，点击Count按键不会更新数量。你必须手工在对话框中，或通过编程方式修改。如果你在开发环境使用一个小型数据集设计Cube，然后把Cube用于正式生产环境的大型数据库时，手工修改统计信息就非常有必要了。
而且，当你使用多分区来物理分布数据，分区数据计数准确地反应分区中的数据量是非常重要的。如果你每年的数据创建一个分区，年属性在每个分区中的成员计数就是1。如果分区计数没有值，那么会聚合设计会参考估计计数值，此值是整个事实表的计数。
Analysis Services通过对比聚合单元的成本，得出一个成本上限值。如果一个聚合单元的成本超过了此上限值，聚合单元就立刻被抛弃。最重要的一个成本上限值称为一比三原则，既Analysis Services不会建立超过事实表三分之一容量的聚合。实际中，如果一个属性包含大量成员，而聚合单元包含此属性，一比三原则通常就会阻止建立这样的聚合单元。
低级别的聚合有更多的成员，一比三原则倾向于阻止处理低级别聚合。被一比三原则排除的聚合几乎都是那些如同事实级别（叶级别）一样大的聚合，或者如同事实级别一样难以满足高级别查询的聚合。
当你的维度拥有大量成员时，靠近叶级别的聚合大部分都会超出上限。例如，一个度量值组如下设计：
· 客户维有5,000,000个客户成员，这些客户成员被分成50,000个销售小区和5,000个销售大区
· 产品维有10,000个产品成员，分成1,000个产品子类别和30个产品类别
· 时间维有1,095天，36个月和3年
· 销售事实表包含12,000,000条销售记录
如果销售度量值组只有一个分区，Analysis Services不会考虑任何超出4,000,000行记录的聚合（一比三原则）。例如，不会考虑任何包含客户属性的聚合。同理也不会考虑由销售小区、产品类别、月组成的聚合，因为5,000个销售小区、30个产品类别、36个月产生的聚合，理论上可能有5,400,000条记录。
如果度量值组有多个分区，就可以通过将度量值组分成更小得物理数据块，并调整分区的统计信息，来影响聚合设计。
例如，你按月将度量值组分成36个分区，每个分区的统计信息可能如下：
· 客户维有600,000个客户，分成10,000个销售小区，3,000个销售大区
· 产品维有7,500个产品，分成700个产品子类别，25个产品类别
· 时间维有1个月和1年
· 销售事实表有1,000,000行销售记录
通过将数据分成更小的块，Analysis Services就可以找到更多有用的聚合。例如，销售小区、产品类别、月组成的聚合就是一个有效的聚合备选单元，因为它包含75,000行记录（3000 * 25 * 1），小于分区记录数的三分之一。当使用了多分区后，还必须更新图16中的成员计数和分区计数。如果你没有更新统计信息，Analysis Services不会知道分区包含的数据集变小了。注意，这里的例子只是说明多分区如何影响聚合设计。实际的分区容量说明和推荐分区记录数量，参考“设计分区”章节。
注意，你可以使用XMLA从Analysis Services实例中检查元数据，获取支持和监控信息。使用这种方法，你可以得到关于分区的记录计数和聚合容量信息，这些信息可以帮助你更好的了解Cube。
采用合理的聚合设计策略
聚合设计策略的目的是帮助在整个实施生命周期中设计和维护聚合。从聚合的角度来说，Cube生命周期可以分成两个阶段：初始聚合设计阶段和基于查询模式调校阶段。
初始化聚合设计阶段
最有效的聚合设计是基于用户的查询模式。可是，当你最初部署Cube时，你没有任何可用的查询使用记录，所以不可能使用基于使用优化向导。虽然使用聚合通常能得到更快的查询速度，但你应该在最初设计时限制聚合的数量。具体的初始聚合数量取决于Cube复杂度和容量（事实表的容量）。
· 小型Cube—对小型Cube，有效地初始聚合设计是在聚合设计向导中使性能达20%~30%。注意，如果设计中包含太多的属性，在计算聚合性能时，聚合设计向导有可能在达到指定的性能提升百分比前停止，同时用户界面没有任何反应。这种情况下，太多的属性会产生许多理论可能的聚合单元，但实际上只会创建一小部分聚合单元。
· 大型且复杂的Cube—Analysis Services将要花费很长的时间在大型且复杂的Cube挑选出小部分需要建立的聚合单元。理论上聚合的数量是2^（Unrestricted属性的数量）。一个拥有5个维度，每个维度有8个成员的Cube，理论上就有2^40个聚合备选单元。如果聚合向导每秒钟检测1000个聚合单元（这已经是乐观的估计了），将要花费35年才完成聚合设计。而且，大量的聚合单元将需要更多的处理时间，占用大量的磁盘空间。真实的环境中，对大型且复杂的Cube，初始聚合最好是少量的性能提升比（少于10%，甚至1%~2%）,且聚合设计向导的运行时间不超过15分钟。
· 中度复杂的Cube—中度复杂的Cube，设计聚合的目的是达到10%到20%的性能提升，且向导执行时间不超过15分钟。如果你不知道如何区别中度复杂和高度复杂的Cube，通常这样考虑：如果一个Cube的某个维度有超过10个Unrestricted属性，那就算是高度复杂的Cube。
在你使用聚合设计向导创建初始聚合前，应该修改Aggregation Usage参数以便尽量使常用到的聚合被物化创建，同时尽量使很少使用的聚合不被物化创建。Aggregation Usage等同于“暗示”聚合算法哪些属性经常使用，哪些不常使用。关于修改Aggregation Usage参数的详细情况，参考“影响聚合备选”章节。
当为分区设计好聚合后，最好检查聚合文件的容量。聚合文件的容量最好是源事实表容量的1~2倍。如果超出1~2倍，就可能需要更长的时间处理Cube和建立更大的聚合文件。在查询时，可能会因为聚合文件太大无法装载到内存中，而使性能低下。如果你碰到这些问题，最好是减少聚合备选单元的数量。
基于查询模式调校阶段
让用户使用Cube一段时间（通常是一、两周），查询日志中就能收集到用户查询模式数据。使用基于使用优化向导分析Cube查询情况，然后根据用户实际的查询模式设计更多的聚合单元。你可以通过处理分区创建新的聚合单元。当用户的查询模式改变后，再用基于使用优化向导更新聚合单元。
如果要让使用优化向导发挥作用，必须捕获终端用户的查询，将查询信息记录在查询日志中。记录用户的查询信息需要一定量的性能开销，所以推荐你在正常情况下关闭它，当需要分析查询模式时再开启。
如果你要更精确地控制聚合设计，还有一种方法可以利用基于使用优化向导。SQL Server Service Pack 2的样例中包含了高级聚合工具，它允许你通过查询日志创建特定的聚合单元，而不用聚合设计算法。关于聚合工具的信息，参考附录C。
