Tag Archives: aggregation

BI Server Restart

If you want to see correct calculations – then a BI Server Restart might be required after you change Aggregation Rule for a column from SUM to AVG (or in any way).

I noticed that problem on Grand-Total calculations – it just wouldn’t perform correct aggregation for the column after RPD change in online mode (with Aggregation Rule – Default).

After services restart, OBIEE would perform correct grand-total aggregation.

Answers request causes BI server to crash

I found an interesting bug in metalink. I wish there were more specifics as to how complex the report was. I just had a similar Assertion error yesterday which I tried to solve by increasing STACK size. However, it seems as it’s possible to crash BI server with longer reports.

When a custom report is executed on Windows the following error is received: –

Error Codes: OPR4ONWY:U9IM8TAC:OI2DL65P
State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 46036] Internal Assertion: Condition FALSE, file .\NQThreads\SUGThread.cpp, line 515. (HY000)

However, on Linux the OBI Server crashes with this typical Stack Trace from the Core file generated: –

0 0xb427f9b2 in samem_details_800::ThreadAllocator<0>::Allocate
(this=0x86fcd00, Index=2) at threadallocator.cpp:443
443 { (gdb) bt
#0 0xb427f9b2 in samem_details_800::ThreadAllocator<0>::Allocate
(this=0x86fcd00, Index=2) at threadallocator.cpp:443 @ #1 0xb42784df in samem_details_800::ThreadAllocator<0>::allocate
(this=0x86fcd00, nBytes=20, nIndex=2,
pFile=0xb4a171dc “thirdpartysource/STLport-4.5/src/nqnodealloc.cpp”,
nLine=10) at threadallocator.cpp:966
#2 0xb4286098 in samem_details_800::Manager::Allocate (this=0xb429cac0, @ Bytes=20,
pFile=0xb4a171dc “thirdpartysource/STLport-4.5/src/nqnodealloc.cpp”,
nLine=10) at manager.cpp:469
#3 0xb4283dae in samem_800_allocate_dbg (Bytes=20, pFile=0xb4a171dc @ “thirdpartysource/STLport-4.5/src/nqnodealloc.cpp”, nLine=10)
at memoryallocator.cpp:160
#4 0xb49fbfb8 in NQNodeAlloc::allocate (__n=20) at @ thirdpartysource/STLport-4.5/src/nqnodealloc.cpp:10
#5 0xb721a1f3 in _SASSTL::allocator<_SASSTL::_Rb_tree_node
>::allocate (this=0x87f7bac, __n=1)
at thirdparty/include/stlport/stl/_alloc.h:372
#6 0xb721a02e in
_SASSTL::_STLP_alloc_proxy<_SASSTL::_Rb_tree_node*,
_SASSTL::_Rb_tree_node,
_SASSTL::allocator<_SASSTL::_Rb_tree_node > >::allocate @ (this=0x87f7bac, __n=1)
at thirdparty/include/stlport/stl/_alloc.h:514
#7 0xb72198c6 in _SASSTL::_Rb_tree, _SASSTL::less, @ _SASSTL::allocator >::_M_create_node (this=0x87f7bac, @ __x=@0xb0e23264)
at thirdparty/include/stlport/stl/_tree.h:243
#8 0xb673169d in _SASSTL::_Rb_tree, _SASSTL::less, @ _SASSTL::allocator >::_M_insert (this=0x87f7bac, __x_=0x0, @ __y_=0x8d895b8, __v=@0xb0e23264, __w_=0x0)
at thirdparty/include/stlport/stl/_tree.c:366
#9 0xb6730c6d in _SASSTL::_Rb_tree, _SASSTL::less, @ _SASSTL::allocator >::insert_unique (this=0x87f7bac, @ __v=@0xb0e23264)
at thirdparty/include/stlport/stl/_tree.c:412
#10 0xb6730499 in _SASSTL::set, _SASSTL::allocator >::insert @ (
this=0x87f7bac, __x=@0xb0e23264) at
thirdparty/include/stlport/stl/_set.h:137
#11 0xb672fe6b in RqNode::AddRqNodePtr (this=0x87f7b88, pRqNodePtr=0x8d999e8)
at server/Query/Optimizer/Request/Src/SQORRqNode.cpp:432
#12 0xb672e34e in SmartRqNodePtr (this=0x8d999e8, rhs=@0x8d995a0) at @ server/Query/Optimizer/Request/Src/SQORRqNode.cpp:55
#13 0xb66a7d17 in RqDerivedColumnReference (this=0x8d999b8, rhs=@0x8d99570, @ bNewIDs=false, bDeepCopy=true)
at server/Query/Optimizer/Request/Src/SQORRqExpr.cpp:1418
#14 0xb66a8898 in RqDerivedColumnReference::DeepCopy (this=0x8d99570, @ bNewIDs=false)
at server/Query/Optimizer/Request/Src/SQORRqExpr.cpp:1525
#15 0xb672e748 in RqNode (this=0x8d977b0, rhs=@0x8d97368, bNewIDs=false, @ bDeepCopy=true)
at server/Query/Optimizer/Request/Src/SQORRqNode.cpp:146
#16 0xb66a0d3c in RqExpr::RqExpr$base () at @ server/include/Query/Optimizer/Request/SQORRqNode.h:77
#17 0xb66d0f68 in RqExprCond::RqExprCond$base () at @ server/include/Query/Optimizer/Request/SQORRqList.h:33
#18 0xb66d6c58 in RqExprCondIsNull (this=0x8d977b0, rhs=@0x8d97368, @ bNewIDs=false, bDeepCopy=true)
at server/Query/Optimizer/Request/Src/SQORRqExprCond.cpp:1299
#19 0xb66d6e88 in RqExprCondIsNull::DeepCopy (this=0x8d97368, bNewIDs=false)
at server/Query/Optimizer/Request/Src/SQORRqExprCond.cpp:1342
#20 0xb672e748 in RqNode (this=0x8d8f878, rhs=@0x8d8f430, bNewIDs=false, @ bDeepCopy=true)
at server/Query/Optimizer/Request/Src/SQORRqNode.cpp:146
Cause
It appears that due to the complexity of the Expressions in the Answer Columns of the custom Report, the Expression Builder makes several recursive calls which eventually increases the Stack Size of the Thread until it reaches its maximum and it throws an Asertion Error.

