Please see the below link referencing the issue:
The specified view list is invalid or the views were selected using a different outline
Essbase cannot use the view list. Significant changes may were made to the outline after the views were last selected. Examples of outline changes that may make a view list invalid are changes to the number of dimensions or to the number of levels in a dimension.
After changing an outline, delete obsolete views (this is not done automatically). Repeat aggregate view selection after making major changes to the outline.
The change is only addition of members on same level.
Only way I can see this being possible is if the dimension you changed has attributes, and where you previously had all members associated with an attribute, you now have some members not associated.
Take a good copy of the outline (or restore it from backup) and run the following MaxL on the old and new cubes:
query database app.db list aso_level_info;
That should show you where the differences are.
Thanks Tim , but if we dont run the query we still should be fine with calculations and retrievals , correct ? Or does it have a significant boost on the query time ?
While we start designing aggregation , we see a. select all recommended aggregate views or b. Total storage space , below there is information about "Current lev 0 input size", "Existing aggregation data size" . Before starting teh query what value should eb choosen here . I was also curious on the significance of these numbers if you can kindly ellaborate . I understand that this information is about the data storage in level 0 members of ASO but i was not very accurate about this process for a while.
To your first question, it can make a huge difference, yes.
The 'level-zero' and 'aggregate data' sizes are what they sound like they are. If you see 10GB of input data and 0GB of aggregate data, selecting a total space of anything over 10GB will leave room for some aggregated data. Likewise if you see 10GB of input data and 2GB of aggregate data, you are only going to get the wizard to design more views if you select a total size greater than 12GB (or select the 'replace existing' option).
I spoke about this at the Kscope conference in 2011, and (if I do say so myself ) still think my presentation is a good introduction to these topics: ODTUG : ODTUG Technical Resources. You will need a free associate membership to download it (just a matter of registering with your email address).
Tim , what I follow is . I select an upper range of value , say 10000 mb and run the query . Once it completes , we see Number of selected views which will have a value and Total size of selected/all views which will be 5000mb or some value . Later i go back and restart by mentioning Total storage space as 5100mb or 100 mb more than Total size i see.
This whole process confuses me. Beacuse , if i check the existing aggregation data size , lets assume 5000mb , and i use 5100 mb in total storage space and run query the selected views will be for ex: 41 and total size of selected views will be 5200mb. While i select an upper value , say 8000 mb and run query then the number of views will be 70 and Total size of selected views will be 6300mb.
My point is if we just go with aggregated data size and adding some extra value , we might miss more views to do aggregation. Correct me if I am wrong . But i am trying hard to understand this concept.
Highly appreciate If you can provide me some clarity on this.
Did you read the presentation I linked?
Yes, the size doesn't always quite match up to what you requested. That's because each separate view requires a discrete chunk of space, so you aren't going to hit the target exactly. Imagine you have a pile of bricks, and someone asks you for 10 kilos of them. It's likely you'll be slightly under or over, if you can only work in whole-brick increments.
Actually, the sizes in the wizard are only estimates anyway.
There is a theoretical maximum number of aggregate views for any given outline but I doubt you'll reach it in a real-world ASO application. But you do reach a point of diminishing returns, where the new views don't make any noticeable difference to query performance and / or the size of the aggregate data actually becomes a burden, preventing your whole cube from fitting into memory.
I am having hard time retrieving that document , I am not getting option to sign in as free member. Individual membership is 99 $/year !! Let me try Associate membership.
Yes as you said , after a certain point the query cost remained same for almost 1000 mb.
Is the whole purpose of Aggregation wizard to allocate chunck of spaces to each view ? I am not sure what query cost is . When I ran an aggregation now , the QC came to 20 !!
So out of the entire ASO storage space , we select 5000mb or something for aggregation . And each view ( still guessing what would be the co ordinates of "VIEW") is allocated certain space in the database . Is this the whole purpose of this wizard ?
I really recommend reading the presentation (rather than making me reword the contents here ) first.
If that link doesn't work, go to ODTUG.com and click on "Join ODTUG" in the top right corner. Choose "Associate Membership" if you don't want a paid membership. Once you've done that, go to ODTUG.com and click "Log in". Then go to the "Tech Resources" link, choose "EPM" and search for "Optimizing Aggregations". It's a presentation from Kscope '11.