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看起来是这样的：
DEFINE OBJ1124208571 AGGMAP AGGMAP RELATION this_aw!TIME_PARENTREL(this_aw!TIME_AGGRHIER_VSET) PRECOMPUTE(this_aw!TIME_AGGRDIM_VSET) OPERATOR SUM args DIVIDEBYZERO YES DECIMALOVERFLOW YES NASKIP YES COUNT NO RELATION this_aw!CHANNELS_PARENTREL(this_aw!CHANNELS_AGGRHIER_VSET) PRECOMPUTE(this_aw!CHANNELS_AGGRDIM_VSET) OPERATOR SUM args DIVIDEBYZERO YES DECIMALOVERFLOW YES NASKIP YES COUNT NO RELATION this_aw!GEOGRAPHIES_PARENTREL(this_aw!GEOGRAPHIES_AGGRHIER_VSET) PRECOMPUTE(this_aw!GEOGRAPHIES_AGGRDIM_VSET) OPERATOR SUM args DIVIDEBYZERO YES DECIMALOVERFLOW YES NASKIP YES COUNT NO RELATION this_aw!PRODUCTS_PARENTREL(this_aw!PRODUCTS_AGGRHIER_VSET) PRECOMPUTE(this_aw!PRODUCTS_AGGRDIM_VSET) OPERATOR SUM args DIVIDEBYZERO YES DECIMALOVERFLOW YES NASKIP YES COUNT NO MODEL this_aw!SALES_OBJ1124208571_TIME_AWXMLMODEL PRECOMPUTE(NA) MODEL this_aw!SALES_OBJ1124208571_CHANNELS_AWXMLMODEL PRECOMPUTE(NA) MODEL this_aw!SALES_OBJ1124208571_GEOGRAPHIES_AWXMLMODEL PRECOMPUTE(NA) MODEL this_aw!SALES_OBJ1124208571_PRODUCTS_AWXMLMODEL PRECOMPUTE(NA) AGGINDEX NO CACHE SESSION END |
