8 million members in ASO - is it possible

All,
Pls excuse me in asking this questions if i am not making sense.
I have around 8 million memebers . Can i think of building a ASO cube out of it. do let me know
Thanks
MS

Thanks all for your replies....
I have a huge marketing data mart where in I have already created a BO Universe on it and running few reports......
when i say i have created reports i mean i have a strandard reporting templates..... I advantage i see in Essbase cube that I am not restricted to the Report format. Now i can pull what ever and whihc ever i wanted the data I mean adhoc reporting in own styles.......
I do understand having so many members in the cube may slow down but just wanted to give a try .......
for now i am planning to start of the cube with just one product data . lemme see where i land.
Thnx
MS

Similar Messages

Maximum number of members in ASO outline

Hi All,
We are using Essbase 11.1.2.1. We have ASO cube with 11 dimensions, 1 dimension is expected to have more than 30 million members. Is that allowed ? What is the maximum limit for members in ASO cube ?
Also how to improve performance for such cube ?
Kindly advice.

I believe the answer is no. The maximum number of members is 20 million: http://docs.oracle.com/cd/E17236_01/epm.1112/esb_dbag/frameset.htm?limits.html#limits_8
Cheers,
Mehmet

Multiple shared members in ASO outline

 I am building an outline with one primary and three alternate hierarchies within one of the dimensions of an Aggregate Storage (ASO) cube. All of the leaf members in each of the alternate hierarchies are shared members of a member in the primary hierarchy. The non-shared member is a leaf in some cases and a summary point in others. All hierarchies are stored. When I try to save the outline, I get a long list of verification errors. For the stored members to which the shared members refer, Essbase is complaining that "This member has multiple copies of same shared member in at least one stored hierarchy. See other messages for which members and which hierarchies." For the shared members, Essbase complains that "Aggregate storage outlines only allow a shared member once in a stored hierarchy." For the alternate hierarchies, Essbase complains that "This stored hierarchy has multiple copies of same shared member. Remove extra member or change hierarchy to be dynamic." However, I did a find on a handful of the members that Essbase was complaining about and in all cases have found only one instance of each shared member in each alternate hierarchy. The same shared member might appear in two or more alternate hierarchies, but I have not found a case where it appears more than once in the same hierarchy. I have also ensure the following: <UL>The primary hierarchy occurs first in the outline, so non-shared members always appear before any instances of any of the shared members.</UL> <UL>There are no shared members in the primary hierarchy.</UL> <UL>All members, non-shared and shared, are in the same dimension.</UL> <UL>Non of the stored hierarchies contain both a non-shared instance and a shared instance of the same member.</UL> I have tried making the alternate hierarchies dynamic, but query retrievals are so slow that they're completely unacceptable to the client. Has anyone encountered a similar problem? Is there a solution to this? 

I heard back from Hyperion Tech Support again. Turns out it's not a defect after all. It's actually a subtle technicality in the restrictions on shared members with ASO. The first restriction, which is explained in the outline verification error message, is that you can only have one instance of a shared member within a given stored alternate hierarchy. The second restriction is that you cannot have any shared members within a given stored alternate hierarchy where the non-shared instances of the members are ancestors/descendants of each other. Unfortunately, when this restriction is violated, EAS gives the same error message as it does for the first restriction, so it's a bit harder to debug. Hope this saves someone some grief. -Silvester

40 million records in a repository. Possible?

Hi,
Our client wants to load appx 40 million records in a material repository. SAP has tested out material repository with just 1 million records. Is it even possible to load these many records? Has anyone done anything like this before and would like to share their experience?
Regards,

Hello mdm3north
Are you sure that 40 millions is really clear records and don't contain duplicates?
I dont have imagination how somebody will be work with
However as i know from my past expirience:
Usually all material area splited by some logical groups and some persons are working just with one group of materials
One of solution may be split materials by logical groups and create own repository for each logical group.
Regards
Kanstantsin Chernichenka

Shared Members in ASO

All - I am migrating outlines from 6.5(BSO) to 7.1.2 (ASO).When Imigrate I am unable to migrate shared members from BSO to ASO evenafter assigning the DIMENSION as Multiple Hierarchies Enabled. For Ex: DIM 1 (Multiple Hierarchy Enabled)..... Member 1(Dynamic Hierarchy) Child1 Child2 Child3 Child4 Member 2(Stored Hierarchy) Child3 (Shrared Member) Child4(Shared Member) I get an Error message as ASO does not support Shared Membersbut I have read that if you enable a dimension as MultipleHierarchy Enabled you can assing members of a Stored hierarchy asshared members.Please help with any inputs.Thanks in advance. Jeeva 

