CALC DIM Issue

I have a Essbase (v11.1.1.3) calc script that I can't see to get to do what I want.
Here is my script:
SET UPDATECALC OFF;
SET UPTOLOCAL OFF;
SET AGGMISSG ON;
SET FRMLBOTTOMUP OFF;
SET CALCPARALLEL 3;
SET CALCTASKDIMS 2;
FIX ("Customer1","May Scenario","Working","FY11","May-MTD",@DESCENDANTS ("Total Product Revenue"))
CALC DIM ("Regions","Projects","Product Lines","Countries","Companies","Currencies");
ENDFIX
I have data in at level 0. Total Product Revenue is in my Accounts dim and the sub-accounts (level 0 members) under it are not rolling up even though all the consolidation operators are set to +. The reason I am doing the @DESCENDANTS("Total Product Revenue") is that with this calc script I just want to aggregate Total Product Revenue and the accounts under it, not the other members in the accounts dimension.
If I have missed anything please let me know.
Thanks,
Ken

One other note. The order you do things can also depend on what is dense and what is sparse. For example if your accounts dimensions is dense, you would want to fix on level zero members of the other dimensions and do the agg if it first. then do the fix on the members of the dimensions including accounts and calc dim the other dimensions. It is more efficient because you are only doing the calculation on the bottom level of the dense dimension then calculating the sparse dimensions

Similar Messages

Calc Dim vs IDESCENDANTS performance

