Calc time vs. defragmentation

I have a database with an average cluster ratio of .44. If I export and reload my data, it will go to 1.0, but as soon as I calc it goes back to .44.Under my current data settings, this calc takes a mere 5.7 seconds to run and retrevial time is fine. In an effort to improve the cluster ratio, I played with my dense/sparse settings, changed my time dimension to sparse, and was able to get a .995 cluster ratio after calculation; the problem is now the calc script ran for 127 seconds which is 22x longer.I know that either calc time is minimal by Essbase standards, but I'm still curious which way is "optimal". I would think it is always best to take the enhanced performance over the academic issue of cluster ratio, but I'm concerned at what point this becomes more than an academic question. How imporant is the cluster ratio and what kind of implications are there for having a database that is more fragmented? Are there other things besides calc and retrieval time that maybe I'm not seeing on the surface that I should be concerned with. Since defragmentation should improve performance is it worth it to sacrifice some performance for less fragmentation? Of course as this database grows this will become more of an issue.Any input, thoughts and comments would be appreciated.

Just my humble opinion: Everybody's data has a different natural sparsity and rather than think in terms of 'fragmentation', think in terms of the nature of your data. If you made EVERY dimension sparse except for Accounts, and had only one member in Accounts, your database would consist solely of single-cell datablocks that are 100% populated - as dense as you can get. The trade-off is that you will have a HUGE number of these small, highly compact datablocks and your calc times would be enormous. As a general rule, you can take each of your densest dimensions in turn and make them "dense" in the outline until your datablocks approach 80k in size. The tradeoff is that not all cells in each datablock will be populated, but you'll have fewer datablocks and your calcs will zoom. Your goal is not to simply minimize the number of datablocks or to minimize the datablock size or to maximize the block density. You goal is to reach a compromise position that maximizes the utility of the database.A good approach is to hit a nice compromise spot in terms of sparse/dense settings and then begin optimizing your calcs and considering converting highly sparse stored dimensions to attributes and such. These changes can make a tremendous impact on calc time. We just dropped our calc time on a database from 14 hours to 45 minutes and didn't even touch the dense/sparse settings.-dan

Similar Messages

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

Reduce Calc Time

Afternoon everyone,
We load data into our cube monthly, and when running the calc on the database it can take between 2/3 days to complete. I appreciate that calc time can be determined by a wide variety of factors (number of dense/spare dims/members etc) - but looking at things from a system resource view:
The server has 8 CPU's.
With total memory = 4194303 (according to server information within Application Manager)
When calcing, approx 1500000 of memory is used.
The start of the calc script defines the following parameters: 'SET CALCPARALLEL 4; SET UPDATECALC OFF;'
Would increasing the 'SET CALCPARALLEL' parameter from 4 to 6 be a viable approach to trying to reduce calc time (especially given the amount of available resource on the server)??
The server wont be used for anything else during the calc.

CL wrote:
Are you running 64 bit or 32 bit Essbase?
32 bit maxes out at 4 CPUs for parallel calc; 64 bit can go to 8.
You might want to look at the number of task dimensions set for parallel calculations.
See: http://download.oracle.com/docs/cd/E10530_01/doc/epm.931/html_esb_techref/calc/set_calctaskdims.htm
And your calculator cache is going to impact parallel calcs as well.
All of this can go up in smoke if you have calculations that require Essbase to calculate in serial, such as cross dimensionals.
There are lots of other possibilities re performance.
1) Could the SAN/local drives be faster?
2) Do you need to calc the whole database (I have no idea what your db is, only that you mention a monthly calc -- is it for just one month?)
3) Partitioning the db by month<--This is probably a really good place to look although nothing is free.
4) Going to ASO
There are others as well.
I appreciate that thie above four thoughts are beyond your question, they're just food for thought.
Regards,
Cameron LackpourASO should be an option. It is much much faster rollup than BSO.

Calc time estimates, anyone?

