Retrive time with Dynamic Calc

Hi Experts,
My users run a large smart view report which works well
However, when they change one of the member on the query to DC member (dense)
Then the retrieve takes forever and they getting network error from smart view.
I try to figure out , how can I improve the retrieve time on my BSO app, focusing on DC issues
I try to increase the data cache, index cache, retrieval buffer and sort.
I add command of DYNCALCCACHEMAXSIZE and the retrieve doesn’t getting better.
In addition, can you pls help me understand the app log file,
Here’s what happen after I ran the report, maybe it will lead
To the problem:
[Mon Aug 06 02:41:03 2012]Local/Orac///1768/Info(1200481)
Formula for member [YTD USD Display] will be executed in [TOPDOWN and CELL] mode
[Mon Aug 06 02:41:03 2012]Local/Orac///1768/Info(1012710)
Essbase needs to retrieve [1] Essbase Kernel blocks in order to calculate the top dynamically-calculated block.
[Mon Aug 06 02:41:03 2012]Local/Orac///1768/Info(1012736)
The Dyn.Calc.Cache for database [Main] can hold a maximum of [242] blocks.
[Mon Aug 06 02:41:03 2012]Local/Orac///1768/Info(1012737)
The Dyn.Calc.Cache for database [Main], when full, will result in [allocation from non-Dyn.Calc.Cache memory].
[Mon Aug 06 02:41:03 2012]Local/Orac///1768/Info(1019018)
Writing Parameters For Database [Main]
[Mon Aug 06 02:41:03 2012]Local/Orac///1768/Info(1019017)
Reading Parameters For Database [Main]
[Mon Aug 06 02:41:05 2012]Local/Orac///1768/Info(1070013)
Index cache size ==> [307200000] bytes, [37500] index pages.
[Mon Aug 06 02:41:05 2012]Local/Orac///1768/Info(1070014)
Index page size ==> [8192] bytes.
[Mon Aug 06 02:41:05 2012]Local/Orac///1768/Info(1070081)
Using buffered I/O for the index and data files.
[Mon Aug 06 02:41:05 2012]Local/Orac///1768/Info(1070083)
Using waited I/O for the index and data files.
[Mon Aug 06 02:41:05 2012]Local/Orac///1768/Info(1019019)
Reading Data File Free Space Information For Database [Main]...
[Mon Aug 06 02:41:05 2012]Local/Orac///1768/Info(1006025)
Data cache size ==> [512000000] bytes, [9359] data pages
[Mon Aug 06 02:41:05 2012]Local/Orac///1768/Info(1006026)
Data file cache size ==> [0] bytes, [0] data file pages
[Mon Aug 06 02:41:05 2012]Local/Orac///1768/Info(1080053)
Free space recovery skipped. Estimated free space recoverable by RecoverDbFreeSpace: [11068706640] bytes
[Mon Aug 06 02:41:05 2012]Local/Orac///1768/Info(1024033)
Missing Database Config File [E:\Hyperion\AnalyticServices\APP\Orac\Main\Main.cfg], Query logging disabled
[Mon Aug 06 02:41:05 2012]Local/Orac///1768/Info(1203135)
Starting the Data Mining Framework
[Mon Aug 06 02:41:05 2012]Local/Orac///1768/Info(1203136)
Data Mining Framework successfully initialized.
[Mon Aug 06 02:41:05 2012]Local/Orac///1768/Info(1200551)
Allocated TRIGMAXMEMSIZE: [4096] Bytes.
[Mon Aug 06 02:41:05 2012]Local/Orac///1768/Info(1013205)
Received Command [Get Database Volumes]
[Mon Aug 06 02:41:05 2012]Local/Orac///1768/Info(1013205)
Received Command [Set Database State]
[Mon Aug 06 02:41:05 2012]Local/Orac///1768/Info(1019018)
Writing Parameters For Database [Main]
[Mon Aug 06 02:41:05 2012]Local/Orac///1768/Info(1019018)
Writing Parameters For Database [Main]
[Mon Aug 06 02:41:05 2012]Local/Orac///1768/Info(1013205)
Received Command [Get Database State]
[Mon Aug 06 02:41:05 2012]Local/Orac///1768/Info(1013205)
Received Command [Get Database Info]
[Mon Aug 06 02:41:05 2012]Local/Orac///1768/Info(1013205)
Received Command [SetApplicationState]
[Mon Aug 06 02:41:06 2012]Local/Orac///1768/Info(1019010)
Writing Application Definition For [Orac]
[Mon Aug 06 02:41:06 2012]Local/Orac///1768/Info(1019011)
Writing Database Definition For [Main]
[Mon Aug 06 02:41:06 2012]Local/Orac///1768/Info(1019022)
Writing Database Mapping For [Orac]
[Mon Aug 06 02:41:06 2012]Local/Orac///5132/Info(1013210)
User [essadmin] set active on database [Main]
Pls help me find out how can I overcome this.
Many thanks,

