Retrieval impact of complex dynamic calc formulas

Hi,
How do you debug a dynamic calc member formula (complex), to tune it for high performance.
Thanks!

If you are using this member in any of the standard reports, Run the report including and excluding this member.
Then you can come to a conclusion whether it is acceptable or not.
If you feel it is not acceptable.
Check the formula for any if conditions or formulas are pointing to a group of sparse members. It requires to load multiple blocks for condition validation.
Recheck and try to minimize. Still problem persists, make the member stored and calculate in the batch.
Read the below link.
http://download.oracle.com/docs/cd/E10530_01/doc/epm.931/html_esb_dbag/frameset.htm?dcadynca.htm#dcadynca28382

Similar Messages

Data not replicated with partition and dynamic calc

HI
I am using Essbase 11.1.2.1.
I want to use a replicated pratition wetween two Essbase BSO applications.
But in my source application, I have to send an account ACCOUNT (level 1) with several stored members and 1 dynamic calc member with formula. Due to this Dynamic calc account, the partition doesn't work (data are not replicated).
How could I do?
Thanks
Fanny

You're right, dynamic calc account are not issues. I am using them in partition.
But py issue is there :
The source dimension is like this :
TAX (Dynamic Calc)
- 6xxxxxxx
- 6yyyyyyy
- 6zzzzzzz (Dynamic Calc) = formula
The target dimension is like this :
TAX
And so I need to send TAX (Source) to TAX (cible).
I don't think it is possible, but I would like a confirmation before using something else.
I hope it is clearer now.
thanks
Fanny

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.

Dynamic calc member formula problem

Hello Gurús!
We are using a member called "Full Year" that is a Dynamic calc with a member formula that calls another dynamic calc. For any reason, it is not working when we try to retrieve it from Excel Add-in.
Any ideas? Any problem for put a Dynamic Calc as member formula of antoher Dynamic calc?
Thanks for your time!
Regards,
Ariel

that can be the problem, depending on what dimension they are in, the order the two pass occurs could couse you issues. In cases like this I've had to put the entire calculation into the member I wanted to calculate and bypass the dependency

Dynamic Calc result different on each retrieval

We're currently testing version 6.5.6 on an NT server. We have two formulas set to Dynamic Calc. On the first retrieval, the formulas seem to retrieve fine. After several retrievals (maybe 20) they stop working. After this, each retrieval will give a different result. It seems to cycle through a few different incorrect answers before it starts over. If I modify the outline, restart services or reboot the box, it fixes the formulas for a while. However, after several retrievals, it reverts to its bad behavior.These formulas work consistently in 6.1p3a.We have already tried adding CALCFGDEPOPT FALSE to the Essbase config file to turn off event 28. It did not solve the problem.

Check your application log to see if the dynamic calc is dependent upon another dynamic calc member. If so you may need to make these members that calc incorrectly "Twopass" such that the first calculation is completed then the twopass calc is performed. You might also check the app log to make sure the dynamic calc members are not trying to perform the calcs off of members that have not been calculated yet. (i.e: they are below the cyn cal mbrs in the outline).

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;

Dynamic Calc Member in formula not working

Hello,
I am having an issue trying to calculate a dynamic calc member in a calc script.
Lets say this is our outline:
OC_GRANDPA (Dynamic Calc)
OC_PART1 (Dynamic Calc) (+)
Child1 (Calculated at top of calc script - STORED member) (+)
Child2 (Calculated at top of calc script - STORED member) (+)
OC_PART2 (Calculated in middle) of calc script - STORED member [NO CHILDREN] (+)
I need to use OC_GRANDPA in a formula
Final = OC_GRANDPA * .05 Rate;
It is giving me 0 when I run the calc the first time and works if i run it a second time. Is this issue two dynamic calc members? I tried making them twopass and no luck either. I really do not want to make them stored then do a calc dim (accounts) in my calc script. Any other ideas?? If I make my formula use the level 0 members and not the OC_GRANDPA it works but that is not good coding in case I added more Children Id like to automatically pick up. PLEASE HELP!!!! Thanks!

