Sparse Dimension

Hello,
Recently Added 2 alternate heirarchies to a sparse dimension. I have made all the parents of alternate Heirarchies dynamic while all the lev0 are shared. while the parents and Lev0 for main heirarchy are stored.
1) Is it a good practise to have parents of alternate Heirarchy Dynamic? since its a sparse dimension.
2) My .pag size has increased ? why would adding shared members increase the .pag size?
3) also my Calc time has gone up... simple Agg which is fixed for single month and year which initially used to take 6 mins is taking 15 mins... Any advice on improving the calc time?
Thank You for your help.

1) This is usually not a good practice, as dynamic calcs on sparse dimensions can cause a lot of I/O during a retrieval. This can have an adverse affect on retrieve performance. Sometimes you can get away with it if
there aren't a lot of members under the dynamic member though.
2) I recently had a similar question on Network54. In my case, the answer was likely fragmentation. Does your .pag size go down after a dense restructure?
3) What happens if you say *@IDESC(Stored Parent Name);* instead of AGG (Dimension);. Any difference?
Hope this helps,
- Jake

Similar Messages

Max. possible no of members in sparse dimension.

Hi,
Just wanted to know the maximum no of members in a sparse dimension (BSO cube) that is recommended by Oracle.
Regards,
Lijoy

Hi,
Have a look at the limits section at :- http://download.oracle.com/docs/cd/E10530_01/doc/epm.931/html_esb_dbag/limits.htm for the official Oracle suggestions.
Cheers
John
http://john-goodwin.blogspot.com/

FIX STATEMENT AND LARGE SPARSE DIMENSIONS

