Hi All,

We have an ASO cube having 11 store dimensions with 24 measures where 5 are having formulas. It
contains 20millions of records (dataload). I have created default views. The performance of cube is not
bad now but facing performance issue when drilling up/down for some dimensions in WA reports.

If any experience on the ASO optimization then pls share with us.

Your response will be really appreciable.

Thanks & regards,

Hypadmin

Hi,

There can be several options for this-

1) Use CALCPARALLEL option: multiple threads runs parallel while creating aggregate views or
fetching data.

2) Compression (perform compression on a dimension which is dynamic)

3) Increase the Buffer Size of "Data retrieval buffer" and "Data Sort buffer" ( This method is more
related to retrieval side)

4) Use query hints to build the aggregate views.

Hope these will help you.

Thanks and Regards,

Mohit Jain

If your performance issues are in zoom in, zoom out operations, what will help you is increasing the
aggregations. Doing so puts more intermediate points for reference. This can be done from EAS or frm
MaxL. One thing you can also do is turn on tracking and then use what you find from that to optimize
where aggregations are made.
Hi Mohit,

We have already set these parameters. Because of the volume of data , getting time during zoom-in /
zoom-out. trying to build aggregation points for the views.

Hi Glenn,

Exactly the performance issue is during zoom-in/zoom-out. We are taking more intermediate point for
references which are being used for the analysis. Regarding query tracking, as first time retrieval will
take time after that it will aggregate based on the query. But after data load these aggregate views will
be removed which will follow the same process to create again.

Is there any alternate to achieve the same?

Thanks & Regards,

Edited by: Hypadmin on Feb 10, 2009 5:28 PM

Hello,

As Glenn mentioned, Query tracking could help to improve your query time.
As he said, enable it and let run a batch of typical queries the users are doing, then save the Query
tracking file generated.

By using the MaxL command " execute aggregate build on database $app.$db using view_file
$cubeagg_file " you could use your Query Tracking file every time you rebuild the cube.
Still, there can be some limitations like having a new range of data for a new month and in practice,
you will sometimes need to renew the query tracking file.

We
On a personal note, I just went through this in 7.1.5, it took me a while to wrap my brain around the
query tracking, saving the view_file, and re-aggregating but once I did it was a major success.

Like everyone says above, make sure query tracking is turned on, in MaxL it's " alter database
'XXXX.'XXX' enable query_tracking; ".

Make sure it stays turned on, do not re-load or re-start the DB. In 7.1.5 DO NOT depend on EAS to
give you an accurate read as to whether query tracking is turned on, instead use MaxL " query database
'XXXX'.'XXX' get cube_size_info; ".

Have users cut loose on the database, it was a huge benefit to me that there were canned Hyperion
Reports I could run to capture the most inefficient queries and set up an aggregation based on those
queries.

While insuring that query tracking is turned on, save those aggregations into a view_file stored in a .csc
file (not like a calc script in BSO). Use that file to materialize the new aggregations. I used EAS to
perfom this task, It can also be done in maxL with ease.

Going forward, set up a MaxL Aggregation such as " execute aggregate build on database
'XXXX'.'XXX' using view_file 'ZZZZZ'; like stated above.

I want to emphasize that this can be a repetitive process, you can add views that are captured to the
View_File when you like as your users run more complicated queries. Also, as what has been said
before, if your outline or cube has drastic changes, you can repeat the process or build a new view_file
from scratch.

This is only my personal experience, I'm sure there are other uses for query tracking or for removing
obsolete aggregations from the view_file.

Edited by: user651301 on Feb 10, 2009 1:13 PM

JOHNS BLOG

http://www.jasonwjones.com/?p=184

Some performance observations changing an