Thanks Cameron! I think I actually posted my mini hierarchy incorrectly as I am trying to put a formula on a different member under grandpa that has no children. Regardless it kept coming up zero -- all of the level 0 members are also calculated in the script. After much trial and error I ended up using the calc script for fomulas for the level 0's then I put a member formula on the member that I could not get to calculate in the script and also made it two pass. So then my calc script has the formulas for the level 0, a Calc Dim (Accounts) to perform the agg and calc the member formula then a calc two pass to calc yet another formula that uses this member.
I do however now have a different question regarding member formulas - do you know if they calculate top down or bottom up?

Use of calclockblock and dynamic calc cache? what is impact on essbase?

Hi,
Please suggest me use of calclockblock and dynamic calc cache?
When to use which?

Hello,
http://docs.oracle.com/cd/E12032_01/doc/epm.921/html_techref/config/calclockblock.htm
And here you can find the different settings on dyn calc cache:
http://docs.oracle.com/cd/E12032_01/doc/epm.921/html_techref/config/homecfgl.htm
good luck!

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.

Dynamic Calc processor cannot lock more than [100] ESM blocks during the calculation, please increase CalcLockBlock setting and then retry(a small data cache setting could also cause this problem, please check the data cache size setting).

Hi,
Our Environment is Essbase 11.1.2.2 and working on Essbase EAS and Shared Services components.One of our user tried to run the Cal Script of one Application and faced this error.
Dynamic Calc processor cannot lock more than [100] ESM blocks during the calculation, please increase CalcLockBlock setting and then retry(a small data cache setting could also cause this problem, please check the data cache size setting).
I have done some Google and found that we need to add something in Essbase.cfg file like below.
1012704 Dynamic Calc processor cannot lock more than number ESM blocks during the calculation, please increase CalcLockBlock setting and then retry (a small data cache setting could also cause this problem, please check the data cache size setting).
Possible Problems
Analytic Services could not lock enough blocks to perform the calculation.
Possible Solutions
Increase the number of blocks that Analytic Services can allocate for a calculation:
Set the maximum number of blocks that Analytic Services can allocate to at least 500.
If you do not have an $ARBORPATH/bin/essbase.cfg file on the server computer, create one using a text editor.
In the essbase.cfg file on the server computer, set CALCLOCKBLOCKHIGH to 500.
Stop and restart Analytic Server.
Add the SET LOCKBLOCK HIGH command to the beginning of the calculation script.
Set the data cache large enough to hold all the blocks specified in the CALCLOCKBLOCKHIGH setting.
Determine the block size.
Set the data catche size.
Actually in our Server Config file(essbase.cfg) we dont have below data added.
CalcLockBlockHigh 2000
CalcLockBlockDefault 200
CalcLockBlocklow 50
So my doubt is if we edit the Essbase.cfg file and add the above settings and restart the services will it work? and if so why should we change the Server config file if the problem is with one application Cal Script. Please guide me how to proceed.
Regards,
Naveen

