This content has been marked as final. Show 16 replies
If you just want to kill the session, then kill the ESSSVR process.
However, find out the root cause why XREF is making the session freeez.
There are business rules running on each database. Rutes are retrieving data form each database. After a while I see freezing xref sessions. I kill the essrv process from the task manager, but it is not a solution. Do you have anay idea for the reason of this xref problem?
^^^What exactly do you mean by that? Are there still other calc sessions running and these run alongside do you look at the running sessions and only see XREF functions running? Does their running impact anything else? Can you stop the Essbase databases in question? Are you sure you don't have small run on form save calcs that constantly fire these?
After a while I see freezing xref sessions.
Here's another thought -- have you tried converting what are likely dynamically calculated XREFs to stored XREFs and see what the difference is? I am not the world's biggest fan of dynamically calculated XREFs because of performance reasons.
Along with CL’s suggestion,
Xref is very sensitive to the member block and the order in which you have written source and target combination.
I have experienced that if you change the member block from denser member to less dense member, there will be drastic amount of change in the running time of business rule. Suggest you to mention the source and target combination in the outline order and try to keep the member block most dense dimension.
^^^ Huh? You mean if you make the target of an XREF a dense member versus a sparse member, calulating the sparse member is faster? How? The same block is pulled into memory (or created on the fly if stored)?
I have experienced that if you change the member block from denser member to less dense member, there will be drastic amount of change in the running time of business rule.
Or a more dense sparse dimension member is faster than a more sparse sparse dimension member?
That still doesn't make sense.
If you want to copy an account say P00010A from REV to EXP and the source and destination combinations are:
Accounts Period Dense3 Sparse 1 Sparse 2
REV P00010A All X1 All X2
EXP P00010A All X1 All NA
FIX on level 0 of sparse
X1 = @XREF(_REV_,X1,X2);
will take less time then
"P00010A" = @XREF(_REV_,"P00010A",X2);
You can anytime use reference cubes to imporve @XREF performace:
Cant tell you the exact differnce in time BUT was at least 4 or 5 times more.
Edited by: RahulS on Jun 19, 2010 8:13 PM
Edited by: RahulS on Jun 19, 2010 8:29 PM
Are you saying that if you declare a calc block on a smaller dense dimension, and then assign the data to a different, larger dense dimension it's faster than if you do it the other way around? And you do the calc block declaration to "FIX" the cross dim on the target side? And then depending on which way you declare the calculation block and the concomitant formula, it's faster one way or the other?
And you've benchmarked this across multiple databases? What's the percentage difference in performance?
I cannot understand the problem. When I check the sessions I dont see any calculation or report activities. But there are lots of xref sessions remaining from previous calculations or reports. Do you have another idea instead of using two or more planning databases for different modelling needs?
Are you any of the xrefs against dense members with two pass applied, if so I have seen issues where xref sessions end up in a endless loop, I ended up having to put an essbase configuration setting to get around it.
You can read about the setting and see if that is what you are experiencing :- http://download.oracle.com/docs/cd/E12825_01/epm.111/esb_techref/frameset.htm?forcealldensecalcon2passaccounts.htm
I put the essbase configuration setting in the essbase.cfg file.
I restarted the essbase services but it didnt work.
I see the same xref sessions....
This is my .cfg file (directory: D:\Hyperion\products\Essbase\EssbaseServer\bin )
; The following entry specifies the full path to JVM.DLL
BPM_Oracle_DriverDescriptor "MERANT OEM 5.2 64-BIT Oracle Wire Protocol"
BPM_DB2_DriverDescriptor "MERANT OEM 5.2 64-BIT DB2 Wire Protocol"
BPM_SQLServer_DriverDescriptor "MERANT OEM 5.2 64-BIT SQL Server Wire Protocol"
BPM_SQLServer_DriverDescriptor "SQL Server"
BPM_ORACLEBI_DriverDescriptor "Oracle BI Server"
Edited by: tarum on 19.Haz.2010 19:08
Can you run just one of these XREF calcs and get the hanging XREF calc?
If you convert the XREF to stored, does the calc still hang?
I cannot catch the hanging xref. It occures while retrieving data or report or running calc script.
Sometimes it doesnt occure. If the number of users in the system increases, I see the unkillable xref sesions.
The Planning application has two plan types. They work together, so there will always be dynamic passes.
There are always xref jobs on retrieving. But they shouldnt be hanged...
I have solved this issue. I changed the source of dynamic total members to my defauld cube. Now I have no xref freezing problem. But I have still performance problems with fiinancial reporting. Thanx all...
tarum wrote:I have the same problem. Can you describe in detail how did you resole this problem?
I changed the source of dynamic total members to my defauld cube.