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/

Similar Messages

  • 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

  • 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

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

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

  • 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

  • What is wrong with this? AGG on sparse and Calc Dim on Dense?

    I have this....
    FIX(@IDESC(Sparse parent member))
    CALC DIM(Dense,Dense,Dense);
    Agg(Sparse,Sparse);
    ENDFIX
    No formulas in outline ....just followed simple perf impro technique.....as they say...agg faster on sparse.Syntatically is abstly right but result is not right......?
    Whats the catch? do i need to attend some basic classes???:-P
    Edited by: 961729 on Sep 26, 2012 10:27 PM

    Thanks Cameroon and Tim for your reply!
    Perhaps i should have listed more details...my bad!. Anyway my idea was to know if two of below fixes produce same result...?
    Fix(Sparse)
    Calc dim(Dense,Dense,Dense,Sparse,Sparse);
    Endfix
    Fix(Sparse)
    Calc dim(Dense,Dense,Dense);
    Agg(Sparse.Sparse);
    Endfix
    Coming to my earlier mentioned fix....well that is the conclusive fix of my allocation script..I have two children of version dim. One is used for allocation and other to put adjustment. So in that fix iam just aggregating all dim for version dim (allocation +adjustment).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               

  • 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

  • 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

  • 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

  • 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/

  • 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

  • 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)

  • Problem with Calc Dim

    <p>Hi,</p><p> </p><p>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???  </p><p> </p><p>Thank you</p><p> </p><p>Marie Vaillancourt</p>

    <p>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.</p>

  • 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.

  • Using AGG/CALC DIM function in the BSO target cube of Transparent Partition

    Hi,
    Is it possible to use AGG("dimension") on a dimnesion in the BSO cube that is a target cube for a BSO-BSO Transparent Partition/
    I have created the partition area with 3 dimensions, one being 'Source'. 90% of the source members are being refrenced from source to target via that transparent partition. But I still have the 10% Source members in the target cube that need to roll up to the 'Source"(along with the 90%) for correct aggregation.
    When I try to use AGG("Source") in a FIX statement that's within the partition area, I get the following error:
    Error: 1042013 Network error [10054]: Cannot Receive Data
    Error: 1042012 Network error [10054]: Cannot Send Data
    Can I not aggregate the dimension in the Target cube?
    Thanks

    Hi,
    We have the same problem.
    I try to create transparent pertition between BSO (as a source) and ASO (target) and have the same warning message.
    Just to eliminate possible effect of outline complexity I created very simple DBs with the following outlines:
    __For ASO:__
    mes1
    mes2
    Measures
    prd1
    prd2
    Products
    Actual
    Adjustment
    Scenarios
    __For BSO:__
    mes1
    mes2
    Measures
    prd1
    prd2
    Products
    Adjustment
    Scenarios
    In addition to the message I have the following behavior - ASO has data in "Actual" scenario, BSO has data in "Adjustment" scenario. Before partition definition I can see the data in the right places, but when the partition created, Actual data disapeared from report of ASO. It is still in the database, and when the partition removed - appears again.
    Any ideas?
    Thank you in advance,
    Alexey

Maybe you are looking for