Hello all,
We have the following Essbase BSO db;
Account (Dense) (285 Members) (Aggregating Dimension)
Period (Dense) (65 Members) (Aggregating Dimension)
D1 (Sparse) (3700 Members)
(Aggregating Dimension)
D2 (Sparse) (8900 Members)
(Aggregating Dimension)
D3 (Sparse) (15000 Members)
(Aggregating Dimension)
Version (Sparse) (3 Members) (NON-Aggregating Dimension)
Scenario (Sparse) (5 Members) (NON-Aggregating Dimension)
Year (Sparse) (3 Members) (NON-Aggregating Dimension)
Currency (Sparse) (11 Members) (NON-Aggregating Dimension)
D4 (Sparse) (20 Members) (NON-Aggregating Dimension)
Block Size = ~150KM
Index Cache = 4GB
Data Cache = 8GB
CPUs = 8
MEMORY FREE = 26GB
NOTE:
We are executing the database with data loaded for "JUST" 10 BLOCKS,
SO
VERY VERY SMALL VOLUME OF DATA!!!
We have come across a rather irritating and strange issue while executing
the following calc;
CASE 1: With LEVEL-0 OF RELEVANT
SPARSE DIMENSIONS IN FIX STATEMENT
//ESS_LOCALE English_UnitedStates.Latin1@Binary
SET MSG ERROR;
SET CACHE HIGH;
SET UPDATECALC OFF;
SET LOCKBLOCK HIGH;
SET AGGMISSG OFF;
SET CALCPARALLEL 4;
SET CREATENONMISSINGBLK OFF;
FIX(ACTUAL,"2013",@LEVMBRS(D1,0),@LEVMBRS(D2,0),@LEVMBRS(D3,0),@LEVMBRS(D4,0),
@RELATIVE("EBITDA",0))
DATACOPY ARS->CURRENCY_VERSION TO ARS->WORKING;
DATACOPY CAD->CURRENCY_VERSION TO CAD->WORKING;
DATACOPY CHF->CURRENCY_VERSION TO CHF->WORKING;
DATACOPY COP->CURRENCY_VERSION TO COP->WORKING;
DATACOPY EUR->CURRENCY_VERSION TO EUR->WORKING;
DATACOPY GBP->CURRENCY_VERSION TO GBP->WORKING;
DATACOPY MXN->CURRENCY_VERSION TO MXN->WORKING;
DATACOPY CNY->CURRENCY_VERSION TO CNY->WORKING;
ENDFIX
$$$$$$NOTE1: The above FIX STATEMENT
works just fine and executes in 1 sec as its just a DATACOPY. ESSENTIALLY I
HAVE CREATED THE BLOCKS I WANT TO PERFORM THE BELOW SPARSE CALCULATION$$$$$$
FIX(ACTUAL,"2013",@LEVMBRS(D1,0),@LEVMBRS(D2,0),@LEVMBRS(D3,0),@LEVMBRS(D4,0),
@RELATIVE("EBITDA",0))
ARS = ARS->CURRENCY_VERSION *
"ARS_RATE"->"NO_CURRENCY"->"C_NONE"->"L_NONE"->"S_NONE"->"U_NONE"->WORKING;
CAD = ARS->CURRENCY_VERSION *
"CAD_RATE"->"NO_CURRENCY"->"C_NONE"->"L_NONE"->"S_NONE"->"U_NONE"->WORKING;
CHF = ARS->CURRENCY_VERSION *
"CHF_RATE"->"NO_CURRENCY"->"C_NONE"->"L_NONE"->"S_NONE"->"U_NONE"->WORKING;
COP = ARS->CURRENCY_VERSION *
"COP_RATE"->"NO_CURRENCY"->"C_NONE"->"L_NONE"->"S_NONE"->"U_NONE"->WORKING;
EUR = ARS->CURRENCY_VERSION *
"EUR_RATE"->"NO_CURRENCY"->"C_NONE"->"L_NONE"->"S_NONE"->"U_NONE"->WORKING;
GBP = ARS->CURRENCY_VERSION *
"COP_RATE"->"NO_CURRENCY"->"C_NONE"->"L_NONE"->"S_NONE"->"U_NONE"->WORKING;
MXN = ARS->CURRENCY_VERSION *
"MXN_RATE"->"NO_CURRENCY"->"C_NONE"->"L_NONE"->"S_NONE"->"U_NONE"->WORKING;
CNY = ARS->CURRENCY_VERSION *
"CNY_RATE"->"NO_CURRENCY"->"C_NONE"->"L_NONE"->"S_NONE"->"U_NONE"->WORKING;
ENDFIX
$$$$$$NOTE2: The above FIX STATEMENT
is where we have a problem, THE CALC JUST HANGS AND DOES NOT CALCULATE$$$$$$
CASE 2: With “specific” members of
RELEVANT SPARSE DIMENSIONS IN FIX STATEMENT
//ESS_LOCALE English_UnitedStates.Latin1@Binary
SET MSG ERROR;
SET CACHE HIGH;
SET UPDATECALC OFF;
SET LOCKBLOCK HIGH;
SET AGGMISSG OFF;
SET CALCPARALLEL 4;
SET CREATENONMISSINGBLK OFF;
FIX(ACTUAL,"2013",W1,"2251026",MORSCREJWHITE,MORSCREJWHITE_S,KG,TRADESALES)
DATACOPY ARS->CURRENCY_VERSION TO ARS->WORKING;
DATACOPY CAD->CURRENCY_VERSION TO CAD->WORKING;
DATACOPY CHF->CURRENCY_VERSION TO CHF->WORKING;
DATACOPY COP->CURRENCY_VERSION TO COP->WORKING;
DATACOPY EUR->CURRENCY_VERSION TO EUR->WORKING;
DATACOPY GBP->CURRENCY_VERSION TO GBP->WORKING;
DATACOPY MXN->CURRENCY_VERSION TO MXN->WORKING;
DATACOPY CNY->CURRENCY_VERSION TO CNY->WORKING;
ENDFIX
$$$$$$NOTE3: The above FIX STATEMENT
works just fine and executes in 1 sec as its just a DATACOPY. ESSENTIALLY I
HAVE CREATED THE BLOCKS I WANT TO PERFORM THE BELOW SPARSE CALCULATION$$$$$$
FIX(ACTUAL,"2013","2251026",MORSCREJWHITE,MORSCREJWHITE_S,KG,WORKING)
ARS = ARS->CURRENCY_VERSION *
"ARS_RATE"->"NO_CURRENCY"->"C_NONE"->"L_NONE"->"S_NONE"->"U_NONE"->WORKING;
CAD = CAD->CURRENCY_VERSION *
"CAD_RATE"->"NO_CURRENCY"->"C_NONE"->"L_NONE"->"S_NONE"->"U_NONE"->WORKING;
CHF = CHF->CURRENCY_VERSION *
"CHF_RATE"->"NO_CURRENCY"->"C_NONE"->"L_NONE"->"S_NONE"->"U_NONE"->WORKING;
COP = COP->CURRENCY_VERSION *
"COP_RATE"->"NO_CURRENCY"->"C_NONE"->"L_NONE"->"S_NONE"->"U_NONE"->WORKING;
EUR = EUR->CURRENCY_VERSION *
"EUR_RATE"->"NO_CURRENCY"->"C_NONE"->"L_NONE"->"S_NONE"->"U_NONE"->WORKING;
GBP = GBP->CURRENCY_VERSION *
"GBP_RATE"->"NO_CURRENCY"->"C_NONE"->"L_NONE"->"S_NONE"->"U_NONE"->WORKING;
MXN = MXN->CURRENCY_VERSION * "MXN_RATE"->"NO_CURRENCY"->"C_NONE"->"L_NONE"->"S_NONE"->"U_NONE"->WORKING;
CNY = CNY->CURRENCY_VERSION *
"CNY_RATE"->"NO_CURRENCY"->"C_NONE"->"L_NONE"->"S_NONE"->"U_NONE"->WORKING;
ENDFIX
$$$$$$NOTE4: The above FIX
STATEMENT works just fine, as I am fixing on just ONE member from relevant
dimensions in the FIX STATEMENT$$$$$$
Please note the only difference between NOTE 2
and NOTE 4 is the FIX statements. I.e., Fixing all required lev-0 members from
required dimensions as opposed to Fixing on just single lev-0 members from
required dimensions.
Also please note that NOTE 1 FIX statement works
just fine! So, there is no problem with the FIX statement itself but rather
with the combination of Sparse Calculations and with Fixing all LEV-0 members
from required dimension in the FIX. Probably because the Sparse dimensions are
VERY LARGE.
Could anyone shed some light on what might be wrong here?
We are on Essbase standalone V11.1.2.
Your inputs are very much appreciated!
Thanks