On a Windows environment we have a check of the ‘LowStackCheck’ parameter which is not present in Linux and therefore it crashes the OBI Server giving a ‘sigsegv’ error.
Solution

Currently, there is no solution. The workaround is to re-design the report so that the Expressions are less complicated (e.g. Creating Measures that sum up at various combinations of Dimension Levels that allows the Users to avoid creating the complex Formulas in Answers and performs well)

This looks like a major change in the code is required to fix this type of behavior and therefore we will not be able to fix this until at least our 11.x release.

Using aggregate tables produce incorrect Year-to-date at the lowest levels.

Applies to:
Business Intelligence Server Enterprise Edition – Version: 7.9.5 [AA 1900] – Release: V7
Information in this document applies to any platform.
Symptoms
The user is modelling Time Series functionality (Todate) with aggregated dimensions and aggregated facts using BI Server 10.1.3.3.2.

You have created aggregate tables. You have both Logical Dimension and Fact tables mapped to the Aggregate tables.
In Answers you have built a report using the Dimension Hierarchy, which has the measures Sales and Sales YTD. When you drilldown in the report, the measures show the correct figures, until you get to the lowest level where the Sales YTD results are incorrect.
Cause

The cause of this incorrect aggregation when you drilldown to the lowest level of the hierarchy has been determined to be an incorrect sql being generated. The incorrect sql generated lacks the
SUM..GROUP BY

The main difference is that when you are at the lowest level of the aggregate table it doesn’t use “SUM..GROUP BY” in it’s core query.

The issue has been determined to be a Bug, as per Engineering who reviewed the issue.

Solution

However a workaround was provided for this specific customer scenario that resolved the issue. With the implementation below which engineering tested and verified the SUM and Group by was generated in the sql when drilling into the lowest level of the hierarchy.


I created a dimension that I just created in the business model and added the additional dimension to the content filter for the problem fact source. That resulted in SQL generation with a SUM clause. My workaround was used just for the problem query submitted. I did not even join the new dimension to the fact table.

So I would recommend creating a virtual dimension in the physical and business model layers. It should not be exposed in the presentation catalog.

Check box “data is dense”

When viewing the properties of a fact column in OBIEE, there is a check box “data is dense” when aggregating by dimension is chosen. What does this check box do? I’m not sure if this only applies to multi-dimensional sources or not.

Solution

This is generally used for FIRST/LAST aggregation rules where data is dense across the time dimension, e.g. inventory values for every period. SQL generation is optimized in this case.