cognos 如何尽量减少立方体的处理时间

如何尽量减少立方体的处理时间

立方体数据集的处理本来就是是一件很费时间的事情，如果维度或立方体设计的不合理，在执行处理任务时，经常会造成机器死锁或者是形成的临时文件太大而引起的磁盘空间不足，以至于处理任务失败。
立方体数据集的处理本来就是是一件很费时间的事情，如果维度或立方体设计的不合理，在执行处理任务时，经常会造成机器死锁或者是形成的临时文件太大而引起的磁盘空间不足，以至于处理任务失败。

经过几天的反复测试，针对上面的问题，总结了一下几点：

一、如何提高立方体的处理速度

为了提高立方体的处理速度，最好在事实数据表和维度表中建立索引。建立索引的规则是：

1、为查询中经常用到的数据字段建立索引。

2 、为维度表和事实数据表相关联的数据字段建立索引。
例如存在以上结构的数据立方体，V_DBA04是事实数据表，V_DM_DBA04_NY是时间维度表，DM_DWDM是单位代码维度表，DM_QKDYDM是区块单元代码表。

在V_DM_DBA04_NY时间维度表中对经常用的ID，the_year, the_month 字段建立了索引，同时对the_yearmonth（它与V_DBA04表中的年月相关联）也建立了索引。

在DM_QKDYDM区块单元代码维度表中，对JH（与V_DBA04中的井号关联）、qkdydm（与V_DBA04中的区块单元代码关联）、dwdm（与V_DBA04中的单位代码关联）建立了索引。

在DM_DWDM单位代码维度表中，对JH（与V_DBA04中的井号关联）、dwdm（与V_DBA04中的单位代码关联）建立了索引。

当然，在V_DBA04事实数据表中，应该为其与维度相关联的所有数据字段都建立索引，这些字段包括：年月、井号、单位代码、区块单元代码。

如果事实数据表或维度表是视图，那么就在视图所对应的表中，建立相关字段的索引。

二、减小生成的临时文件

大港数据仓库系统的清洗库是在Oracle数据库系统中的，在处理立方体时，

Oracle数据库的默认表空间（一般为temp）会不断的增加，如果立方体或维度设计不合理，这个临时表空间会飞快的增长，几分钟就扩展到几十G的容量，从而造成磁盘资源不足，进而导致处理任务失败。

后来经过反复的测试，发现这是由于维度表节点存在null值引起的，同时也

要避免事实数据表中与维度相关联的字段不为null值。

例如存在一下视图：

create or replace view v_sfjjs as

select '1' as id,'计井数' as memo from dual

union all

select '0' as id,'不计井数' as memo from dual

union all

select '' as id,'不计井数' as memo from dual

union all

select null as id,'不计井数' as memo from dual

做成 是否计井数 维度后，成员结构如下：

其中的null值与’’是没有显示的。

在立方体中存在如下结构：

这个时候如果处理此立方体，会发现Oracle的temp数据表空间飞快的增长，即使将事实数据表中的记录减少到2条，处理速度也是很慢。这说明这种结构是不合理的。为了解决这个问题，我们可以将维度表V_sfjjs改动一下：

create or replace view v_sfjjs as

select '1' as id,'计井数' as memo from dual

union all

select '0' as id,'不计井数' as memo from dual

union all

select '' as id,'不计井数' as memo from dual

union all

将null值去掉（注意’’与null是不一样的），同时为了保证事实数据表中所有的记录在立方体中参与聚合，需要对实事数据表的是否计井数字段进行修改，将该字段为null值的用其它值来代替，一个好的方法就是 nvl（字段名，’’）来判断调整。

三、立方体的重新构建

如果出现了上面的问题，在对维度表和事实数据表进行修改后，其实并不没

有万事大吉，这个时候即使先重新构建维度，然后再完整处理立方体，处理速度也会很慢，还需要在立方体编辑框内将原来存有空值的维度删除，然后重新构建维度，再将维度加入到立方体中才可以。

同时，注意在改动数据立方体的源数据后，需要重新启动AS。才可以得到源数据的更新情况，利用右键刷新仓库的方法是行不通的。