Performance of cumulative total and caching

Question

Hi all
I'm having some trouble with performance when using the cumulative total function from AWM in derived measures.
For some of our measures we store a delta, i.e. the change from the previous actual and an initial state as the first delta. From this we can work out the actual value at any point by doing a cumulative total across the entire range. For this i've used the cumulative total function in the calculated measure wizard in the AWM.
Would any one know the implementation specs for this algorithm?
In the AWM XML it does not have an OLAP DML formula, instead it seems to use a bibeans definition with oracle.dss.selection.calcStep.TimeCumulativeTotalStep as some sort of working class.
I expected from the 'step' function that the cumulative total would be worked out as we go i.e. work out total for 1st month, then for the second month take this result and add the delta from the second month. For third month add third month's delta to second month and so on. This would make the performance linear as you do one cache hit (for previous total) one read (for delta) and one calculation per month added.
However i get these kind of numbers for years returned against query time.
1 year- 1 second
2 years - 5 seconds
5 years - 46 seconds
The results show non linear growth which when you do query over 10 years cripples the system.
Its looking like the cube is either working out each total from scratch and as such later years must add up more deltas or the cached total is being missed (if using the algorithm above) and hence must be recalculated, resulting in the same behavior as above.
NB i've fully aggregated my cube so no aggregation is being done up to the month/week level.
Can anyone tell me what's going on here, is it a poorly coded algorithm or are there some settings in olap that i need to modify to improve performance?
My recourse at the moment is to retrieve all the deltas and do my own linear cumulative total in pl/sql, however as other calculated measures rely on these totals, I'd have to recode all of our calculated measures in pl/sql which seems wholly redundant.
I'm on 10.2.0.1, using an all sparse cube with compressed composites, time is my first dimension in the order.
PS on my first run of doing the cumulative total in pl/sql i retrieved 10 years worth of deltas and totalled them in 0.2 seconds.
This is opposed to 395 seconds for 10 years using the inbuilt olap function!
Message was edited by:
Block

Answer 1

I think have seen this type of issue before where the calculated measures do create performance issues. This does seem to mainly affect time based calculations and I think this is because there is specific processing that occurs for time based calculations to manage the default time levels of day, week, month, quarter and year.
It is possible to create your own custom formula via DML to perform a cum. total. However, you will need to create some additional objects within your AW to manage the relationships between the levels within your time dimension.
Using the common schema sample that is shipped with BI10g I produced the following report:
limit time to '1803';
limit time add descendants;
limit time keep time_levelrel 'CAL_MONTH';
RPR DOWN TIME -
W 30 TIME_LONG_DESCRIPTION -
W 10 D 0 <CUMSUM(SALES_REVENUE, TIME, TIME.QTR) -
CUMSUM(SALES_REVENUE, TIME, TIME.YR)>;
This creates a running total for both quarter and years.
January 03 2,077,440 2,077,440
February 03 4,435,069 4,435,069
March 03 6,093,747 6,093,747
April 03 1,573,273 7,667,020
May 03 3,285,001 9,378,748
June 03 4,925,472 11,019,219
July 03 1,891,216 12,910,434
August 03 3,796,132 14,815,351
September 03 5,827,050 16,846,269
October 03 1,722,615 18,568,884
November 03 3,441,748 20,288,017
December 03 5,373,679 22,219,948
this requires two additional dimensions and associated relations to manage the reset process:
If you need quarterly balances:
DEFINE time_quarter text dimension
DEFINE TIME.QTR RELATION TIME_QUARTER <TIME>
limit time to time_levelrel 'CAL_QTR'
MNT TIME_QUARTER MERGE VALUES(TIME)
limit time to time_levelrel 'CAL_MONTH'
TIME.QTR=time_parentrel
If you need yearly balances:
DEFINE TIME_YEAR TEXT DIMENSION
DEFINE TIME.YR RELATION TIME_YEAR <TIME>
limit time to time_levelrel 'CAL_YEAR'
MNT TIME_YEAR MERGE VALUES(TIME)
limit time to time_levelrel 'CAL_MONTH'
TIME.YR=TIME_PARENTREL(TIME TIME_PARENTREL)
LIMIT TIME TO TIME_LEVELREL 'CAL_QTR'
TIME.YR=TIME_PARENTREL(TIME TIME_PARENTREL)
If you just need to create totals reset at the year level then the formula would be:
CUMSUM(SALES_REVENUE, TIME, TIME.YR)
I don't think I can post the XML for the custom calculation template into this posting as I think it gets filtered out. Send me an email ([email protected]) and I will send you the XML template for creating a custom calculation that can be imported into AWM.
Hope this helps
Keith Laker
Oracle EMEA Consulting
BI Blog: http://oraclebi.blogspot.com/
DM Blog: http://oracledmt.blogspot.com/
BI on Oracle: http://www.oracle.com/bi/
BI on OTN: http://www.oracle.com/technology/products/bi/
BI Samples: http://www.oracle.com/technology/products/bi/samples/