I try to aggregate (LegalEntity, LegalEntityICP, EntityICP)
script1:
FIX(&vYear,&vScenario, &vVersion, ......)
___CALC DIM(LegalEntity, LegalEntityICP, EntityICP);
ENDFIX
Execute time: 1201sec
I execute the same slice in script2:
FIX(&vYear,&vScenario, &vVersion, ......)
__ FIX(@IDESCENDANTS(LegalEntity)
______@IDESCENDANTS(LegalEntityICP))
__________ @IDESCENDANTS("EntityICP",-1);
__ ENDFIX
__ FIX(@IDESCENDANTS(LegalEntity)
______ @IDESCENDANTS(EntityICP))
__________ @IDESCENDANTS("LegalEntityICP",-1);
__ ENDFIX
__ FIX(@IDESCENDANTS(LegalEntityICP)
______@IDESCENDANTS(EntityICP))
__________ @IDESCENDANTS("LegalEntity",-1);
__ ENDFIX
ENDFIX
Execute time: 623sec
Why CALC DIM work so long? When I use AGG execute time is more then 1800sec!!!!
I try to play with dim order, I move LegalEntity, LegalEntityICP, EntityICP on top (under dense dim) but result still the same.
But when I try to reduce agg slice it`s work stable.
FIX(&vYear,&vScenario, &vVersion, ......, @IDESCENDANTS(LegalEntityICP))
__ CALC DIM(LegalEntity, EntityICP);
ENDFIX
Execute time: 117sec
FIX(&vYear,&vScenario, &vVersion, ......, @IDESCENDANTS(LegalEntityICP))
__ AGG(LegalEntity, EntityICP);
ENDFIX
Execute time: 117sec
FIX(&vYear,&vScenario, &vVersion, ......, @IDESCENDANTS(LegalEntityICP))
__ FIX(@IDESCENDANTS(LegalEntity))
______ @IDESCENDANTS("EntityICP",-1);
__ ENDFIX
__ FIX(@IDESCENDANTS(EntityICP))
______ @IDESCENDANTS("LegalEntity",-1);
__ ENDFIX
ENDFIX
Execute time: 116sec

Wow, you are covering a bunch of different issues.
Here's the issue -- the number of blocks the code touches. The more it has to address, the slower it goes. There's no way round that.
There are a few things you can do:
1) Introduce parallel calcs (I am assuming a calc script, not a user-run Business Rule). See the [Tech Ref|http://download.oracle.com/docs/cd/E12825_01/epm.111/esb_techref/set_calcparallel.htm] for more information. The DBAG also has information on this -- you should understand the theory behind it before you go full speed on it.
2) Adjust your data and index cache (this one is only going to help a little). See the DBAG for more information on this. Do not dedicate your life to this one -- there are some quick hits that can help; going beyond will be an exercise of increasing effort for decreasing results.
3) Make sure you FIX on level zero of all of your other dimensions.
4) Think about what's in your block. Accounts and Time don't have to be the only ones. Do you know how densely populated your other dimensions are? Search this board for techniques to figure that out. The denser the dimension, the more likely it is to be in the block. Blocks size becomes a lot more plastic if you're on 64 bit Essbase.
5) Btw, you have the right idea when it comes to limiting the scope of the calc to get better times. I use that approach for different purposes in Planning Business Rules as shown in my blog.
Okay, enough of the general comments, I'll try your questions in order:
FIX(&vYear,&vScenario, &vVersion, ......)
___CALC DIM(LegalEntity, LegalEntityICP, EntityICP);
ENDFIX
Execute time: 1201sec^^^You're doing a full calculation of all dimensions. I'm a little surprised AGG is slower than CALC DIM as the times are usually reversed, but I wonder if you did a restructure between runs -- my guess is not so the AGG was maybe running on a fragmented db?
FIX(&vYear,&vScenario, &vVersion, ......)
__ FIX(@IDESCENDANTS(LegalEntity)
______@IDESCENDANTS(LegalEntityICP))
__________ @IDESCENDANTS("EntityICP",-1);
__ ENDFIX
__ FIX(@IDESCENDANTS(LegalEntity)
______ @IDESCENDANTS(EntityICP))
__________ @IDESCENDANTS("LegalEntityICP",-1);
__ ENDFIX
__ FIX(@IDESCENDANTS(LegalEntityICP)
______@IDESCENDANTS(EntityICP))
__________ @IDESCENDANTS("LegalEntity",-1);
__ ENDFIX
ENDFIX
Execute time: 623secSo it's faster, but of course you're not calculating level 0. Why? How do you even have any values at level 1? From the above AGG and CALC DIM tests I would guess. In any case, you're doing three passes through the database and these calcs are not going to work for you in the real world.
FIX(&vYear,&vScenario, &vVersion, ......, @IDESCENDANTS(LegalEntityICP))
__ CALC DIM(LegalEntity, EntityICP);
ENDFIX
Execute time: 117sec
FIX(&vYear,&vScenario, &vVersion, ......, @IDESCENDANTS(LegalEntityICP))
__ AGG(LegalEntity, EntityICP);
ENDFIX
Execute time: 117secI'm not sure why you repeated yourself, but you know your code is not calculating LegalEntityICP.
FIX(&vYear,&vScenario, &vVersion, ......, @IDESCENDANTS(LegalEntityICP))
__ FIX(@IDESCENDANTS(LegalEntity))
______ @IDESCENDANTS("EntityICP",-1);
__ ENDFIX
__ FIX(@IDESCENDANTS(EntityICP))
______ @IDESCENDANTS("LegalEntity",-1);
__ ENDFIX
ENDFIX
Execute time: 116secSo now you're taking a different tack, and still not calculating LegalEntityICP, which has to be calculated sooner or later.
You've proved that the fewer blocks your code addresses, the faster it runs.
However, since you need to calculate this data sooner or later, I'd go with one of the general recommendations (and I am sure others will chime in, too) and start working with those approaches.
Good luck!
Regards,
Cameron Lackpour

T400 LCD dim issue - Need help!!

I'm having a LCD dim issue with a T400. Have changed the LCD panel, LCD cable and systemboard but still having same issue. If i removed the lcd card, then the display is working fine. I've tested the lcd card in another working unit and it's working as well (means the lcd card is working). I use a working lcd card and plug into this T400 but LCD still dim.
I've try to switch the problematic lcd cable and lcd panel to a working systemboard and it kills the systemboard. Have try to switch a few things but still unable to find the root cause. Urgently need help on this. Any advice will be appreciated.
Model : 6475-RM5

hey bhoh
i suggest uninstalling your current graphic card driver, let windows install its own generic drivers and see if that makes any difference
WW Social Media
Important Note: If you need help, post your question in the forum, and include your system type, model number and OS. Do not post your serial number.
Did someone help you today? Press the star on the left to thank them with a Kudo!
If you find a post helpful and it answers your question, please mark it as an "Accepted Solution"!
Follow @LenovoForums on Twitter!
Have you checked out the Community Knowledgebase yet?!
How to send a private message? --> Check out this article.

How to speed-up CALC Dim and/or AGG Dim

Hello Everyone,
I am new to Essbase and apologize for such a generic query. I came across a calculation script that takes more than 10 hours to execute. The crux of the script is CALC Dim (DIM) where DIM is a dense dimension with 11 levels (and a lot of calculated members). Can anyone guide me about the approach to be adopted to optimize the script. I was fiddling around with CALCCACHEHIGH parameter in essbase.cfg file and the SET CACHE HIGH declaration in the script. Will that help?
Some details of the original script are outlined below. The basic optimization parameters are in place (like the dense dimensions are at the end of the FIX list etc)
Thanks.
Sayantan
Script details:
SET AGGMISSG ON;
SET CREATENONMISSINGBLK ON;
SET UPDATECALC OFF;
SET FRMLBOTTOMUP ON ;
SET CACHE ALL;
SET CALCPARALLEL 5;
SET CALCTASKDIMS 2;
SET LOCKBLOCK HIGH;
FIX (&pln_scenario,"BU Budget",&plan1_yr,@RELATIVE("Product",0), @RELATIVE("YearTotal",0),... etc
CALC DIM ("Account");

Hi,
Thanks for your suggestions. I will definitely try to implement them and post the results. Meanwhile, here's another script which should not take too long to run. However, this script runs for hours. Any suggestions would be great (this does not have the cache options implemented yet). I have added some more details about the dimensions involved.
Outline of the script:
/*Script Begins*/
SET UPDATECALC OFF;
SET CACHE ALL;
SET CALCPARALLEL 5;
SET CALCTASKDIMS 2;
SET NOTICE LOW;
SET MSG SUMMARY;
FIX (@ATTRIBUTE("Existing"),@Relative("DC",0),@RELATIVE("PCPB",0),&pln_scenario,"BU Budget",&plan1_yr,@RELATIVE("YearTotal",0))
FIX(@RELATIVE ("RM",0))
SET CREATENONMISSINGBLK ON;
"RMQ" = "DC wise Sales Volume"->"UBOM" * "RMQ per Unit SKU"->"All DC"->"YearAgg";
ENDFIX;
ENDFIX;
/*Script Ends*/
Dimension details: Evaluation Order which has been thought through.
Dimension Members Density
Account 352 Dense
Period 35 Dense
Version 3 Sparse
Scenario 8 Sparse
DC 7 Sparse
Year 9 Sparse
Entity 20 Sparse
Product 416 Sparse
BOM 938 Sparse

Problem in executing calc dim calculation command

why does calc dim does not work when xref function is used in account hierarchy......
while i was trying to use the said command essbase was giving error which specified "login credentials do not match"
and the log which created was" Error retrieving user by identity"

Read this...
http://forums.oracle.com/forums/ann.jspa?annID=599
and then post in the correct forum for your question (which to be honest I can't figure out myself as I haven't a clue what you're referring to)

Calc Sibling Issue

Hi I'm trying to calculate a KPI (Rate * Qty) where Rate is loaded against one LEV0, Member (Cost Centre) and Qty is loaded against all the other siblings (Cost Centre). Both Rate & Qty appear at LEV1, but as the aggregation performs the figure is overwritten. I've been thinking about adding some script to copy the Rate to all the other siblings but am struggling. Any thoughts, suggestions & pointers would be most welcome. The sibling have non-uniformed names so I was thinking of using a UDA against the Cost Centre containing the Rate. Thanks in advance Mark<img src="i/expressions/face-icon-small-confused.gif" border="0">

Here you are not aggregating the "3138".
Try the below script.
SET CACHE DEFAULT;
SET NOTICE LOW;
SET MSG SUMMARY;
/*SET UPDATECALC ON;*/
SET AGGMISSG ON;
SET FRMLBOTTOMUP ON;
FIX ("QTR3 2010", ACTUAL, YTD)
@IDESCENDANTS ("3138");
FIX(@IDESCENDANTS ("3138")
CALC DIM (ACCOUNTS, Country, Product, OECust, STCust);
ENDFIX
ENDFIX
FIX (ACTUAL, YTD)
&CurYear;
ENDFIX

Calc dim v. @descendants

Should there be any pratical difference between doing a calc dim v. doing a focused rollup at the top level?Harold

Members with formulae aren't calculated with @descendants???I think that they are, in fact @Idescendant is treated as a list of members, if there is a formulae, it is treated if you just write the member in a calc script.If you do not want to use formulaeuse the @AGG function that will only do consolidation.The main difference is that calc dim can be used with several dimension, with the order of calculation choosed by the kernel to speed the calculation.And with descendant you can select only a part of your dimension.RegardsErwan Le Pogampelp at analytic dot fr

Problem with Calc Dim

Hi, I'm getting pretty confused now... I'm trying to correct a modelbuilt by someone else a while ago (not much is working). Ineed to do a calc dim on a budget center dimension and for whateverreason, I receive an error message each time. I don't seeanything weird with that dimension... and I'm receiving an errormessage saying it is an Invalid Cal script syntax (but there is noerror in the syntax). Any idea??? Thank you Marie Vaillancourt

Oh, I'm still confused... The name is Function (we arecreative here on how to call budget center!), and for the alias Iused Functions and it works... Is Function means anythingelse for Essbase??? I can't change the name of the dimension,this model has been around for years and too many people are doingretreival on it.

Which is optimal one among AGG and CALC DIM??

Hi Frndz,
I knew the difference between AGG n CALC DIM but i'm not sure which is the optimal one.Is there any specific situation to use them when should we go for them.
Thanks

Hi John,
I am responding to this post after such a long period. But i found that this is perfectly relevant to the situation i am facing.
Actually we have been using the CALC DIM function for aggregation. Recently we replaced this by AGG as i read that AGG is more optimal when you are aggregating sparse dimensions with less that 6 levels. All the dimensions we are aggregating have less than 6 levels. But after using the AGG command my database size increased exponentially from 53G to 90G. This was the only change i did in the process. Then i cleared all data and imported level 0 and did the aggregation using CALC DIM again. Now the database size is back to normal.
I am not able to understand why this happened in my case. Even the rules were taking more time to run as compared to Calc Dim.
If you can please through some light on this.
Regards
Vikas

About consolidation: CALC DIM, AGG, @IDESCENDANTS, @ANCESTORS

 I have some question (and few doubt) about commands andfunctions for data consolidation 1) CALC DIM is available for both dense and sparse dimensionsand calculates member formula. It's right? 2) AGG is available for sparse dimension only and doesn'tcalculate memberformula, but it's faster than CALC DIM.It's right? 3) @IDESCENDANTS("X") consolidate from bottom level to"X" member (included). It's right?This function is available for both dense and sparse dimensionsor sparse dimension only? It calculates member formula? 4) @ANCESTORS("X") consolidate from "X"member (included) to top of hierarchy. It's right?This function is available for both dense and sparse dimensionsor sparse dimension only? It calculates member formula?

1. Correct. 2. Correct. 3. Correct, both Sparse and Dense, including member formulas. 4. Almost Correct: IANCESTORS(X) includes "X", ANCESTORS(X) only does the ancestors, not "X". Works on both Sparse and Dense, including member formulas.

Calc Dim Problem

Hi gurus,
i have a calcscript to clear data(replacing data with #missing) in particular combinations and aggregating the period dim by using Calc Dim.
Problem is,when i cleared data first time in Halfyearly2 it is only clearing data For Idesc of H2 and aggregating correctly with H1 data to YearTotal.
Now second time when cleared data in Halfyearly1 data clear is succesfull but comes to aggregation still i have data in Yeartotal though
descendants of H2 data and H1 data is missing.
Why i'm still having data in yeartotal though Idesc of H1 and Idesc fo H2 data is missing and also aggregating the period dim.
thanks in advance
Edited by: kailash on Sep 17, 2011 7:22 PM

Hi Kailash - this all sounds like normal Essbase BSO behaviour. You can control whether missing values aggregate up using the SET AGGMISSG command / 'Aggregate Missing Values' database settings. Check out the Tech Ref / DBAG / EAS Help sections:
http://download.oracle.com/docs/cd/E17236_01/epm.1112/esb_tech_ref/set_aggmissg.html
http://download.oracle.com/docs/cd/E17236_01/epm.1112/esb_dbag/dcaoptcs.html#dcaoptcs61358
http://download.oracle.com/docs/cd/E17236_01/epm.1112/eas_help/aggmissg.html
The brief explanation is that with AGGMISSG ON, where all child values are #Missing a calculation will roll them up to a #Missing value at the parent. With AGGMISSG OFF, where all child values are #Missing a calculation will not alter the parent value.
You have to be careful with using this globally if you sometimes load data directly to non-level-zero members, as values can then be overwritten.

Calc DIm

Hi All,
In our cube we have Accounts(Dense),period(Dense),Product(Sparse),Costcenter(Sparse),Scenario(Sparse),Version(Sparse),fund(Sparse),Year(Sparse),Projectyear(Sparse)
1.since accounts & period are dense, all its parents are dynamic calc. do we need to include them in CALC DIM
2. do we need to include year and project year in calc dim/Agg as the children do not agg into parent.
CALC dim (product,costcenter,actual,draft,fund,)
do we need to include them in Fix statment ....@levmbrs("year",0),@levmbrs("projectyear",0)...do we need to include theses 2 in fix....if we dont include will all years get calculated
this question is from the following thread,,.....but not satisfied with answers.....can someone throw some light on these questions...appreciate ur response.
Re: Batch Calc after dataload

If all the upper level members in dense dimensions are dynamic calc then you don't need to include them in calc dim.
For the sparse dimensions if they are straight aggregrations you can use the AGG function as well as CALC DIM
You don't have to include the non aggregating dimensions in your aggregation, you could just include them in a fix.
Cheers
John
http://john-goodwin.blogspot.com/

AGG and CALC DIM Essbase script recently started to grow our pag files

We have a Essbase script that does nothing but AGG and CALC DIM that ran fine for months in that it did not grow our Workforce cube. Starting in late Jan it started to grow its pag files. Workforce cube used to be 7 GB in Dec 2010, then it grew to 10GB today. I tested running it and it grew our pag files by 170MB 2nd time and then by 70MB the 3rd time I ran it. Has anyone seen this?

Thanks a million Cameron.
1) I do dense restructures every night - apparently that does not remove all defragmentation.
last questions:
2) I exported level zero, cleared all data, then imported level zero data. That should clear up all defragmentation, wouldn't it?
3) After importing level zero data, I ran a simple Calc Dim calc script on Accounts dim only on this Workforce BSO cube that is only 400MB. It took over 30 mins. On my second and third run of same calc script, it took 9 mins. My BSO cube grew a few MB. Can I assume that blocks have been build by first run and that all subsequent runs will stay around 9 mins since blocks have now been build?
Here is the calc script
SET CACHE HIGH;
SET UPDATECALC OFF;
SET CLEARUPDATESTATUS OFF;
SET LOCKBLOCK HIGH;
SET AGGMISSG ON;
SET CALCPARALLEL 3;
FIX (febscenario,Working)
FIX(@RELATIVE(TTC,0),@RELATIVE(TCI,0),@LEVMBRS("Project",0),@RELATIVE("Total Employees",0))
FIX(FY11, FY12 "Jan":"Dec")
FIX("HSP_InputValue","Local","USD")
CALC DIM ("Account");
CALC TWOPASS;
ENDFIX
ENDFIX /* &YearNext */
ENDFIX
ENDFIX
4) When I calc only FY11, it takes 3 seconds to calc on the first to 4th run of the above calc. However, when I calc FY12, it takes over 30 mins on first calc and 9 mins subsequently. Why is that? Should I use SET CALCONMISSINGBLK in my calc script?
5) I am running calc as Essbase admin user. The level zero text file I loaded is only 460MB. After calc, the BSO cube's pag files are only 420MB. We are thinking of calc'ing older scenarios for historical purposes but am not sure if that will degrade the calc performance. My experience has been that - increasing the size of the BSO cube by calc'ing will degrade future calc times. Is that your experience?
Edited by: Essbase Fan on Feb 25, 2011 9:15 AM
Edited by: Essbase Fan on Feb 25, 2011 9:17 AM

CALC DIM or AGG - Can we aggregate from higher levels?

Hello everyone,
We have a custom dimension called LOCATION, under which we have Continents ASIA and EUROPE. Under ASIA and EUROPE we again have countries (India & England) under which there are states. Now data may be entered at a Continent level or Country level. If we do a normal AGG or CALC DIM operation, the higher level data will get overwritten since aggregation is done on a bottom up basis from zero level members.
Can we aggregate from a higher level (say Country or Continent) in the dimension up to the Location level (i.e. override the default zero level up aggregation) ?
PS: Creating a dummy member would not be an elegant solution, since I have presented the problem in a much simplified way, and there are many level of hierarchies - and a dummy will be required under each hierarchy level.
Any suggestion would be of great help.
Thanks..
Sayantan

I know you are against creating dummy members but if you don't there is no way to know for sure you are aggregating correctly. Most people want to see the dummy members just so they know why the parent doesn't equal the sum of all the children.
We have a million+ member customer dim. Quite a few of them are loaded at the parent level. Our parent child hierarchy (not dim) gets built from the fact table+dim. So if the etl finds a record in the fact table that has children in the dim table it creates the dummy member to load the data to. This has worked well for us. Good luck.
Edited by: user7332747 on Apr 23, 2009 1:34 PM

Calc Dim vs Agg

to my understand when you want to agg up a Dense dimension you use Calc Dim in the Calc Script, and when you want to agg up a Sparse dimension in the calc Script you use the AGG statement
what is the different in the to process
Please advise

Does the definition of AGG not help from the documentation
"The AGG command performs a limited set of high-speed consolidations. Although AGG is faster than the CALC commands when calculating sparse dimensions, it cannot calculate formulas; it can only perform aggregations based on the database structure. AGG aggregates a list of sparse dimensions based on the hierarchy defined in the database outline. If a member has a formula, it is ignored, and the result does not match the relationship defined by the database outline."
Cheers
John
http://john-goodwin.blogspot.com/

CALC DIM Issue

Similar Messages

Maybe you are looking for