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-

Similar Messages

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

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

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

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/

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]

Fixing Tab Container Dimensions

Is there an easy way to setor "fix" the height and width dimensions of a tab container -- not the tabs themselves -- so that they do not change automatically when a "too large" front panel control or indicator is placed on them? I am using multiple graphs, pictures, text and other itemson tabs and they occasionally change the size of the tab container resulting in a lot of extra effort.

Hello,
I think you are probably looking for the tab control pane dimension property node. You can also set the Autogrow to false to ensure that when you add an object into the tab control, it does not automatically resize the pane.
Hope this helps!
Tejinder Gill
National Instruments
Applications Engineer
Visit ni.com/gettingstarted for step-by-step help in setting up your system.

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]

Any way to fix ZFS "sparse file bug" #6792701

I have a Solaris x86 server running update 6 (Solaris 10 10/08 s10x_u6wos_07b X86). I recently hit this "sparse file bug" when I deleted a 512GB sparse file from a 1.2TB filesystem and the space was never freed up. What I am asking is would there be any way to recover the space in the filesystem without having to destroy and recreate it? I am assuming before trying anything I would need to update the server to U8.
Thanks in advance...
Robert Loper

Per assistance from the zfs-discuss mailing list:
Installing kernel patch 141444-09 (SPARC) or 141445-09 (x86) (included in a Live-update to Solaris 10 update 8) on my system showed the file system with 600GB more free space. I did not need to export/import or upgrade the pool...it was just available.

FIX on a UDA

I am trying to FIX on a UDA for the 'Period' dimension. The UDA is defined as either 'open' or 'closed'. The dimension is re-built dynamically each night. When some periods are 'open' and others 'closed', this MAXL works. However, when all periods are 'open' - and there are not any 'closed' periods, the FIX statement doesn't operate as expected and the MaxL runs everything under the FIX. Very odd. Can anyone shed any light on this and offer their best work-a-round? Thxs.
FIX (@UDA("Period", "closed"))
CLEARDATA "Forecast";
DATACOPY "Actual" TO "Forecast";
ENDFIX;

Hello There.
Cameron:
I should have been more clear in my original posting.
The intent of the suggestion/alternative was from an "ease" of maintenance (and avoiding the "global fix" problem) perspective rather than a speed/performance one.
Regarding the FIX on the sub vars you are absolutely correct -- it will not make it any faster -- but you could prevent the script from executing the statements within the FIX by using sub vars rather than UDAS (actually you could also create an "opposite" UDA like "open" and use AND/OR/NOT logic within the FIX signature itself if you didn't want to go down the sub var path for whatever reason). As you know the problem the user is having is when there are no UDAs on the members of the period dimension the statements within the FIX execute (older version of essbase and setting option not being available). I was simply stating that you could use sub vars to specify only those months (assuming months are the base level members of the period dimension) that you want the enclosed fix code to operate on -- of course you could/would need another sub var to specify the months to specifically exclude (e.g. &ActMonths, &FcstMonths) and possiibly AND/OR operator within the FIX statement itself if you like. The bottom line is you would make certain each member was always tagged with one of the two sub vars (again - could be done with udas) thereby allowing the script to only operate on those periods that it should. I just looked at the users second entry and it appears the second UDA and conditional route was taken.
In my opinion, a single substitution variable that evaluates to 1 - 12 months (modified in one place - the sub var value-string itself) seems easier than manually or via load rule changing (potentially) up to 12 different period base level members -- once again assuming the base level members are indeed months.
And yes you are correct - datacopy does not work within a conditional -- it would have to be accomplished through another means which I now see the user chose -- and yes you are also correct in that datacopy is very fast and would likely be the hands-down most efficient means.
Gary:
With regard to the "Golden Rule" statement -- it was not my intention to imply that it is a "always do this or perish" rule (although - admittedly - using the term "golden" probably made it appear quite the contrary) -- given the fact that rarely is anything always black/white when it comes to hyperion essbase, particularly in the realm of database calculation optimization. Nevertheless, someone should tell the numerous hyperion instructors/technical consultants (including Ed Roske as he has it clearly stated in his Look Smarter book) that I have worked with in the past. Thanks for the food for thought -- I sincerely appreciate it.
Look Smarter excerpt: "...It is a good rule that can be used even more effectively..."
Outdated/misguided logic below? You decide sports fans...
In general, you should try and only use "FIX" statements on SPARSE dimensions.
FIX statements allow you to take a slice of the database and only perform an action on that slice. If you fix on a SPARSE dimension, then you are limiting the amount of blocks that you are performing the action upon. If you FIX on a DENSE dimension, you are not limiting the number of blocks, but rather just a portion within each block. Using the FIX statement on a dense dimension can cause multiple passes through the same blocks which is very inefficient. On the other hand, the IF statement is well suited to DENSE dimensions because it performs IF logic while the block is in memory.
Example: If JUL then ..., else .... will all be performed in one pass without the need of multiple passes through the blocks. In general, try and use FIX on sparse dimensions and IF on dense dimensions.
Thank you both once again for your comments.
Regards,
todd rebner
http://www.advancedepm.com/
Edited by: todd rebner on Jun 7, 2009 10:32 AM

FIX on Sparse Dimensions.

Similar Messages

Maybe you are looking for