I'll add on to Dan's comment that you very much need to test the dynamic calc (if indeed that is the problem) in the proper context.
Amusing but painful story:
I was once tasked with reducing calc time on a BSO database. i saw long ugly stored member calcs. Hah! I cleverly converted them to dynamic and calc times dropped. No one told me (and I didn't ask) how they were to be reported. There were thousands of instances of this member on the Excel sheet. What had been a nice fast retrieve dropped to five minutes. Whoops.
Take your pain wherever you like -- if you are reading multiple blocks to do the calc (my guess) nothing on earth is going to make it fast. Why make it dynamic in the first place? How many times is the member retrieved? Is it all in the block or, as i guessed, across multiple blocks?
Last comment -- again (this is getting boring) I agree with Dan -- caches are not, usually, the source of any performance joy and it always comes down to design.
Regards,
Cameron Lackpour

Similar Messages

Problem with Dynamic Calc members in calc script

Hi
i wrote a calc script which calculates the value of acct2 which is dependant on the value of acct1 that is calculated from acct0 as bellow:
FIX(
M1
acct1(
acct1=acct0->M2;
acct2=acct1->M2;
ENDFIX
the value of the intersection of M1->acct0 is 100 as input ,what i wanted from this calc script is the acct2->M1 to be 100 after executing the script once
but the fact is i have to run it twice to get the expected result.
the outline is like this:
M:
M2 Dynamic calc M2=M0+M1
M0 Stored
m1 stored
Account:
acct0 stored
acct1 stored
acct2 stored
Can anyone tell me the reason and how to solve it?
Edited by: user10450070 on 2011-1-25 上午1:38

Is acct1 correct after one run of the calculation, but acct2 incorrect? If so, it's because Essbase is calculating them both at the same time (parallel), whereas it has to be forced to calculate acct1 first and acct2 second. You can do this with separate fixes as below:
FIX(M1)
acct1=acct0->M2;
ENDFIX
FIX(M2)
acct2=acct1->M2;
ENDFIX
Or, you can you can force it into calculating in serial mode:
SET CALCPARALLEL 0;
FIX(M1)
acct1=acct0->M2;
acct2=acct1->M2;
ENDFIX
Sabrina
Edited by: SabrinaD on Jan 26, 2011 7:56 AM

Help with Dynamic Calc

Hello, could someone help me why after creating the dynamic calc member below, our calc script somehow get stuck/ ran very very slow...
Below is currently our Hierararchy for Division dimension:
Division Dimension
Division Rollup ( Never Share)
Division 1 ( Never Share)
Division a (Never Share) level 0
Division b (Never Share) level 0
Division c (Never Share) level 0
Division 2 (Never Share)
Division d ( Never Share) level 0
Alt_Division without cd (Dynamic Calc) ...and the member formula I did is
="Division Rollup" - "Division c" - "Division d" ;
After I refresh, the Alt_Division without cd went fine, calculated correctly when I retreive in Essbase Escel , however, the big problem was, when we run our aregular Essbase calc scripts, it somehow got stuck with Alt_Division without cd member and the calc went very very slow almost to the point that it just stopped calcing.
Could you please let me know if there is something wrong with my dynamic calc member above... Should the Alt_Division dynamic calc should not be a sibling of the Division Rollup member? or I could not use the "Division Rollup" member .
Could you please recommend a better way of writing the dynamic calc member ( and it's position in the Hierarchy) ... without me aggregarting the dbase ...( I like dynamic calc since it aggs on the fly).
Please advise.
Thanks.

Few Things...
I am assuming Division is a sparse Dimension. A Dynamic Calc member formula on a Sparse dimension member will surely take lots of time.
Suggestion 1:
Create an Alternate hierarchy sharing c and d. Change the consolidation operators to get the C - D at Alt_Hierarchy.
Suggestion 2:
Make the member Store and put the desired calculation in a Calculation script rather than having it as a dynamic calc member formula.
Hope this helps.
Madhavi

Retrieval performance become poor with dynamic calc members with formulas

We are facing the retrieval performance issue on our partititon cube.
It was fine before applying the member formulas for 4 of measures and made them dynamic calc.
The retrieval time has increased from 1sec to 5 sec.
Here is the main formula on a member, and all these members are dynamic calc (having member formula)
IF (@ISCHILD ("YTD"))
IF (@ISMBR("JAN_YTD") AND @ISMBR ("Normalised"))
"Run Rate" =
(@AVG(SKIPNONE, @LIST (@CURRMBR ("Year")->"JAN_MTD",
@RANGE (@SHIFT(@CURRMBR ("Year"),-1, @LEVMBRS ("Year", 0)), @LIST("NOV_MTD","DEC_MTD")))) *
@COUNT(SKIPNONE,@RSIBLINGS(@CURRMBR ("Period")))) + "04";
ELSE
IF (@ISMBR("FEB_YTD") AND @ISMBR ("Normalised"))
"Run Rate" =
(@AVG (SKIPNONE, @RANGE (@SHIFT(@CURRMBR ("Year"),-1, @LEVMBRS ("Year", 0)),"DEC_MTD"),
@RANGE (@CURRMBR ("Year"), @LIST ("JAN_MTD", "FEB_MTD"))) *
@COUNT(SKIPNONE,@RSIBLINGS(@CURRMBR ("Period")))) + "04";
ELSE
"Run Rate"
=(@AVGRANGE(SKIPNONE,"Normalised Amount",@CURRMBRRANGE("Period",LEV,0,-14,-12))*
@COUNT(SKIPNONE,@RSIBLINGS(@CURRMBR ("Period"))))
+ "Normalised"->"04";
ENDIF;
ENDIF;
ELSE 0;
ENDIF
Period is dense
Year is dense
Measures (normalised) is dense
remaining all sparse
block size 112k
index cache to 10mb
Rertrieval buffer 70kb
dynamiccalccahe max set to 200mb
Please not that, this is partition cube, retriving data from 2 ASO, 1 BSO underline cubes.

I received the following from Hyperion. I had the customer add the following line to their essbase.cfg file and it increased their performance of Analyzer retrieval from 30 seconds to 0.4 seconds. CalcReuseDynCalcBlocks FALSE This is an undocumented setting (will be documented in Essbase v6.2.3). Here is a brief explanation of this setting from development: This setting is used to turn off a method of reusing dynamically calculated values during retrievals. The method is turned on by default and can speed up retrievals when it involves a large number of dynamically calculated blocks that are each required to compute several other blocks. This may happen when there is a big hierarchy of sparse dynamic calc members. However, a large dynamic calculator cache size or a large value of CALCLOCKBLOCK may adversely affect the retrieval performance when this method is used. In such cases, the method should be turned off by setting CalcReuseDynCalcBlocks to FALSE in the essbase.cfg file. Only retrievals are affected by this setting.

Essbase : Order evalution with dynamic Calc : Account x Scenario

Hi everybody,
I'm trying to calculate a variation N / N-1 in % for All Accounts.
basically : %/ N-1 = (Actual- Actual N-1) / Actual N-1 - I create a scenario.
I create a scenario %_N_1 which is Dynamic Calc.
"%_N_1" = ("ACTUAL" - @MDSHIFT( "ACTUAL" , -1 , "Year" , ))/@MDSHIFT( "ACTUAL" , -1 , "Year" , )*100;
But with agregated Accounts (which are dynamic calc also), Essbase sums the % ... which is wrong !!!
Question : How could we set the priority between Scenario and Account for Dynamic Calculation.
regards,
ps : I want not to put this calculation in Financial Reporting, because there are a lot of reports that use this measure : %_N_1 !

Two-pass Calc
You should basically put this on every formula that is a % to make sure it happens after the aggregation stuff.
It get's tricky if you did two-pass on two pass but I believe you aren't using two-pass so you should be good to go

Trouble with Dynamic Calc Scenario

We have built a dynamic Calc scenario in our first 11.1.2 Planning environment that works fine in web forms; Forecast vs Prior Forecast Version. However, when we created our second environment the dyanmic scenario is now causing errors with the web forms. I am getting the generic Data form is invalid, check log for details.
I have isolated the problem to this one scenario. We have three other dynamic scenarios on the form and they work fine.
The formula on the scenario below which is not working does reference another dynamic scenario (Prior Forecast Version, which is working).
Forecast vs Prior Forecast (Scenario not working)
"Forecast" - "Prior Forecast Version";
Prior Forecast Version works fine and here is that formula:
if (@ISMBR("Final"))
"Forecast"->&FcstPF;
elseif (@ISMBR("Final_Jul"))
"Budget"->"Final";
else
@PRIOR("Forecast", 1, @RELATIVE("Version", 0));
endif;
The Prior Forecast Version is before the Forecast vs Prior Forecast in the outline.
I have checked the formulas and settings on each one and they are the same in both environments. We used LCM to build the second environment.
Any suggestions on where to look next?
I am not finding anything in the planning logs that seems to help, do I need to turn on auditing first to get information from the planning logs when you get the generic Check Planning Log for Details message?
Thanks.

I haven't check the essbase log but will do so. I thought I checked the correct planning log, but looking at the path I was using, I might have been looking for the log in the wrong place. I was using the path from the troubleshooting guide but it was the diagnostic logs and maybe that is only the correct one when we have auditing turned on.
Help on the path to the correct planning log would be great. I was looking in middleware/user_projects/epmsystem1/diagnostics/logs
Thanks.

Problem at calculation time, when using Dynamic Calc measures

Hello, We are using Essabse v6.5 and we want to upgrade to v7.1. we are performing some tests, in order to check that the Cubes we have created in 6.5 are working properly in v7.1. the problem that we are experiencing is that the calculation time for the cubes that have dynamic calc members has exploaded to 10 times more, compared to what it took at version 6.5. Do you have any idea why this happens. (also we are still using the old client "Application Manager") Furhermore, I have set up 2 cubes that are the same, except the 1st has dynamic calc memebers, whereas the 2ns has not. I perform calcualtions with the SET MSG DETAIL; and receive the following: CUBE (A) with Dynamic Calc Total Block Created: [4.3720e+03] Blocks Sparse Calculations: [8.0620e+03] Writes and [2.5338e+05] Reads Dense Calculations: [2.8000e+01] Writes and [2.8000e+01] Reads Sparse Calculations: [6.0202e+06] Cells Dense Calculations: [1.1476e+06] Cells CUBE (B) withOUT Dynamic Calc Total Block Created: [4.3720e+03] Blocks Sparse Calculations: [4.3720e+03] Writes and [3.5887e+04] Reads Dense Calculations: [2.8000e+01] Writes and [2.8000e+01] Reads Sparse Calculations: [6.0202e+06] Cells Dense Calculations: [1.1476e+06] Cells Question: Why does Cube (A) has more Sparse Calculations than Cube(B) ???? thanx

Yes, all the settings were exactly the same. See following: - Data Cache (note: we are NOT using the Data File Cache) - Index Cache - Index Page - Commit Block Interval - Cache memory Locking - Access Mode = buffered IO - Data Compression = Bit-Map encoding - Two Pass Calculatino = ON - Aggregate Missing Values = ON - CFG file Is there any new settings in 7.1 that I must configure? Is there any settings that I cannot see through the old client Application Manager, which is important? Must I install the new client in order to be able to configure correctly the Outline/Cube? Thnkx

Dynamic Calc, 2 Pass with Attributes!

Hi there,We have an Occupancy KPI within our Measures dimension, that works off the following member calc:(("Agency"/"Occupancy")/"Actual"->"DayInMonth"->"DummyHome")*7;This is set with <Dynamic Calc> <Two-Pass>This works great accross our cost centres until we start to use attributes within the ADD-In. Then the figures are shown as #Missing - Nuts!Any ideas would be welcomeMany Thanks in advanceMark

Are you also trying to pull dynamic time series or any other dynamically calculated member? If every other intersection is stored, I would expect this to work. However, if you attempt to pull, say Q-T-D(&CurrWk), then a #Mi result is quite possible, and unavoidable (depending on your outline).

Substitution variable in Dynamic Calc

Hi,
We are using Essbase 9.3.0 on Windows and are seeing this behavior in our BSO cubes.
When we use a substitution variable in a Scenario member with Dynamic Calc (not store) setting, after the first retrieve, if we change the value of the substitution variable, the subsequent retrieves do not generate updated results.
I suspect that the value is cached in the Dynamic Calculator Cache, and for some reason does not track changes in Substitution Variables to know that the value must be re-calculated. Here is what I see in the Application log -
[Mon Aug 09 10:31:51 2010]Local/App1/db1/user1/Info(1020055)
Spreadsheet Extractor Elapsed Time : [0.032] seconds
[Mon Aug 09 10:31:51 2010]Local/App1/db1/user1/Info(1020082)
Spreadsheet Extractor Big Block Allocs -- Dyn.Calc.Cache : [4] non-Dyn.Calc.Cache : [0]
This says that 4 blocks were used from the Dynamic Calc Cache, and none from outside it. Does this mean that existing blocks were read and not re-populated?
If I make a change to the formula, wherein I hard code the value of the sub var and perform the retrieve, then the value is updated. Subsequent retrieves, after restoring the formula still returns the updated results.
My question is, is this expected behavior? Or am I doing something /reading something wrong?
Thanks,
Andy

when a subst variable value is changed... to use the value in member formula or calc script, the concerned application has to be restarted...
- Krish

Input data into dynamic calc in Planning forms

Hi guys,
Have someone tried to combine these two requirements:
1. to have upper level members dynamic calc
2. to give users the ability to input data into those upper level members through Planning forms.
I need to do that in order to pass inputted values into HBR, and allocate those values to the leaf level across multiple dimensions. I need those members dynamic calc because otherwise I would need to aggregate data across 7 dimensions and that takes too long. Those allocations are suposed to happen constantly and are the main purpose of application.
I know you can have dummy stored members that correspond the uper level dynamic members, but then the user will have input forms without current data and will be required to check reports/forms with dynamic calc members prior to updating data.
I wonder if it is a realistic task to change jsp files that generate those forms, so that data can be inputed into the form, but instead of passing it to Essbase cube to send it to relational database.
P.S.
This is related to the thread I opened about optimizing recalculation time:
Recalculatiion takes much longer than initial calculation
I received a lot of valuable advices that would definitely work in other situations, but in my case they seem to contradict either user concurrent access or performance requirements.
Thanks a lot!
Dmitry

Hi Glenn,
I think i found a workaround for this, or may be i am missing something. I will replicate my hierarchies so that one hierarchy will have uper level stored members, and another dynamic calc. Once user loads the form it will run on-load script that will copy data from corresponding dynamic calc to stored slice. The updated data will be alocated to the leaf level, but will never be aggregated. Since reporting is done from ASO cube i only care about the leaf level and current selection in the form.
Thanks!

Dynamic Calc Member with Formula to Calculate a Rolling 13 Year

I have to create a rollup in my time dimension that will have 13 members representing each month of a 13 rolling forecast. I am having trouble setting this up as dynamic calc members with a formula assigned to it. For example, on of the members has the following formula.
As you can see, I am referencing several substitution variables since I want to make this as most dynamic as possible without having to make any changes to the formula member. Only making changes to the substitution variable. Any help would be much appreciated.
IF((@ISMBR(&Current_Year)) AND (&Act_RF_Last_Month == "Jan"));
"RTM 6" = @MDSHIFT(&Act_RF_Last_Month, -1, "Years", , 5, "Period",);
ELSE #Missing;
ENDIF
IF((@ISMBR(&Current_Year)) AND (&Act_RF_Last_Month == "Feb"));
"RTM 6" = @MDSHIFT(&Act_RF_Last_Month, -1, "Years", , 5, "Period",);
ELSE #Missing;
ENDIF
IF((@ISMBR(&Current_Year)) AND (&Act_RF_Last_Month == "Mar"));
"RTM 6" = @MDSHIFT(&Act_RF_Last_Month, -1, "Years", , 5, "Period",);
ELSE #Missing;
ENDIF
IF((@ISMBR(&Current_Year)) AND (&Act_RF_Last_Month == "Apr"));
"RTM 6" = @MDSHIFT(&Act_RF_Last_Month, -1, "Years", , 5, "Period",);
ELSE #Missing;
ENDIF
IF((@ISMBR(&Current_Year)) AND (&Act_RF_Last_Month == "May"));
"RTM 6" = @MDSHIFT(&Act_RF_Last_Month, -1, "Years", , 5, "Period",);
ELSE #Missing;
ENDIF
IF((@ISMBR(&Current_Year)) AND (&Act_RF_Last_Month == "Jun"));
"RTM 6" = @MDSHIFT(&Act_RF_Last_Month, -1, "Years", , 5, "Period",);
ELSE #Missing;
ENDIF
IF((@ISMBR(&Current_Year)) AND (&Act_RF_Last_Month == "Jul"));
"RTM 6" = @MDSHIFT(&Act_RF_Last_Month, -1, "Years", , 5, "Period",);
ELSE #Missing;
ENDIF
IF((@ISMBR(&Current_Year)) AND (&Act_RF_Last_Month == "Aug"));
"RTM 6" = @SHIFT(&Act_RF_Last_Month,-7);
ELSE #Missing;
ENDIF
IF((@ISMBR(&Current_Year)) AND (&Act_RF_Last_Month == "Sep"));
"RTM 6" = @SHIFT(&Act_RF_Last_Month,-7);
ELSE #Missing;
ENDIF
IF((@ISMBR(&Current_Year)) AND (&Act_RF_Last_Month == "Oct"));
"RTM 6" = @SHIFT(&Act_RF_Last_Month,-7);
ELSE #Missing;
ENDIF
IF((@ISMBR(&Current_Year)) AND (&Act_RF_Last_Month == "Nov"));
"RTM 6" = @SHIFT(&Act_RF_Last_Month,-7);
ELSE #Missing;
ENDIF
IF((@ISMBR(&Current_Year)) AND (&Act_RF_Last_Month == "Dec"));
"RTM 6" = @SHIFT(&Act_RF_Last_Month,-7);
ELSE #Missing;
ENDIF

We use similar logic but its in a calc script, not a dynamic formula.
Here's an example of what we do:
FIX (&Year, &Scenario)
IF (@ISMBR("JAN"))
"Average Usage%" = @AVG(SKIPBOTH, @MDSHIFT("Usage %"->"DEC"->&actYear, -1, "Year",), "Util %"->"JAN"->&actYear);
ELSEIF
ENDFIX
Another example in a different database:
IF (@ISMBR("JAN")) ((@MDSHIFT("Fees"->APR,-1,YEARS,)+@MDSHIFT("Fees"->MAY,-1,YEARS,)+@MDSHIFT("Fees"->JUN,-1,YEARS,)+@MDSHIFT("Fees"->JUL,-1,YEARS,)+@MDSHIFT("Fees"->AUG,-1,YEARS,)+@MDSHIFT("Fees"->SEP,-1,YEARS,)+@MDSHIFT("Fees"->OCT,-1,YEARS,)+@MDSHIFT("Fees"->NOV,-1,YEARS,)+@MDSHIFT("Fees"->DEC,-1,YEARS,)+"Fees"->JAN)/10)*12;

Slow calc time with SET CREATEBLOCKONEQ OFF for block creation

Hello everyone,
I have a problem with the slow execution of one of my calc scripts:
A simplified version of my calc script to calculate 6 accounts looks like this:
SET UPDATECALC OFF;
SET FRMLBOTTOMUP ON;
SET CREATEBLOCKONEQ ON;
SET CREATENONMISSINGBLK ON;
FIX (
FY12,
"Forecast",
"Final",
@LEVMBRS("Cost Centre",0),
@LEVMBRS("Products",0),
@LEVMBRS("Entities",0)
SET CREATEBLOCKONEQ OFF;
"10000";"20000";"30000";"40000";"50000";"60000";
SET CREATEBLOCKONEQ ON;
ENDFIX
The member formula for each of the accounts is realtively complex. One of the changes recently implemented for the FIX was openin up the cost center dimension. Since then the calculation runs much slower (>1h). If I change the setting to SET CREATEBLOCKONEQ ON, the calculation is very fast (1 min). However, no blocks are created. I am looking for a way to create the required blocks, calculate the member formulas but to decrease calc time. Does anybody have any idea what to improve?
Thanks for your input
p.s. DataStorage in the member properties for the above accounts is Never Share

MattRollings wrote:
If the formula is too complex it tends not to aggregate properly, especially when using ratios in calculations. Using stored members with member formulas I have found is much faster, efficient, and less prone to agg issues - especially in Workforce type apps.We were experiencing that exact problem, hence stored members^^^So why not break it up into steps? Step 1, force the calculation of the lower level member formulas, whatever they are. Make sure that that works. Then take the upper level members (whatever they are) and make them dynamic. There's nothing that says that you must make them all stored. I try, wherever possible, to make as much dynamic as possible. As I wrote, sometimes I can't for calc order reasons, but as soon as I get past that I let the "free" dense dynamic calcs happen wherever I can. Yes, the number of blocks touched is the same (maybe), but it is still worth a shot.
Also, you mentioned in your original post that the introduction of the FIX slowed things down. That seems counter-intuitive from a block count perspective. Does your FIX really select all level zero members in all dimensions?
Last thought on this somewhat overactive thread (you are getting a lot of advice, who knows, maybe some of it is good ;) ) -- have you tried flipping the member calcs on their heads, i.e., take what is an Accounts calc and make it a Forecast calc with cross-dims to match? You would have different, but maybe more managable block creation issues at that point.
Regards,
Cameron Lackpour

Problem with a calc involving @MDSHIFT and Dynamic Calc

Hi all,
I have a problem with the calculation of a member in a calc script. The formula of this member is :
"R70100"
IF(@ISMBR("M01"))
("T_008"->"Cumul"->"HT"+"T_003"->"Cumul"->"HT")*"AVCT_PR" - @MDSHIFT("R70100" -> "Cumul" -> "HT" -> "M12", -1, "Year", );
ELSE
("T_008"->"Cumul"->"HT"+"T_003"->"Cumul"->"HT")*"AVCT_PR" - @MDSHIFT("R70100" -> "Cumul" -> "HT", -1, "Period", );
ENDIF
- R70100 is a member of a dense dimension.
- T_008, T_003 and AVCT_PR are spare and stored.
- "Cumul" is a dynamic member which allow us to calculate cumulative from monthly.
- Time is split into two dimensions, Period and Year.
The problem is that the @MDSHIFT doesn't seems to work with the dynamic calc as the monthly result is the cumulative correct value. I didn't know what is wrong BUT each time I launch the script, values are good for one more month.
After one run, for example, I obtained this result :
!http://zenon.apartia.fr/stuff/200910070001.GIF!
Two run later, here are the news values :
!http://zenon.apartia.fr/stuff/200910070002.GIF!
Any idea on what going on and how to correct it ? Thanks !
Frédéric

A couple of questions for you:
1) Do you need the overhead of @MDSHIFT when you are only moving in one dimension? Wouldn't @PRIOR have been a lot easier? At least this is true for the ELSE condition.
2) Could you post just the results of the @MDSHIFT calculation so we (okay, this may be just for me, it's still breakfast time here and not enough coffee has been ingested yet to read a spreadsheet without recourse to the formulas) can better see the impact?
3) Have you tried using your code against a non-dynamic member? Does it make a difference?
Regards,
Cameron Lackpour

Dynamic Calc with if statements

Hello
I have a dynamically calced member who’s calculation depends on what member of another dimension the user is looking at, so in the calc we have several if statements using the @ismbr function. Our calc looks something like this:
If (@ismbr("Dim Member1") or @ismbr("Dim Member2"))
     Big Calc 1;
elseif (@ismbr("Dim Member3") or @ismbr("Dim Member4"))
     Big Calc 2;
elseif(@ismbr("Dim Member5"))
     Big Calc 3;
else
     Last Big Calc;
endif;
What we are seeing is that when we run a query that should fall through to the final else (IE the Last Big Calc;) every calculation under every if is being executed. To come to this conclusion we did the following. Each of the calculations is pretty complex and can take a bit of time to run so we replaced Big Calcs 1-3 with very simple calcs that are very fast and ran the same query again, and while the result returned was the same (IE the result of Last Big Calc) it returned 10 times faster.
I’m pretty naive about most things Essbase but I’m stuck with trying to solve this problem so I was hoping that someone might have run into something like this before or knows how I can solve it. Any insight will be very appreciated.
I’m using Essbase 9.3.1 and my cube is a BSO cube.
Thanks
David

Is it possible that the intermediate results can be put into "memo" members as a stored value, being "on call" so they don't get re-calculated as often?
This wouldn't eliminate the source of the issue, but it would return the results much faster during retrieves. The downside of course is that these values would extend the calc time, so it may not be the right answer for you.
Alternative #2: Make the final value stored, using a calc script to iterate the formulas only for the appropriate member sets, eliminating the duplicate efforts but moving the calculations away from the D-C realm.
-Doug.

Issues using two-pass with dynamic time series?

Is there any issues with using Dynamic time series [Q-T-D(May)] on a dynamic calc account which is defined as two-pass and has time balance property associated with it.
The account is defined as "Dynamic Calc"+"Two-pass"+"TB First" and it works fine, but does not fetch result when used with DTS as Q-T-D(May). But, the same seems to work fine without the two-pass calc option on.
Thanks in advance,
cheers,
revati

Hi Revati,
Yes u r right, I also tried with same scenario as you mentioned.
Y-T-D values are not fetching with Twopass,but in that case Twopass is not required because of that member already having "Dynamic calc".
so you can proceed with Dynamiccalc without twopass.
               Actual
               Sales     COGS     Margin     Margin %     Margin1 %
New York     Cola     Jan     6000     5500     500     8.333333333     8.333333333
          Feb     5500     5000     500     9.090909091     9.090909091
          Mar     7000     6500     500     7.142857143     7.142857143
          Qtr1     18500     17000     1500     8.108108108     8.108108108
With twopass          Q-T-D(Mar)     18500     17000     1500     8.108108108     #missing
with out twopass          Q-T-D(Mar)     18500     17000     1500     8.108108108     7.142857143
Praveenkumar.I
TSPL
mobile:09975686985

Retrive time with Dynamic Calc

Similar Messages

Maybe you are looking for