Your calculation needs to hold more blocks in memory than your current set up allows.
From the docs (quoting so I don't have to write it, not to be a smarta***:
CALCLOCKBLOCK specifies the number of blocks that can be fixed at each level of the SET LOCKBLOCK HIGH | DEFAULT | LOW calculation script command.
When a block is calculated, Essbase fixes (gets addressability to) the block along with the blocks containing its children. Essbase calculates the block and then releases it along with the blocks containing its children. By default, Essbase allows up to 100 blocks to be fixed concurrently when calculating a block. This is sufficient for most database calculations. However, you may want to set a number higher than 100 if you are consolidating very large numbers of children in a formula calculation. This ensures that Essbase can fix all the required blocks when calculating a data block and that performance will not be impaired.
Example
If the essbase.cfg file contains the following settings:
CALCLOCKBLOCKHIGH 500 CALCLOCKBLOCKDEFAULT 200 CALCLOCKBLOCKLOW 50
then you can use the following SET LOCKBLOCK setting commands in a calculation script:
SET LOCKBLOCK HIGH;
means that Essbase can fix up to 500 data blocks when calculating one block.
Support doc is saying to change your config file so those settings can be made available for any calc script to use.
On a side note, if this was working previously and now isn't then it is worth investigating if this is simply due to standard growth or a recent change that has made an unexpected significant impact.

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

Shared members and dynamic calc

I am trying to replicate a new cube from current GL cube and wish to remove unused shared members if they have any impact on essbase.
2/3 of my accounts (dense) member is stored with the remainder being shared members. Shared members do not add to block size. But having so many of them, does it impact on calc scripts or retrievals or any other impacts?
Secondly, in accounts and divisions, we have four levels. except for level 0, the remaining levels are all dynamic calc. Division is sparse member. Its not advisable to have dynamic calc on dense dimension. What about sparse dimension like division? Will it be better to change level 2&3 to dynamic and change level 1 to store as well?
We have also been advised by our consultant to change accounts to sparse dimension considering the number of times we need to update outline for new members (stored and shared).
Dimension          Type          Stored     Shared
Measure               Dense     1378     796     rest
Time               Dense     106     13     rest
Year               Dense     9     8
Currency          Sparse     12     9
Scenario          Sparse     41     38
Market               Sparse     20     12
Division          Sparse     490     302     rest
Product               Sparse     635     308
Reportcode          Sparse     327     299

Hi,
Having shared members in dense hierarchy will not have much of impact on Cube size or retrieval performance.
but its always advisable to avoid unnecessary hierarchies (shared or stored or dynamic).
Having top level dense members as dynamic lines is a good design but having sparse dynamic calc will impact retrieval performance.
its not at all advisable to make sparse members as dynamic calc but if needed we can make sparse members with very few children as dynamic calc (or dynamic calc & store). yet again its not advisable to have a dynamic calc children to a sparse stored parent as this will affect the batch calculation while aggregating parent sparse member.
And as suggested by your consultant it is feasible to make the dimension getting modified more often, as a sparse dimension as this will reduce the restructuring time (sparse restructure will take less time compared to dens restructure).
But that alone cannot be considered as factor as there are many other factors to be considered for making a dimension sparse.
- Krish

Dense dim - dynamic calc

Hi
Essbase / Planning 11.1.2.1 - BSO db.
We are reviewing our app / db design following implementation last year. One of the things I have noticed is that one particular dense dimension has all members as stored (ie the non-level 0 members are not dynamic calc). Dimension has no member formulas, it is a straight roll up with consolidation for members consisting of (+ and ~).
I have changed this in our dev environment and ran some tests - calc time dramatically improved and total page file size halved (hard disk space becoming a slight issue for us so this is useful).
If we ran with this change, is there anything we need to do or be aware of, other than amending any business rules to exclude calc dims or partial aggs on the amended dimension? It seems a fairly low risk change, but looking for clarification that this is the case.....
The documentation on this states that any required combinations at non level 0 members will be calculated on the fly (eg a user retrieve). Is the same true if a non level 0 intersection is used within a business rule? (testing this on Sample Basic seems fine, again just looking for confirmation).
Thanks
JB

Yes, the same is true within a rule (i.e. if you reference an upper level in a dense dimension, Essbase will calculate it for you).
I think the only major functional issue that you haven't mentioned is that you need to be sure that none of your existing loads / calculations / user lock & send activities depend on being able to store a value at an upper level - for example, that you never load to a Quarter and then run a calc that allocates down to the Periods.

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

Optimizing a dynamic calc

Hi In our measures dimension we have a MTD member, which is a dynamic calc.The formula is:if (not @ISLEV (Time,0))"AIP-Sales";else@SUMRANGE("AIP-Sales",@ILSIBLINGS(@CURRMBR(Time)));endif;The problem is that it takes very long to fetch on this member.If I just put in if (not @ISLEV (Time,0))"AIP-Sales";else"AIP-Sales";endif;the fetch is instantaneous but whith the first fetch it takes 30 seconds even when fetching on an upper level member of time. Does Essbase evaluate the full expression regardles of the if statement?Time is a dense dimension, with the isolated dates beiing lvl 0, months lvl 1 then qtrs etc.The strange thing is that with the first formula it retrieves 3 blocks, even though there are no references outside the current block.With the second formula only 1 block is fetched as should be expected.Soren

Check out"Dynamic Time Series"in the Essbase documentation.Machismo

Retrieval impact of complex dynamic calc formulas

Similar Messages

Maybe you are looking for