Hi,
One minor thing I notice - your NOTE 2 problem script does not fix on your Working version, whereas the NOTE 4 script does.
With your small number of blocks, this should not be the problem, but it's probably worth quickly testing and eliminating before delving deeper.
Your script could be invoking member formulae from the Account dimension - does your outline validate ok..?
I cannot tell from your NOTE 4 script which member relates to the Account dimension - is it 2251026?
Whichever it is, it is worth expanding NOTE 4 script up to @RELATIVE("EBITDA",0)....
- if it runs, you know the problem is with your sparse member selections (ie number of blocks being calculated).
- If it doesn't run, then you know there is a problem in calculating one or more of the Accounts under EBITDA. In which case, gradually narrow the range of Accounts to locate the Account or Accounts that trigger the issue. Chances are there's a problem with the member formula

FIX on Sparse Dimensions.

Hi,
I know that FIX can be used on both Sparse as well as Dense Dimensions. But its more efficient when used on Sparse Dimensions. Is there any logic behind...? Coz the functionality of FIX is to restrict the dimensions and members, but why is it more effective in Sparse...?
Please let me know...
Thanks,

If you fix on a sparse dimension you restrict the data blocks that must be accessed; thus it is faster.
If you fix on a dense dimension the calculation must go through every data block.
Please also refer to http://www.network54.com/Forum/58296/thread/1208974485/Order+of+Fixes+-Doesit+matter-

Why should we associate attribute dimension to base sparse dimension only

