We’re still working with Oracle to investigate this further, but it appears that in order to get “correct” numbers when running OBIEE against Oracle OLAP, you need to turn off the OBIEE cache. To do so, you need to edit NQSConfig.INI inside the VMWare image. This isn’t as hard as it sounds. You can map a drive easily in the startup screen. Then edit G:\biee\10.1.3.2\OracleBI\server\Config\NQSConfig.INI (assuming your mapped drive is drive G) using any editor such as NOTEPAD.EXE and change the following:
######################################
# Query Result Cache Section
#
#####################################
[ CACHE ]
ENABLE = YES;
to
ENABLE = NO;
You’ll need to bounce the BI Server service after doing this. We’ll work on more guided instructions, but I at least wanted to get this out to you all now while we complete our research.
Hello Dan,
Just wondering whether unsetting the “Cacheable” property of the cube table in the RPD physical layer would be sufficient?
Changing the setting in NQSConfig.ini will disable caching for the entire OBIEE server, not just the OLAP connection. This could be a problem if your RPD connects to other sources in addition to the OLAP.
Regards,
Martin
Martin,
That’s exactly the solution we are working on right now. Thanks for pointing it out, however. Obviously, we’re also trying to understand why this is even necessary, but that’s another issue.
Dan
Just a quick update with a status on this issue. We have found tracking this down to be quite elusive. There are multiple ways to prevent this problem from occuring. One is to turn off the cache in NQSConfig.INI (which is actually a good idea anyway when demoing this software since we care so much about performance!). I did find that even turning off the Cacheable property in the RPD did not solve the problem. Also, changing the query to not require extraneous columns that are not used seems to solve the problem too! But then again, just when we think we’ve isolated the exact cause of the problem, it will mysteriously disappear, confounding our attempts to definitively “solve the problem”. That leads us to wonder if we caused the problem for ourselves in the first place. The only measures that appear “wrong” are ratio measures such as % Chg from Last Year. Let us know if you see this in the wild.
Dan