I have a 13 dimension database that yields about 20GB of data after calculation.Block size is about 18KThe only calculation I run is a CALC DIM statement (I'd run a CALC ALL but I fix on members from some dimensions). The CALC DIM just consolidates each dimension (no member formulas and all consolidation tags are +)For my sparse dimensions, I have deep hierarchies (two, though, are flat).The database is reset and reloaded with data prior to calculation. Calculation time for one year's worth of data is 6 hours.That can't be right.Without necessarily telling me how to do it, can someone tell me what's the best calc time I should be able to achieve with some performance-tuning?

The calc time you should be looking after, shoud not exceed 1 hour.There is a way which you can bring down dramatically your calc time -however seeing the number of dims and data volume and considering your hardware, thats just about wright the time.OK, your best card in situations like this, is to use the Dynamic Calc atibute- resource, for upper level sparse members, it works miracles if you can do it wright- not affecting your reporting performance.However maybe there are dependencies in formulas (avrg) etc.The trick is to use the dyn calc in these formulas (make them dense), so they can calculate at the end.Remember the calc order in dyn calc is the oposite of regular agregations.Believe me it can make a huge difference, i use it in situations where depending the polarity of sparse dimension, cuted down the size tenfold and consequently calc times.Unfortunatelly noone is teaching thoroughly this great resource (dyn calc), so do not be scared at the beginning.You can contact me at [email protected] Yannis

Speed up calc times for compley member formulae

Hello together,
I am seeking to speed up calc time for one of the steps in a business rule. Besides the required dimensions (+ currency), the application includes custom dimensions for cost centre, products and distribution channel. The members for the currency dimension include EUR, GBP, USD, ..., Curnone (currency not relevant).
FIX (
FY12,
"Forecast",
"Final",
@LEVMBRS("Cost Centre",0),
@LEVMBRS("Products",0),
@LEVMBRS("Currency,0),
"Distribution Channel",
SET FRMLBOTTOMUP OFF;
"500400";
"500600";
SET FRMLBOTTOMUP ON;
ENDFIX
The member formula are:
500400 = 500000 * 400000
500600 = 500000 * 600000 -> Curnone
The accounts 400000, 500000 and 600000 are calculated themselves from member formulas including complex crossrefs. In order to speed things up, I tried to fix on the source and push the result onto the target account:
"500000"("500400" = "500000" * "400000")
which seems to speed up things considerably (I kept the setting FRMLBOTTOMUP ON). However, I'm not sure how to go about it for the second formula (the crossref is making it difficult). Does anybody have any advice? thanx in advance
Florian
Edited by: 943380 on 21.08.2012 01:56

I am sorry re my comment of "A + B" calculations as they are, uh, obviously not. Sometimes I wonder about my eyes, other days it's my brain that is in question, and then yet other days it's both...
Okay, so with that out of the way, let me ask if you must calculate everything all at once? Per your (hopefully closely read this time) comment, I am guessing this is for a Planning application. If so, is this a calculation that could be fired from a form, using that form's dimensionality? If it is, its scope could be limited and thus appear to be quicker.
Failing that, yes, CALCPARALLEL can help, but is probably not a great idea within the context of planner-initiated calcs as it will chew up CPUs even faster than single-threaded calcs.
Regards,
Cameron Lackpour
Edited by: CL on Aug 21, 2012 8:39 AM
I was just going through the tabs in my browser and I found the OP's post (I am sort of lazy when it comes to closing tabs). The OP's OP did have +'s instead of *'s. I thought I was losing what little sanity I have left.
https://docs.google.com/open?id=0B_qdhXKUMwSdTEFVcU1uSUlMWkk
I can't tell you how happy this makes me. :) Sometimes I wonder about my advancing years, but this time I wasn't totally bonkers.

Calc time issue.

Hello,My Calc script is taking little bit longer to complete. I am doing the following fix in my calc script. FIX (Actual, @RELATIVE("P&L Hierarchy",0), @RELATIVE(Headcount,0)) FIX(@DESCENDANTS ("Fiscal Year")) Amount ( IF (Amount == #Missing) IF (@ISMBR(&Fiscal_Year)) IF (@ISMBR(Aug:&Fiscal_Month)) IF (@ISMBR(AUG)) PreviousHeadcount = @SHIFT("Amount"->Jul, 1, "Fiscal Year"); ELSE PreviousHeadcount = @SHIFT(Amount,-1); ENDIF IF (PreviousHeadcount == #Missing) Amount = #Missing; ELSE Amount = 0; ENDIF ENDIF ELSE IF (@ISMBR(AUG)) PreviousHeadcount = @SHIFT("Amount"->Jul, 1, "Fiscal Year"); ELSE PreviousHeadcount = @SHIFT(Amount,-1); ENDIF IF (PreviousHeadcount == #Missing) Amount = #Missing; ELSE Amount = 0; ENDIF ENDIF ENDIF ) ENDFIXENDFIXIs this possible to do the above in the load rule. So I can eliminate this process from the calc to improve the calc time?Thanks in Advance.Ricky [email protected]

As the discussion is going about @CURRMBR() function, I would like to know are there any better function you could use instead of it to get the desired result especially when you want to find out where is the user making changes to the values and do some calculations on those cells. Is there a better way to catch that in Hyperion that would make your scripts more efficient and fast especially when you don't know the value to hard code it for calculation?
I do have some of my scripts/BR where I have used this function a couple of times, and it bothers me to think if that is going to make them inefficient and slow.
~ Adella
Edited by: Adella on Oct 21, 2011 11:25 AM

Increased calc time in Essbase cube

Hello-
I have an Essbase cube that just recently started experiencing very long calc times. The cube has been in a 9.3.1 environment for approximately 4 months and there haven't been any major additions to the data. Just adding Actuals every month. I had a CalcAll running in approximately 2 minutes and now it's running in 2+ hours. This essentially happened overnight. The size of the page file is 267Mb and index file is 25Mb. The data cache and index cache are currently set at 400,000Kb and 120,000Kb respectively.
This is a 7 dimensional cube with 2 dense dimensions... Accounts and Time. My block size is high due to the large amount of level 0 Accounts... 215,384Kb.
The number of index page writes and data block reads & writes is pretty high... 128,214 - 3,809,875. And the hit ratio on the data cache is .07.
I've tried adjusting the data cache and index cache both up and down... but with no success.
Any help would be appreciated.
Thanks!

Here are a couple of things to think about
How big is the databasename.ind file? How often do you restructure the database? if it is large, it means the database is fragmented (you can also look at the database stats to help figure it out) Every time you runn the calc all, you cause fragmentation.
If you have agg missing off it also increases the calc time. Also, you will find that calculation a loaded cube takes longer than if you have a cube with just level zero data.
If your database is not too big, you might try exporting level zero data, clearing the database, reloading the data and doing your calc all. (of course I would try this on a copy of the production database not the actual database itself). You might fined it quicker than your straight calc.
Since you do a straight calc all, you might also consider converting this to an ASO cube, you really get rid of the call all in total.

Auto calc time for shot duration, fails to change or appears to be in fixed mode.

Switching back and forth online to offline as you recommended is causing sync issues, additionally, the shot duration set for auto calc defaults back to custom so not certain if times are fixed, correct or not.
drgm

Downloaded Windows Assessment and Deployment Kit which contains the latest imagex program.
Running imagex.exe on the BASE7.WIM file on the second System Recovery DVD:
imagex.exe /info K:\PRELOAD\BASE7.WIM
ImageX Tool for Windows
Version: 6.2.9200.16384
Error opening file [K:\PRELOAD\BASE7.WIM].
The data is invalid.
The same error message is shown for BASE7.WIM, BASE8.WIM, and BASE9.WIM.
The other WIM files in the PRELOAD directory, BASE5.WIM, BASE6.WIM, BASE10.WIM, BASE13.WIM, BASE15.WIM, BASE17.WIM and BASE23.WIM, could be read by imagex without any errors.

Improving calc time..Issue using @CurrMBR in @MAXSRANGE

I have a calc ..If I use @CurrMBR(Entity)..It takes 11 min ..If I hardcode to lets say ....100 ,it takes 7 sec.
Can I modified the calc to work it more faster.
==========================
FIX("Plan", Working, Fy12, "Jan":"Dec", "LOC",
@REMOVE(@IDESC("Total_Function"), @LIST(@RELATIVE("Total_Function",0))),
@RELATIVE("Management_Reporting",0),Amount
"TestAc" = @MAXSRANGE (SKIPBOTH, "TestAc", @CHILDREN("100")) ; /*This takes 7 sec*/
/*"TestAc" = @MAXSRANGE (SKIPBOTH, "TestAc", @CHILDREN(@CurrMBR(Entity))) ;..This takes 11 min */
ENDFIX
=================
Thanks,

As the discussion is going about @CURRMBR() function, I would like to know are there any better function you could use instead of it to get the desired result especially when you want to find out where is the user making changes to the values and do some calculations on those cells. Is there a better way to catch that in Hyperion that would make your scripts more efficient and fast especially when you don't know the value to hard code it for calculation?
I do have some of my scripts/BR where I have used this function a couple of times, and it bothers me to think if that is going to make them inefficient and slow.
~ Adella
Edited by: Adella on Oct 21, 2011 11:25 AM

Diff between dyn calc time and stored time rollup using tblast

Results when using tblast, skip missing on loaded measure using stored time: Lvl0 Lvl0 Lvl0 Lvl12002-QTR 3 15 15 43 732002-QTR 4 2 #MI 3 52002 2 15 3 5and using dynamic time: Lvl0 Lvl0 Lvl0 Lvl12002-QTR 3 15 15 43 732002-QTR 4 2 #MI 3 52002 2 15 3 20Why is the 2002 lvl1 rollup different and is there a way to make stored look like dynamic? We are using XREF to access this measure, so need to use stored, but want 5 on the 2002 lvl1 rollup.

Any Ideas ?

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

Attribute calc and retrieval time

I have built an outline that consists of 7 standard dimensions. The last dimension is a base dimension with 15 attributes. This base dimension lists SSN# identifiers, but has their characteristics, such as age, race, rank, occupation, etc as attributes. There is a total of 100,000 different individuals all with varying combinations of characteristics. Right now the calc time is around 2 1/2 hours, and data retrieval on some characteristics takes several minutes. I know there are some obvious flaws in this design, but could someone tell me what they are and what I could do to correct them. I would greatly appreciate it.

Hi,go through this online documentation for optimizing the retrieval times based on the attibute dimensions position on the outline.http://www.essbase.com/doc/essbase-62/dbag/dindesin.htm#4364Jaya---Message Posted by hwinsch 3/25/02 07:13---Does anyone have suggestions on how to improve retrieval time when using attributes?

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

Run time error

Dear All,
During the transaction /n/sapapo/ccr (Reconsilation of transaction data) in client SCP 950, system displays the run time error which are attached herewith.
This is the activity a used to execute regularly (Daily) and first time i recieved this message - -
Runtime Errors         ASSERTION_FAILED
Date and Time          13.07.2007 10:13:37
ShrtText
The ASSERT condition has been violated.
What happened?
In the current application program, the system recognized a situation
    involving the ASSERT statement that should not occur. A runtime error
    occurred, either because there was no activation ID entered or because
    the ID of the activation mode used was set to "Cancel.
What can you do?
Print out the error message (using the "Print" function)
    and make a note of the actions and input that caused the
    error.
To resolve the problem, contact your SAP system administrator.
    You can use transaction ST22 (ABAP Dump Analysis) to view and administer
     termination messages, especially those beyond their normal deletion
    date.
is especially useful if you want to keep a particular message.
Error analysis
The following activation ID was used: "No checkpoint group specified"
If the FIELDS addition was used with this ASSERT statement, the content
    of the first 8 fields is as follows:
    " (not used) "
" (not used) "
" (not used) "
" (not used) "
" (not used) "
" (not used) "
" (not used) "
" (not used) "
How to correct the error
Probably the only way to eliminate the error is to correct the program.
You may able to find an interim solution to the problem
    in the SAP note system. If you have access to the note system yourself,
    use the following search criteria:
"ASSERTION_FAILED" C
"/SAPAPO/SAPLTIMESTAMP" or "/SAPAPO/LTIMESTAMPU08"
    "/SAPAPO/TIMESTAMP_DIFFERENCE"
    If you cannot solve the problem yourself and you wish to send
    an error message to SAP, include the following documents:
1. A printout of the problem description (short dump)
       To obtain this, select in the current display "System->List->
       Save->Local File (unconverted)".
2. A suitable printout of the system log
       To obtain this, call the system log through transaction SM21.
       Limit the time interval to 10 minutes before and 5 minutes
       after the short dump. In the display, then select the function
       "System->List->Save->Local File (unconverted)".
3. If the programs are your own programs or modified SAP programs,
       supply the source code.
       To do this, select the Editor function "Further Utilities->
       Upload/Download->Download".
4. Details regarding the conditions under which the error occurred
       or which actions and input led to the error.
System environment
SAP Release.............. "640"
Application server....... "scmprd"
    Network address.......... "172.16.10.47"
    Operating system......... "AIX"
    Release.................. "5.3"
    Hardware type............ "0002BFAAD700"
    Character length......... 16 Bits
    Pointer length........... 64 Bits
    Work process number...... 0
    Short dump setting....... "full"
Database server.......... "scmprd"
    Database type............ "ORACLE"
    Database name............ "SCP"
    Database owner........... "SAPSCP"
Character set............ "C"
SAP kernel............... "640"
    Created on............... "Jan 18 2006 20:47:39"
    Created in............... "AIX 1 5 00538A4A4C00"
    Database version......... "OCI_920 "
Patch level.............. "109"
    Patch text............... " "
Supported environment....
    Database................. "ORACLE 9.2.0.., ORACLE 10.1.0.., ORACLE
     10.2.0.."
SAP database version..... "640"
    Operating system......... "AIX 1 5, AIX 2 5, AIX 3 5"
Memory usage.............
    Roll..................... 16192
    EM....................... 196923232
    Heap..................... 0
    Page..................... 98304
    MM Used.................. 186636840
    MM Free.................. 1895288
    SAP Release.............. "640"
User and Transaction
Client.............. 950
    User................ "SCMATP"
    Language key........ "E"
    Transaction......... "/SAPAPO/CCR "
    Program............. "/SAPAPO/SAPLTIMESTAMP"
    Screen.............. "SAPMSSY0 1000"
    Screen line......... 6
Information on where terminated
    The termination occurred in the ABAP program "/SAPAPO/SAPLTIMESTAMP" in
     "/SAPAPO/TIMESTAMP_DIFFERENCE".
    The main program was "/SAPAPO/CIF_DELTAREPORT3 ".
The termination occurred in line 61 of the source code of the (Include)
     program "/SAPAPO/LTIMESTAMPU08"
    of the source code of program "/SAPAPO/LTIMESTAMPU08" (when calling the editor
     610).
Source Code Extract
Line SourceCde
31     lv_time_int_low      TYPE i,
   32     lv_timediff_int      TYPE i,
   33     lv_datediff_int      TYPE i,
   34     lv_time              TYPE t,
   35     ls_time              TYPE tstr_timestr.
   36
37 * check timestamp parameter
   38 * ASSERT NOT iv_timestamp_high IS INITIAL.
   39 * ASSERT NOT iv_timestamp_low IS INITIAL.
   40 * ASSERT iv_timestamp_low <= iv_timestamp_high.
   41   IF iv_timestamp_high IS INITIAL
   42   OR iv_timestamp_low IS INITIAL.
   43     RAISE invalid_parameter.
   44   ENDIF.
45   IF iv_timestamp_high < iv_timestamp_low.
   46     RAISE invalid_parameter.
   47   ENDIF.
48
49 * prepare timestamps
   50 * .. split into date and time integers
   51   ls_timestamp_high = iv_timestamp_high.
   52   lv_date_int_high = ls_timestamp_high-date.
   53   lv_time_int_high = ls_timestamp_high-time.
   54   ls_timestamp_low = iv_timestamp_low.
   55   lv_date_int_low   = ls_timestamp_low-date.
   56   lv_time_int_low   = ls_timestamp_low-time.
   57
58 * .. calc date diff
   59 * .. check against max. allowed integer difference
   60   lv_datediff_int = lv_date_int_high - lv_date_int_low.
>>>>>   ASSERT lv_datediff_int <= lc_datediff_intmax.
   62
63 * calc time diff
64   lv_timediff_int = lv_time_int_high - lv_time_int_low.
   65   IF lv_timediff_int < 0.
   66     ADD 86400 TO lv_timediff_int.
   67     SUBTRACT 1 FROM lv_datediff_int.
   68   ENDIF.
69
70 * calc total duration
   71   lv_duration_int = lv_datediff_int * 86400 + lv_timediff_int.
   72   lv_time = lv_timediff_int.
   73   ls_time = lv_time.
   74   ls_duration-hours   = lv_duration_int DIV 3600.
   75   ls_duration-minutes = ls_time-minute.
   76   ls_duration-seconds = ls_time-second.
   77
78   ev_duration_packed = ls_duration.
   79   ev_duration_integer = lv_duration_int.
   80 ENDFUNCTION.
Contents of system fields
Name     Val.
SY-SUBRC 0
SY-INDEX 0
SY-TABIX 1
SY-DBCNT 1
SY-FDPOS 6
SY-LSIND 0
SY-PAGNO 0
SY-LINNO 1
SY-COLNO 1
SY-PFKEY
SY-UCOMM
SY-TITLE CIF - Comparison/Reconciliation of Transaction Data
SY-MSGTY
SY-MSGID
SY-MSGNO 000
SY-MSGV1
SY-MSGV2
SY-MSGV3
SY-MSGV4
Active Calls/Events
No.   Ty.          Program                             Include                             Line
      Name
5 FUNCTION     /SAPAPO/SAPLTIMESTAMP               /SAPAPO/LTIMESTAMPU08                  61
      /SAPAPO/TIMESTAMP_DIFFERENCE
    4 FORM         /SAPAPO/SAPLCIF_DELTA3              /SAPAPO/LCIF_DELTA3F17                349
      COMPARE_ORDER_HEADER
    3 FUNCTION     /SAPAPO/SAPLCIF_DELTA3              /SAPAPO/LCIF_DELTA3U03                125
      /SAPAPO/CIF_DELTA3_COMP_ORDER
    2 FUNCTION     /SAPAPO/SAPLCIF_DELTA3              /SAPAPO/LCIF_DELTA3U01                871
      /SAPAPO/CIF_DELTA3_COMP
    1 EVENT        /SAPAPO/CIF_DELTAREPORT3            /SAPAPO/CIF_DELTAREPORT3              189
      START-OF-SELECTION
Chosen variables
Name
Val.
No.       5 Ty.          FUNCTION
Name /SAPAPO/TIMESTAMP_DIFFERENCE
IV_TIMESTAMP_HIGH
#q1###
02073899
2001125C
IV_TIMESTAMP_LOW
##q!####
00720899
2011125C
EV_DURATION_INTEGER
0
0000
0000
EV_DURATION_PACKED
000000
00000C
SYST-REPID
/SAPAPO/SAPLTIMESTAMP
    0000000000000000000000000000000000000000
    0000000000000000000000000000000000000000
    2545454254545444554452222222222222222222
    F31010FF310C49D5341D00000000000000000000
%_SPACE
0
0
2
0
LS_TIMESTAMP_HIGH
22000713182959
00000000000000
00000000000000
33333333333333
22000713182959
LV_DATE_INT_HIGH
803363
0042
0C23
LS_TIMESTAMP_HIGH-DATE
22000713
00000000
00000000
33333333
22000713
LV_TIME_INT_HIGH
66599
0002
0147
LS_TIMESTAMP_HIGH-TIME
182959
000000
000000
333333
182959
LS_TIMESTAMP_LOW
20071210182959
00000000000000
00000000000000
33333333333333
20071210182959
LV_DATE_INT_LOW
733021
0025
0BFD
LS_TIMESTAMP_LOW-DATE
20071210
00000000
00000000
33333333
20071210
LV_TIME_INT_LOW
66599
0002
0147
LS_TIMESTAMP_LOW-TIME
182959
000000
000000
333333
182959
SY-UNAME
SCMATP
000000000000
000000000000
544455222222
33D140000000
SCREEN-INPUT
1
0
0
3
1
LV_DATEDIFF_INT
70342
001C
0126
LV_TIMEDIFF_INT
0
0000
0000
SYST
#######################################Ō###############################################䵘 C#Ԁ##
    0000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000
    000000000000000000000000000000000000000100000000000000000000000000000000000000000000000D000500
    0000000000000000000000000000000800000004000000000000000000000000000000000000010900000005240000
    0000010200000000000001060100010C0000000C0000000002000000000000000000000000000B000001000803000C
SY-REPID
/SAPAPO/SAPLTIMESTAMP
    0000000000000000000000000000000000000000
    0000000000000000000000000000000000000000
    2545454254545444554452222222222222222222
    F31010FF310C49D5341D00000000000000000000
%_DUMMY$$
0000
0000
2222
0000
No.       4 Ty.          FORM
Name COMPARE_ORDER_HEADER
SYST-REPID
/SAPAPO/SAPLCIF_DELTA3
    0000000000000000000000000000000000000000
    0000000000000000000000000000000000000000
    2545454254544445444543222222222222222222
    F31010FF310C396F45C413000000000000000000
GC_APPEND_MODE
3
0
0
3
3
LS_FIELDS_TO_COMPARE-DUEDATE
    X
0
0
5
8
SYST
#######################################Ō###############################################䵘 C#Ԁ##
    0000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000
    000000000000000000000000000000000000000100000000000000000000000000000000000000000000000D000500
    0000000000000000000000000000000800000004000000000000000000000000000000000000010900000005240000
    0000010200000000000001060100010C0000000C0000000002000000000000000000000000000B000001000803000C
LS_APO_ORDER-ORDTYPE
5
0
0
3
5
GC_PLANNED_ORDER
5
0
0
3
5
LS_R3_ORDER-STATUSCNF
0
0
2
0
GC_ORDER_STATUS_NO_CONF
1
0
0
3
1
LS_APO_ORDER-STATUSCNF
0
0
2
0
GC_PRED_OUT_DEL
A
0
0
4
1
GC_TND_DELETE
CN
00
00
44
3E

Dear Sajit,
Go through the following OSS Notes:
<a href="https://websmp110.sap-ag.de/form/handler?_APP=01100107900000000342&_EVENT=REDIR&_NNUM=901957&_NLANG=E">901957</a>, <a href="https://websmp110.sap-ag.de/form/handler?_APP=01100107900000000342&_EVENT=REDIR&_NNUM=1036880&_NLANG=E">1036880</a>, <a href="https://websmp110.sap-ag.de/~form/handler?_APP=01100107900000000342&_EVENT=REDIR&_NNUM=1067414&_NLANG=E">1067414</a>
Regards,
Naveen.

Calc scripts are running slow(all of a sudden)

All of a sudden, for the past few days, we are noticing that all our calc scripts have been running very slow.
The same scripts used to run much faster earlier.
Has anybody seen this kind of scenario?
We did a RAM upgrade on the eas server, and have restarted all services.
Other than that, nothing has changed in our system.
Thanks.

It can be quite common for calcs to slow down over time, but there are some things to do to mitigate this.
1. Are you using Intelligent Calc? All things being equal (a very broad statement in essbase, since things are never equal) if there is more activity by users, it could affect how many blocks are marked dirty. This is probably not your issue, because a properly written calc wouldn't slow down much for this reason. I had to mention it though because I have seen an installation where their calc was 'Calc All' and they used intelligent calc to create the scope of the calc. (bad, very bad)
2. Do you perform DB restructures? (either explicity by Restructuring or by exporting level 0, clearing and import level 0 then agg) If this is not done on a regular basis (regular depends on the usage of the cube) then you could be experiencing fragmentation, which increases the size of the database, increasing run times.
3. Have you just added another fiscal year to the database? More data means bigger database.
RAM upgrade on the EAS server shouldn't affect calc times (unless essbase services are also running on the EAS server, then there might be something to it).
Most of these (and other) issues can be mitigated by applying proper scope to your calcs (Fix statements).
What environment are you running in? Windows or Unix?
New application?
What kind of time increases are we talking about here?
Robert

Calc time vs. defragmentation

Similar Messages

Maybe you are looking for