hi experts,
I have query, please suggest that.
Why should we associate attribute dimension to base sparse dimension only ? any reason is there.
thanks in advance

Have a read of - why attribute dimension attached to sparse dimension and Attribute Dimension and association with multi level base members
Cheers
John
http://john-goodwin.blogspot.com/

Re-Order the Sparse Dimensions

Hi,
We have a typical scenario where in we need to change the order of sparse dimensions in the outline.The cube is already in use,however,as we got rid of few members in one of the sparse dimension and we want to change the order of sparse dimensions in the outline to enhance the performance.
My question here is,
1.How to change the order of the sparse dimensions in the outline?
2.What would be the impact?
Any quick response on this is highly appreciated !!
Thanks,
RNG

1) We can improve calculation performance by changing the order of standard (not attribute) sparse dimensions in the database outline. We can Order standard sparse dimensions by the number of members they contain, placing the dimension that contains the fewest members first.
This arrangement provides a number of possible improvements, depending on the site:
●The calculator cache functions more effectively, providing approximately a 10% performance improvement if you have a database outline with a very large dimension (for example, a dimension containing 1000 members).
●Parallel calculation, if enabled, is more likely to be used if the standard sparse dimension with the most members is the last standard sparse dimension in the outline.
2) I think there would not be an any impact...
JSA

Sparse Dimension calc order

Hi,I have some sparse dimension with different number of members.Which is the correct order in the outline to maximize the calc time ?Thank you.

You may achieve improvement in calculation performance by changing the order of the sparse dimensions in the database outline. Order the sparse dimensions by their number of members, starting with the dimension that contains the fewest members. (Ref :Database Admin guide)

Sparse dimension problem (2)

This message is for Jade Cole and Farid Rashid:I'm working on Hyperion Essbase 5.0.2 patch 11 and when you assign a constant to a member in a sparse dimension, Essbase DOESN'T create data blocks for sparse dimension member combinations!!! It must be a bug!!! I have replicated the situation on Hyperion Essbase 6.0 and works fine.Thank you,Lucas.

You need to restrict the CLEARDATA further, as it seems to be deleting the entire block. Hence, the Account = 1 is failing.There are a few ways to remedy the problem - one way would be to use DATACOPY to create the Enterprise1 and Enterprise2 blocks, but you would need a source member that had numbers.The other thing you could do is re-arrange the formula so that a sparse member appears on the left hand side of the equation, rather than a dense member. This will create the blocks and populate the values, but you should be careful, as it may create more blocks than you want.Hope that helps.Regards,Jade-------------------------------Jade ColeSenior Business Intelligence ConsultantClarity [email protected]

Aggregate only portion of sparse dimension

System 9 BI+(9.3) - Here's my problem.
I need to aggregate only a portion of a sparse dimension.
All members are stored data. Dimension looks like this:
Total Europe
-Western Europe
--France
--Germany
--United Kingdom
--Iberia
---Spain
---Portugal
-Central Europe
-Eastern Europe
I tried
FIX(May, 2009, @IDESCENDANT("Iberia"))
agg(Products,Channel)
ENDFIX
but all it does is aggregate Spain and Portugal, but not Iberia.
I also tried
FIX(May, 2009, @IDESCENDANT("Western Europe"))
agg(Products,Channel)
ENDFIX
but again all it does is aggregate France, Germany, Spain, Portugal, bit not Iberia or Western Europe.
Any ideas/assiatnce appreciated.

