优化OLAP中的聚合

admin

DBMS_AW 包有两个很有趣也很有用的存储过程，它们使你可以调整你的聚合过程。在OLAP项目中一个常见的问题是预先计算哪些等级以及在查询时计算哪些等级?大多数人们似乎认为你必须预先计算他们维度的所有等级。不过这个方法的缺点是数据加载和聚合过程会比你所期望的时间更长。那么是否可以尽可能地平衡数据加载/聚合和预解析以维护查询性能?DBMS_AW包有两个存储过程是可以帮助你优化这个聚合过程的，它们能够确认一个维度中消耗最多的成员。这两个包是：

· ADVISE_CUBE

· ADVISE_REL

它们都使你可以定义一个百分值来进行预先计算，这作为形成常规建立过程的一部分。在11g中，这直接包括进AWM中，但是对于那些使用10g的客户，这有一个关于怎样使用这些存储过程的快速概括。

Advise_Cube

ADVISE_CUBE 存储过程帮助你确定怎样在一个分析工作区中预先聚合一个标准格式立方体。这个存储过程有两个参数：

· Aggmap_name：与这个立方体关联的aggmap的名称。

· Precompute_percentage：要进行预先聚合的立方体数据的百分比。默认是20%。

在aggmap中的每一个RELATION语句都必须有一个预先计算的条件语句，它包含一个valueset(数据集)。如果这个valueset不为空，那么ADVISE_CUBE在添加新的值前会删除它的内容。

这个aggmap必须在它的每一个RELATION语句中有一个预先计算的条件子句。预先计算的条件子句必须包含一个valueset。基于你指定的预先计算百分比，ADVISE_CUBE会返回一个在每个valueset中的维度成员集合。

现在我试着使用这个常规schema并在获取正确结果方面遇到了一些问题。在一个立方体中的每一个测量，都有一个指向AGGMAP对象的规则，如下所示，在这里aggmap是OBJ1123208571：

DEFINE SALES_PRT_TOPFRML FORMULA DECIMAL

EQ aggregate(this_aw!SALES_PRT_TOPVAR using this_aw!OBJ1124208571)

这个aggmap看起来是这样的：

在这篇文档中，这个示例显示了一个更为简单的AGGMAP，如下所示：

DEFINE UNITS_AGG AGGMAP
RELATION product_parentrel PRECOMPUTE (prodvals)
RELATION time_parentrel PRECOMPUTE (timevals)

对标准格式AGGMAP执行ADVISE_CUBE存储过程不会产生错误，但是它也不生成结果。我能让它起作用的唯一方法是使用一个valusets的不同集合创建另一个AGGMAP，如下所示：

然后从新的valuset复制结果到主valuset中。下面是用来执行这个过程的脚本：

我不确定在计算一个维度中指定成员的成本时这个是怎么工作的。对另一个包Advise_Rel清楚些。
Advise_Rel

ADIVISE_REL过程是对一个指定的维度起作用，并可以使用标准格式aggmap涉及的现有valuesets。这个存储过程有三个参数：

· Family_relation_name：家族关系的名称，它指定一个维度和维度成员间的层级关系。

· Valueset_name：一个valueset的名称，它包含了这个过程的结果。这个valueset必须是从家族关系中的维度定义的。如果这个valueset不为空，那么ADVISE_REL会在添加新值之前删除它的内容。

· Precompute_percentage：这个维度预先聚合的百分比。默认是20%。

这个valueset必须是基于要分析的维度的，而且在这种情况下这个valueset可以列在标准格式aggmap中。基于你指定的预先计算百分比，ADVISE_REL会返回维度成员的集合到指定的valueset中。预先计算的值是基于探索父成员的成本而选择的。一个父成员具有的子成员越多，那么它在查询时计算所花费的时间就越长。

这是用来执行这个过程的脚本：

最后一步是加载数据到立方体中，现在这个聚合引擎会使用这些值来预先计算指定的成员。