Had similar problem. Solved it doing these: in BSO outline, temporarily rename your shared members - just so the Conversion wizard can work. Change Dimension to Dynamic Calc. Once converted, change Dimension to Dynamic Hierarchy. Restore shared members to original names.

Syncing BSO and ASO when there are extra members in ASO

Hi All,
I have a BSO cube for planning application and an ASO cube which is used for reporting purposes. Now the problem is heavy changes were made in planning like deleting members, moving members to a different parent etc and the ASO cube was not updated for weeks. Now I have to update the ASO Cube. What are my options?
Thanks.
Edited by: user9097967 on Dec 23, 2011 9:10 AM
Version 11.1.2

Depends on how you are managing the metadata to the planning application.
Cheers
John
http://john-goodwin.blogspot.com/

Time Balance Members in ASO

Hi-I have read in the documentation that ASO doesn't support TimeBalance members at all.Is there a work around involved where in wecan include TB members.Please let me know your ideas or a way to implement TimeBalance.Thanks in advance. Narain

Try this: Case WHEN IsUDA([Measures].CurrentMember, "Time Balance Last") AND (IsGeneration([Months] , 3)) THEN Tail ( Filter ( PeriodsToDate ( [Months].Levels(1) ), Not IsEmpty ([Month Of]) )).Item(0).Item(0) where Month Of is not in the time dimension, its part of a Time Views dimension. The key to this formula are the Tail and Filter functions. Tail says to get the last and filter is what is checking for missing. Put them together and you get skip missing with TB Last. Credit goes to George Spoffard for this solution.

Upload duplicate members to ASO

I'm testing for a conversion of a cubo to one that allows duplicate members. So far, the outline has been constructed properly, including my test members [dim1].[OTHER] and [dim2].[OTHER]. However, I can't upload any data to cells in those members.
When I include just the leaf member names 'OTHER', I get an error in the dataload.err file saying OTHER is a duplicate member, even though they already exist in their dimensions.
But, if I type the qualified member name [dim1].[OTHER] in the datafile, EAS throws an error saying "Aggregate storage applications ignore update to derived cells. [%s] cells skipped". I am sure it does recognize those names as existing in the outline because changing the name throws the usual "does not exist in database" error.
I figure it interprets qualified names as having formulae in them. Is there any workaround this issue?
Thank you,
Alejandro Castro
UPDATE: I tried giving different aliases to each duplicate member (others and otherss), and got the same "Aggregate storage applications ignore update to derived cells. [%s] cells skipped" error message.

DataStorage is set to 'Store Data' for both members.
Alejandro Castro

ASO update of attribute associations causes Data to be "converted"?

Has anyone seen the issue in 11.1.2.3(.506) where associating attributes with a dimension causes Essbase to reorganize the data (it is referred to as convert)?
e.g.
import database app.db dimensions connect as user identified by password using server rules_file 'DimFuel' on error write to '/essapp/subject/sos/logs/sosp04_dims.build_dim_sosp04_sosp04_dimopen.20150429011053.err':
OK/INFO - 1270086 - Restructuring converted [5.72103e+08] input cells and removed [0] input cells.
OK/INFO - 1270087 - Restructuring converted [32] and removed [0] aggregate views.
OK/INFO - 1007067 - Total Restructure Elapsed Time : [1944.88] seconds.
Previoiusly this process ran in 3 seconds in 11.1.2.2(.100)

