Tag Archives: obiee linux

Admintool Check-in changes: Internal Assertion Error Condition

If you’re running OBIEE under 64-bit Solaris – this might be of use. I just want to add from myself – that it’s not a good idea to change repository in online mode.

Admintool Check-in changes: Internal Assertion Error Condition FALSE , file server/Utility/Generci/NQThreads/SUGThread.cpp, line 515 [ID 820803.1]

When checking in changes in Admintool, you are getting the error:

nQSError:28019 Near line 230: In the metadata expression … the following error occured nQSError 46036 Internal Assertion Error Condition FALSE , file server/Utility/Generci/NQThreads/SUGThread.cpp, line 515
Cause

This is a defect:
Bug 6652490: PSR:FUNC:ESSBASE: OBSERVED THE ERROR WHILE CHECK-IN OR SAVING RPD IN ONLINE MODE ?

Bug was logged for 10.1.3.3.2 with OBI server on Solaris 64 bits

Although the abstract mentions Essbase the bug is reproducible against any database.
But only when OBI is on 64 bits solaris platform.
It applies to all versions from OBI 10.1.3.3.1 and later.

Test case:
From Admin tool created the new rpd (i.e. physical layer) and Drag-Drop
the db to Business model & Presentation layer then tried to Check In / Save
form Admin tool in Online mode but I observed the below error form Admin tool
window as well as NQServer.log
Error Message:
[46036] Internal Assertion: Condition FALSE, file server/Utility/Generic/NQ
Threads/SUGThread.cpp, line 515.
2007-11-27 04:44:12
[46036] Internal Assertion: Condition FALSE, file
server/Utility/Generic/NQ
Threads/SUGThread.cpp, line 515

Off line mode able to check-in or saved sucessfully.

Also we only had the error on a Business Model that had been dragged and dropped from the physical.
Solution
The workaround is to modify the NQSConfig.INI file.
Change the “SERVER_THREAD_STACK_SIZE = 0;”
with “SERVER_THREAD_STACK_SIZE = 512 KB;”

and restart the OBI server

Increasing thread stack size (by setting SERVER_THREAD_STACK_SIZE to a bigger number) is the solution to this issue in all versions including 10.1.3.4.

Increasing thread stack size requires more memory from the server machine.
That is the only impact it should have. But increasing from 256k (default) to 512k is a minor change

This defect will be fixed in the next main release

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.

nQSError: 46073 – ANALYTICS TEMP FILES CANNOT BE LARGER THAN 2GB

While running a report, we receive the following error message: State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 46073] Operation ‘stat()’ on file ‘/u02/OracleBIData/tmp/nQS_28056_15671_77250638.TMP’ failed with error: (75) (HY000)

Watching the server as the report runs, a large file is created in the /OracleBIData/tmp directory. Once the file hits 2GB in size, the report generates the error. It appears that we are hitting a 2GB file size limitation.

Build:10.1.3.4.0 [1900]
LINUX Red Hat Enterprise Linux AS release 4 (Nahant Update 6) 2.6.9 67.0.7.ELsmp (64-bit)

Please let me know how to resolve this issue. thank you.
Cause
We’ve researched on this error and this issue has been logged as a BUG “BUG 6998143 – ANALYTICS TEMP FILES CANNOT BE LARGER THAN 2GB “.
According to BUG 6998143, in UNIX/LINUX env tmp files over 2 GB in size lead to an error. This bug was fixed for Window env in OBIEE 10.1.3.2, and has been fixed for UNIX/LINUX env in OBIEE 10.1.3.4.

Solution

Please note that a patch for BUG 5543386 – ANALYTICS TEMP FILES CANNOT BE LARGER THAN 2GB, for Linux is now available.

OBIEE Linux components

QUESTION 1) Whether all OBIEE 10.1.3.3 Infrastructure components can now be deployed exclusively on a Linux platform?

ANSWER: According to the Oracle Business Intelligence Infrastructure Installation and Configuration
Guide> Installing Oracle BI EE Infrastructure > Oracle BI Installer Screens and Prompts

There are restrictions on Installing Oracle BI Under Linux. Using the Custom installation choice, only the following components are available under Linux:

> Oracle Business Intelligence JDBC Driver
> Oracle Business Intelligence Systems Management
> Oracle Business Intelligence Server
> Oracle Business Intelligence Cluster Controller
> Oracle Business Intelligence Scheduler
> Oracle Business Intelligence Client
> Oracle Business Intelligence Presentation Services
> Oracle Business Intelligence Presentation Services Plug-in
> Oracle Business Intelligence Publisher

Therefore, this implies that that the other OBI components can only be installed on Windows.