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 this1) 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 10:11:08.35 start-report_01-DB (Dynamic) finish-report_01-DB (Dynamic) start-report_01-DB (Stored) finish-report_01-DB (Stored) start-report_02-DB (Dynamic) finish-report_02-DB (Dynamic) start-report_02-DB (Stored) finish-report_02-DB (Stored) start-report_03-DB (Dynamic) Time 11:10.0 11:13.4 11:14.6 11:21.4 11:22.6 11:51.9 11:53.0 12:00.0 12:01.3 Duration Winner 00:03.4 00:06.8 00:29.3 00:07.0 Stored Dynamic

finish-report_03-DB (Dynamic) start-report_03-DB (Stored) finish-report_03-DB (Stored) start-report_04-DB (Dynamic) finish-report_04-DB (Dynamic) start-report_04-DB (Stored) finish-report_04-DB (Stored) start-report_05-DB (Dynamic) finish-report_05-DB (Dynamic) start-report_05-DB (Stored) finish-report_05-DB (Stored)

12:02.2 12:03.9 12:42.1 12:43.6 12:50.2 12:51.3 14:26.4 14:36.3 15:18.3 15:19.6 17:32.0

00:00.9 00:38.2 00:06.6 01:35.1 00:42.0 02:12.4 Dynamic Dynamic 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.