The comment on Network54 (sorry, I forgot who posted it) is on the money -- you are not aggregating Region/Geography/whatever your dimension is called.
Assuming your dimension order is:
Region
Products
Channel
I would write a script like:
FIX(@LEVMBRS("Products", 0), @LEVMBRS("Channel", 0))
@IDESCENDANTS("Iberia") ;
ENDFIX
FIX(@IDESCENDANTS("Iberia"))
AGG("Products", "Channel") ;
ENDFIX
You will have to rearrange this a little bit if your dimension order is different. As an example, if your dimension order is Products, Region, Channel, your code might look like:
FIX(@RELATIVE("Iberia", 0), @LEVMBRS("Channel"))
AGG("Products") ;
ENDFIX
FIX(@IDESCENDANTS("Products"), @LEVMBRS("Channel"))
@IDESCENDANTS("Iberia") ;
ENDFIX
FIX(@IDESCENDANTS("Products"), @IDESCENANTS("Iberia"))
AGG("Channel") ;
ENDFIX
This may look painful, but you may find a significant performance increase.
Take a look at my blog post, ignore all the Planning stuff, and jump to the bit where I explain how a BSO db consolidates. The concept is identicial to the one I outline above. Here's the link: http://camerons-blog-for-essbase-hackers.blogspot.com/2009/06/why-i-hate-and-love-business-rules-part_17.html
Regards,
Cameron Lackpour

Attribute dimensions may only be added to sparse dimensions

Hello everyone,
I got this error several times. It wouldn't be so surprising for me if my Account dimension would be set as dense. But it is set to be sparse...
Could anyone help me with this?
Maybe some details will be helpfull:
I have created an attribute dimension with only one member - "Yes". Then, I have created flat file for Account dimension with 6 custom properties, every property associated with the attribute dimension. Account dim is set as sparse, not dense. Importing flat file results ok, with no errors and warnings. Validating the application is ok.

Hi Andy,
I'm using only Plan1 and account dimension is set as sparse in this plan type.
What do you mean with "refreshing"? I'm doing redeploy of the whole application from EPMA. Or should I try refreshing the database from the application? I think the first step may be the redeploy. Or am I wrong?
Thanks,
Vlado

Financial Reporting: Suppress pages for large sparse dimension combinations

Hello,
I am trying to create a Financial Reporting report that shows only pages that are populated with data, but the dimensions that I have on the page are fairly large and very sparse. There are 8,000+ combinations of sparse members, only of which about 120 have data populated and those 120 are what I want to return on my report. I can't call out the page member combinations individually as new combinations appear regularly and I want to avoid running maintenance on the report definition each time the data in the cube is refreshed. My report isn't executing, so I suspect it is running for each of the 8,000+ combinations before determining whether or not it should render each particular page. Does this behavior sound right? If so, is there a workaround or some other trick to get Financial Reporting to test for the presence of populated combinations before rendering the pages?
Any help would be much appreciated!
Thanks,
Rob M
Synapse Group/Time, Inc.

You can achieve this by doing following:
1. Open report
2. Select grid (left top corner)
3. On 'Properties' window, select suppression
4. Select '#Missing' in 'Basic option' section.
Good luck & let me of the results.
Venu

Dense and Sparse Dimensions

When defining which dimensions are sparse or dense in the outline I'm a little confused because you can't determine this until you know which measure you are refering to. A certain measure might be dense against "A" and "B" dimension and a different measure might be sparse against the same dimension. Can someone explain to me how this works with this scenerio?

You are describing a common catch-22 with Essbase - unfortunately the specification of storage is at the dimension level in Essbase - not the intersection level.There are a few things you can do - you could try the "offending" dimension in either configuration and see which performs better and meets your calc requirements.If its really a problem in terms of storage and performance, and neither configuration works, you could consider splitting the database into two and each can have its own configuration. The drawback is that the users must know which cube contiains which data. You could partition the two cubes together, but it is not recommended that you partition cubes with different sparse/dense configurations, as there can be a significant impact on retrieval performance.Probably not the answer you were looking for, but its the only one I can think of without more details.Regards,Jade----------------------------------Jade ColeSenior Business Intelligence ConsultantClarity [email protected]

Are there any implications on changing a dense dimension to sparse?

We have some calculation performance issues where our calc is taking a long time to run. We have 6 dimensions, Scenario, Period/Months, Years, Currency, Market, and Accounts. Market and Accounts are the only Sparse members. We tried to make Years sparse (through research, although all the years have data), and the calculation time improved significantly. My question is, will this change have any implications on retrieval or data load?
Here's our calc:
Agg(Accounts, Market)

