CPU Performance Issue

Question

We are facing a performance issue related to cube refresh. Even a small cube consumes around 70% of the CPU while refreshing.
Details of the cube: This cube has 10 dimensions and 46 straight forward measures (mix of sum and avg as aggregation algorithm). No compression. Cube is partitioned (48 partitions). Main source of the data is a materialized view which is partitioned in the same way as the cube.
Data Volume: 1200 records in the source to be processed daily (almost evenly distributed across the partition)
Cube is refreshed using: DBMS_CUBE.BUILD(<<cube_name>>,'SS',true,5,false,true,false);
Environment - Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 (on AIX 6.1 64 bit), AWM - awm11.2.0.2.0A
Hardware Configuration
4.2 GHz, 3.5 CPU Core 32 GB RAM
Has anyone faced similar kind of issue? Is there any server level / database level parameter that needs tweaking to control this behaviour?

Answer 1

Here is another trick to combine sum and average measures in the same cube. It relies on the AGGCOUNT function in OLAP DML, which you can look up in the reference guide.
Suppose that you have a cube with two measures, A and B, and that you want to aggregate A using SUM and aggregate B using AVG.
Step 1: Make the cube be compressed and aggregate all measures (A and B) using SUM.
If you do this using AWM, then the solve specification should include a MAINTAIN COUNT clause. To double check, look at the user_cubes view for your cube (TEST in my example).
select consistent_solve_spec from user_cubes where cube_name = 'TEST';
CONSISTENT_SOLVE_SPEC
SOLVE
  SUM
    MAINTAIN COUNT
    ALLOW OVERFLOW
    ALLOW DIVISION BY ZERO
    IGNORE NULLS OVER ALL
)You can hand edit the XML for the cube if this hasn't happened. Here is what you want to see in the XML for the cube.
    <ConsistentSolve>
      <![CDATA[SOLVE
  SUM
    MAINTAIN COUNT
     OVER ALL
)]]>Don't worry about the slight difference in syntax -- this is due to different printing routines in the client Java and the server c code.
Step 2: Verify that the cube's VARIABLE has the WITH AGGCOUNT option.
My cube is named TEST, so the variable is named TEST_STORED, and my cube is dimensioned by TIME and PRODUCT. You can run this in the OLAP Worksheet.
dsc test_stored
DEFINE TEST_STORED VARIABLE LOCKDFN NUMBER WITH NULLTRACKING WITH AGGCOUNT CHANGETRACKING <TEST_PRT_TEMPLATE <TEST_MEASURE_DIM TIME PRODUCT>>
Step 3: Define a new Calculated Measure, B_AVG, in the cube to get the average for measure B.
Select "OLAP DML Expression" as the "Calculation Type" and enter the following expression. Obviously you need to adjust for the cube and measure names. I am putting new lines into this for readability.
QUAL(
  NVL2(AGGCOUNT(TEST_STORED), TEST_STORED / AGGCOUNT(TEST_STORED), TEST_STORED),
TEST_MEASURE_DIM 'B')
Step 4: Specify the $LOOP_VAR on the new measure
Execute the following in the OLAP Worksheet. (Again, correct for measure and cube names.) It instructs the server to loop the cube sparsely. If you don't do this, you will get dense looping and poor query performance. You only need to do this once (per calculated measure). If you save the AW to XML after this, then the LOOP_VAR value will be saved in the XML itself.
call set_property('$LOOP_VAR' 'TEST' 'B_AVG' 'TEST_STORED')For reporting purposes you should look at measures A and B_AVG.