I agree with everything that Tim has said. Let me elaborate some more that might be helpful:
The fact that agg views are not based on query tracking makes no difference in the analysis. Query tracking only affects WHICH views are selected. Once views are selected by whatever means they are handled in the same way. Is there a reason you think otherwise?
Let's divide the question into two parts:
1. What is a restructure and Why is a restructure needed?
2. Why must the agg views be converted
But first realize there are two possibilities concerning WHICH agg views actually exist:
a. All views might be on the primary hierarchy only. (You told Essbase to consider alternate hierarchies when creating aggregates) - let's call that the Agg_Primary option
b. Views might be based on both primary and alternate (which includes attribute) hierarchies - let's call that the Agg_Any option
All of this is is discussed in my Chapter "How ASO Works and How to Design for Performance" in the book "Developing Essbase Applications" edited by Cameron Lackpour. You will also find a discussion of the bitmap in the section of the DBAG entitled "An aggregate storage database outline cannot exceed 64 bits per dimension" (Essbase Administrators Guide Release 11.1.2.1 Chapter 62 page 934). and in a presentation I made at Kscope 20120 which you can find on ODTUG.com
1. Why a restructure? As Tim says the outline has changed and anytime the number of levels per hierarchy or the width of the hierarchy changes then the coding system used for the data changes. OK what do i mean by this? The binary system by which each piece of data in your cube is described is called the "BitMap". In actuality, this bitmap only reflects the data's position in the primary hierarchy for each dimension. The primary hierarchy for a specific dimension is not necessarily the first hierarchy seen in your outline. It is the "widest" hierarchy - the one requiring the greatest number of bits to represent all Level 0 (L0) members found in that hierarchy and each L0's full ancestry within that hierarchy.
If you read the references above you will see that the number of bits used to determine the "widest" hierarchy is a function of the number of levels and the size of the largest "family" in a hierarchy. A hierarchy of 5 levels where the largest family has 17 members will require 3 bits more than a hierarchy of 5 levels with 4 members in the family (17 requires 5 bits and 4 requires 2 bits). So you can see that any time you add more members you could be causing the size of the largest family to exceed a power of 2 boundary.
Additionally, if the primary hierarchy is NOT all inclusive - i.e. it contains all L0 members for that dimension then you have to add a sufficient number of bits to enumerate the hierarchies.
So, in summary changes to the width or the height (number of levels) will require a restructure forcing the the identifying bits on every piece of data to be updated.
In the case the OP mentions where the ONLY changes are to add attribute associations you normally would NOT expect to see a change in the bitmap due to the number of bits required. This is because attribute dimensions can never have new unique L0 members (you can not associate to something that does not exist). If you go thru the math (and realize that the bitmap for an attribute dimension does NOT have consider size of the L0 families of the primary hierarchy - or whichever Level the association is based on) you will find that there is no possible attribute dimension that can require more bits than the primary hierarchy. UNLESS you have been sloppy and you have a primary dimension with x L0 members and a very large secondary hierarchy with x-n members UNIQUE L0 members (i.e. L0 members not appearing in the primary hierarchy).
So the answer is to inspect the statistics tab before and after your addition of member associations.
Note - (and this does NOT pertain in the OP's Case) a similar situation exists if all secondary hierarchies contain ONLY members that already exist within the primary hierarchy. However, remember that the FIRST hierarchy in your outline is not necessarily the primary hierarchy. Most people however consider the first hierarchy as the de-facto primary. If one is in a hurry and adds the member to that first hierarchy but does not add it to ALL of the alternate hierarchies (one of which is the true primary), then bits will have to be added to each piece of data to enumerate the hierarchies - thus triggering a restructure.
Finally, I am relying on the OP's description of the conditions where it was stated that ONLY associations were added and that no upper level attribute members created. If upper level attribute members are added it is possible that the number of levels for the attribute dimension is changed. In this case a mini restructure would be required - one that would not change the bitmap on every data item but a change to the mapping table that relates alternate hierarchies to the primary hierarchy. Note the existence of this table and its exact structure is not acknowledged by Oracle - I (Dan Pressman) have postulated it as one possible implementation of the observed functionality.
2. Aggregate View Conversion: Each data item is tagged not only with a bitmap indicating its position within each primary hierarchy but with a "View ID". This is the number that is seen in the ASO version of the .CSC file created whenever the view definition is saved. The input data is always identified by a View ID of 0. The view ID of other views is a function of the number of levels and the bits required therefore of ALL hierarchies of ALL dimensions. Therefore any restructure will require that the View IDs of all aggregate views be translated (or converted) from the old scheme to the new scheme. Note that this is purely a translation and no aggregation is required.
Please excuse me if I post this now and add some more later on this second question - actually let me know if anyone has actually read this far and is interested.
Please note in the above whenever i have said "Each data item" I am referring to the situation where no dimension has been tagged as the "compression" dimension. If a compression dimension has been used then replace the phrase "Each data item" with the phrase "each data bundle". I will leave it to the reader to find the section of the DBAG that describes compression and data bundles.

Can we load data for all levels in ASO cube

Hi All,
Can we load data for all levels of members in ASO cube in 9.3.1.
Regards

Yes you can load data for all levels in an ASO cube in any version HOWEVER, none of the upper level data in any cube will be there when you look for it. You will get a warning message in the load because ASO cubes don't store data at upper levels. It is the same as loading data into dynamic calc members in BSO cube. It will do the load without compalints, but there will be no data there (At least you get the warning in ASO)

Rule file design need to reject some members in the same field

Hi,
I'm working on Essbase vrsn11.1.1.3.I'm building dimensions through rules file. I have a .dim file with parent child reference that have 5 fields(parent-child-alias1-alias2-property).
The requirement is as such that the fourth field (alias2) is to be needed only for some members,Let say i have four members to load(A,B,C,D)Alias1 is required for all four members but alias2 is to be loaded only for B & D members.
Is there any possibility to full fill this requirement, if so then kindly let me know
thanks in advance
Edited by: hyperion on Jan 12, 2012 4:01 PM

create second rule file and load alias2 only with your select/reject criteria.
Essbase rule file will reject entire record if at least one column matches up reject condition.

More Than One Million Distinct Users

I'm looking at implementing Plumtree for an organization that has 1.2 million members. We're also looking at importing some profile data for tailoring content to different users.
Is Plumtree capable of supporting such a large number of users? What kind of issues have been faced by others who deal with large user bases? Are there best-practices that deal with this scenario? Inquiring minds want to know!

Jason,
Let me know if you have specific questions. As Mark mentioned, the 6.0 Portal (and associated Identity Services) have been tested with scenarios involving over one million users.
There are a number of factors that you should consider depending on your particular needs. Please feel free to contact me at: [email protected]
Lars
------- Jason Normandin wrote on 1/17/06 8:43 AM -------That would be very much appreciated.

Writing back to ASO with Version 9.3

Hi,
Could you please let me know if the write back facility is there with ASO cubes with Version 9.3
Thanks

You should be able to write back to level0 members in ASO 9.3.1
Cheers
John
http://john-goodwin.blogspot.com/

ASO 9.3 Time Dimension

Hi All,
I'm trying to do YTD members within ASO on a time dimension and at the same time use the Time Balance functionality. I have the following structure (I'll only do Q1)
Total QTR (dim name)
--QTR
----Q1
-------Jul
-------Aug
-------Sep
----Q2
etc
I want the YTD to just be
--Q1 YTD
----Jul (Shared Member)
----Aug (Shared Member)
----Sep
--Q2 YTD
----Q1 YTD (Shared Member)
----Oct
----Nov
----Dec
etc
However, I'm getting various errors - "This prototype must have all its shared members as siblings of previous siblings" (that just doesn't make sense to me)
Any ideas about how to solve for YTD whilst using the TimeBalance functionality with 9.3 for ASO.
Many many many thanks
Paul