The short answer is 'yes', it may have implications, and you will have to test to figure out what they are.
'Years' is a classic candidate to be a sparse dimension (as is 'Scenario'). But your cube design sounds unusual, at least in my experience, which may or may not be for good reasons. So it's all but impossible to make predictions or recommendations without knowing more about the cube and the input dataset.
Incidentally, the simple fact that all years have some data doesn't in itself make Years a candidate for a dense dimension (which is what you seem to be implying). Within reasonable limits of block size, you want to select dense and sparse dimensions such that when data exists at a sparse intersection, the largest possible proportion of dense combinations are populated. Just for example, if you have Product, Region, Account and Period dimensions and your company sells only a small proportion of Products in any given Region, Account and Period are likely good candidates to be Dense dimensions: Where data does exist for a Product / Region combination, many Account / Period combinations are filled. Region and Product are likely poor candidates for Dense dimensions, because almost all Region / Product combinations are empty even where data exists for an Account / Period. So the simple fact that all Products have some data doesn't make Product a good dense candidate.
Hope this is of some use... :)

28.Which is a possible member of anchoring dimension (largest dense dim or smallest sparse dim or largest sparse dim...

Higreetings to you all.can anyone tell me "Which is a possible member of anchoringdimension (largest dense dim or smallest sparse dim or largestsparse dim etc.,)"?

There is a good explanation in the DataBase Administrator's Guide. The DBAG is always a good first stop for technical issues, and in many cases does a great job. One word of caution is that while the body text is rarely technically wrong, the same is not true for examples (throughout the documentation). Short answer (from memory, so it may be somewhat flawed): A sparse dimension is either a bitmap dimension or an anchor dimension. The bitmaps are used to optimize the calc order of the members, so it's basically a checklist of which ones are finished and which need to be done. Multiple bitmaps are needed for multiple calc conditions (like one member rolling up to more than one parent). The anchor dimensions are essentially 'outside' of this optimization technique, and thus the fewer, the better. Hence the DBAG reference to having a "single dimension, multiple bitmap" calc as being the most optimum. HTH

Sparse Dynamic Calc Member

All,
Is it better to have a sparse store member and calculating in Calcscript/Rule or sparse dynmic calc member with formula?
Thank You

Here's a little background on why sparse dynamic calcs can sometimes (but not always) be bad for retrieval performance:
- Essbase stores data in one of two types of files - the Index file and the Page file. (there can be many of each type of file, depending on how much data is stored in your cube)
- The index file stores all of the combinations of sparse members (where there is data). Think of each sparse dimension as a column in the index file.
- The page file contains "blocks" that are made up of your dense dimension members. Each "cell" in a block is 8 bytes. (a cell being a single combination of members from each dense dimension)
- Each row in your index file points to one and only one block. (this is why you need one member from every dimension to get to a data value)
So let's say we have three members in one of our sparse dimensions. For the sake of simplicity, let's say this is the only sparse dimension in the cube.
- Member "A" is stored.
- Member "B" is stored.
- Member "C" is a dynamic calc equal to "A" - "B".
Question - if you retrieve on member "C", how many blocks does Essbase have to pull into memory? 2 (the blocks for A and B), plus it has to create a block in memory for member "C". (at least I think it creates a block in memory . . . . ) Either way, that's a lot of I/O, relatively speaking.
If "C" were calculated in batch and stored, the same retrievel would only have to pull a single block into memory - the stored block for C. This is less I/O.
So why are some dynamic sparse calcs bad and others aren't? It all comes down to how many blocks the retrieval forces Essbase to pull into memory. (FYI this "memory" is really your database caches)
This is why sparse dynamic calcs like variance scenarios are common. A sparse dynamic calc that compares Actual to Budget doesn't pull a lot of blocks into memory. However, if you set a sparse parent to be dynamic, and it had 100 children, this would be pretty bad for performance.
If you can visualize this concept, you can performance tune a BSO cube. It's all about I/O.
Hope this helps,
- Jake

Sparse Dimension

Similar Messages

Maybe you are looking for