ASO hierarchy from Dynamic to Stored
There are numerous ASO cubes among my flock. Usually the choice to use ASO was not arrived at
lightly it was/is for very specific technical reasons. Typically, the main reason I have for using ASO
is to get the fast data loads and the ability to load oodles of noodles I mean data. Yes, oodles of
data. The downsides (with version 7.x) is that Im giving up calc scripts, incremental loading (although
this has been somewhat addressed in later versions), native Dynamic Time Series, some flexiblity with
my hierarchies, and I have to have just one database per application (you uhh were doing that
already, right?). Also, due to the sparsity of much of the data, trying to use BSO would result in a very
unwieldy cube in this particular instance.
I have a set of four cubes that are all very similar, except for different Measures dimensions. They
range from 10,000 to 40,000 members. This isnt huge, but in conjunction with the sizes of the other
dimensions, there is an incredible maximum possible blocks potential (sidenote for EAS: one of the
most worthless pieces of information to know about your cube. Really, why?). The performance of
these cubes is generally pretty acceptable (considering the amount of data), but occasionally user Excel
queries (especially with attribute dimensions) really pound the server and take awhile to come back.
So I started looking into ways to squeeze out a little more performance.
Due to the nature of the aggregations in the cubes, they all have Dynamic hierarchies in the
Accounts/Measures dimension. This is due to using the minus (-) operator, some label only stuff, and
shared members, all of which ASO is very particular with, especially in this version. All of the other
dimensions have Stored hiearchies or are set to Multiple Hierarchies (such as the MDX calcs in the
Time dimension to get me some Year-To-Date members).
Actually, it turns out that all of the these cubes have Measures dimensions that make it prohibitively
difficult to set Measures to Stored instead of Dynamic, except for one. So, even though I would need
to spin off a separate EIS metaoutline in order to build the dimension differently (these cubes are all
generated from the same metaoutline but with different filters), it might be worth it if I can get some
better performance on retrieves to this cube particularly when the queries start to put some of the
attribute dimensions or other MDX calcs into play.
What I need is some sort of method to test the performance of some typical retrieves against the two
variants of the cube. I setup one cube as normal, loaded it up with data, and materialized 1 gig worth of
aggregations. Prior to this I had also copied the cube within EAS, made the tweak to Measures to
change it from Dynamic to Stored, loaded the data, did a gig of aggregations. At this point I had two
cubes with identical data but one with a Dynamic hierarchy (Measures with 10,000 or so members) and
one with stored. Time to compare.
I cooked up some report scripts, MaxL scripts, and some batch files. The batch file loads a
configuration file which specifies which database to hit and which report to run. It then runs the report
against the database, sets a timestamp before and after it runs, and dumps it all to a text file. Its not an
exact science, but in theory itll give me somewhat of an idea as to whether making the hierarchy
Stored is going to help my users retrieval operations. And without further ado, here are the results:
Starting new process at Tue 01/20/2009
Time Duration Winner
10:11:08.35
start-report_01-DB (Dynamic) 11:10.0
finish-report_01-DB (Dynamic) 11:13.4 00:03.4
start-report_01-DB (Stored) 11:14.6
finish-report_01-DB (Stored) 11:21.4 00:06.8 Dynamic
start-report_02-DB (Dynamic) 11:22.6
finish-report_02-DB (Dynamic) 11:51.9 00:29.3
start-report_02-DB (Stored) 11:53.0
finish-report_02-DB (Stored) 12:00.0 00:07.0 Stored
start-report_03-DB (Dynamic) 12:01.3
 finish-report_03-DB (Dynamic) 12:02.2 00:00.9
start-report_03-DB (Stored) 12:03.9
finish-report_03-DB (Stored) 12:42.1 00:38.2 Dynamic
start-report_04-DB (Dynamic) 12:43.6
finish-report_04-DB (Dynamic) 12:50.2 00:06.6
start-report_04-DB (Stored) 12:51.3
finish-report_04-DB (Stored) 14:26.4 01:35.1 Dynamic
start-report_05-DB (Dynamic) 14:36.3
finish-report_05-DB (Dynamic) 15:18.3 00:42.0
start-report_05-DB (Stored) 15:19.6
finish-report_05-DB (Stored) 17:32.0 02:12.4 Dynamic

Starting new process at Tue 01/20/2009

10:30:55.65
start-report_01-DB (Dynamic) 30:57.5
finish-report_01-DB (Dynamic) 30:59.9 00:02.4
start-report_01-DB (Stored) 31:01.0
finish-report_01-DB (Stored) 31:05.8 00:04.7 Dynamic
start-report_02-DB (Dynamic) 31:07.7
finish-report_02-DB (Dynamic) 31:40.8 00:33.1
start-report_02-DB (Stored) 31:42.5
finish-report_02-DB (Stored) 31:46.1 00:03.5 Stored
start-report_03-DB (Dynamic) 31:50.4
finish-report_03-DB (Dynamic) 31:51.0 00:00.6
start-report_03-DB (Stored) 31:52.4
finish-report_03-DB (Stored) 31:52.8 00:00.3 Tie
start-report_04-DB (Dynamic) 31:54.0
finish-report_04-DB (Dynamic) 32:06.3 00:12.3
start-report_04-DB (Stored) 32:12.1
finish-report_04-DB (Stored) 32:51.4 00:39.3 Dynamic
start-report_05-DB (Dynamic) 32:55.5
finish-report_05-DB (Dynamic) 33:38.1 00:42.6
start-report_05-DB (Stored) 33:39.7
finish-report_05-DB (Stored) 36:42.5 03:02.8 Dynamic
So, interestingly enough, the Dynamic dimension comes out on top, at least for most of the tests I
wrote. There is one of the tests though (report_02) that seems to completely smoke the Dynamic
hierarchy. I wrote these report scripts kind of randomly, so I definitely need to do some more testing,
but in the mean time I think I feel better about using a Dynamic hierarchy. Since the ASO aggregation
method for these cubes is simply to process aggregations until the database size is a certain multiple of
its original size, one of the next steps I could look at for query optimization would be to enable query
tracking, stuff the query statistics by running some reports, and then using those stats to design the
aggregations. In any case, Im glad I am looking at some actual data rather than just blindly
implementing a change and hoping for the best.
This isnt to say that Dynamic is necessarily better than Stored or vice versa, however, I ran this very
limited number of tests numerous times and got essentially the same results. For the least part, this
goes to show that there isnt really a silver bullet for optimization and that experimentation is always a
good way to go (except on your production servers, of course). I am curious, however to go back and
look at report_02 and see what it is about that particular report that is apparently so conducive to Stored
hierarchies.