Taking the error message at face value, you need to structure things differently. The Q1 YTD (Shared Member) is not a sibling of Oct, Nov, Dec, so its inclusion under the Q2 YTD isn't allowed.
Are you trying to provide a particular drilldown for the users, or are you just trying to reduce calculations a bit?
You may need to try the typical ytd structure, like:
Total QTR (dim name)
--QTR
----Q1
-------Jul
-------Aug
-------Sep
----Q2
(etc)
--Q1 YTD
----Jul (Shared Member)
----Aug (Shared Member)
----Sep (Shared Member)
--Q2 YTD
----Jul (Shared Member)
----Aug (Shared Member)
----Sep (Shared Member)
----Oct (Shared Member)
----Nov (Shared Member)
----Dec (Shared Member)
etc.
HTH

EIS move members

Hi,
I have in my outline SECURITIES under ENTITIES. Some of the securities have moved from one entity to another in my source DB. So I want to move those members without losing all my data.
In EIS, I tried to to do a member load with 'delete all members first' and 'incremental update' (increments only my SECURITY dimension). This process fails. Checking the log file, it seems it doesn't delete all members before trying to load. There are messages saying that he found duplicate member names and that user decided to ignore them. It's true it is set in the properties in my outline, and that's why I'm deleting the members first, so that he doesn't find duplicates.
The other thing is I saw in the SECURITY properties that there is an option for duplicate member names 'move members' but it's not possible to select it. Does someone which settings allow to access that option ?
Thanks,
Cyril

Hi
I think you have added recursion to ENTITIES dimension. Deleting the recursion for ENTITIES dimension table will allow Move members option.
To do this:
Open the OLAP model, select ENTITIES dimension table, go to Edit->Properties->Table
Click on Physical Joins tab
Select the row under column1 and delete.
Gangadhar

8 million members in ASO - is it possible

Similar Messages

Maybe you are looking for