Category Archives: OBIEE 11G

You have an OBIEE 10.1.3.4.1. instance and a lot of folders and requests for the Administrator user.
You upgrade to 11.1.1.3.0, using the ua.bat tool. It finishes as complete and there are no errors in the the Upgrade Assistant (ua) log files:
$OBIEE_HOME/upgrade/logs
For example
C:\OBIEE_11g\Oracle_BI1\upgrade\logs
In OBIEE 11.1.1.3.0, when you log in as Administrator and go to the Catalog option, you are not able to see any folder or request.

Cause

The upgrade process, ua.bat, is not transferring the folders and request for the Administrator user.
This is due to the bug below
What were you trying to do?
---------------------------
Upgrade both repository and web catalog from 10.1.3.4.1 to 11.1.1.3.0.
What should have happened?
--------------------------
You should be able to see all folders and request you had in 10.1.3.4.1 after
upgrading to 11.1.1.3.0.
What actually did happen?
-------------------------
For the Administrator account, after running the ua.bat for upgrading and
finishing without error, when you log in with this account, it does not
display any folder or document for the Administrator user in 11.1.1.3.0,
there are a lot of folders and request in 10.1.3.4.1.
What are the symptoms of the problem?
-------------------------------------
You have a web catalog in 10.1.3.4.1. When you log in as Administrator in
this version you see a lot of folders and request for that user.
You upgrade to 11.1.1.3.0 using the ua.bat utility. It finishes fine,
completed without error. In the upgrade log file you can find some warnings
that I am not sure they are related to this issue. You log in as
Administrator in 11.1.3.0 and you cannot see any folder or request.
What changes have been made to the technical environment recently?
------------------------------------------------------------------
None.
-------------
Suggested workaround is the following:
In 10.1.3.4.1.
===============
1) In Administration Tool, create a new user, 'new_account', under Manage-Security (if you are using other Security option, add the new user there).
2) Using Catalog Manager, copy the content of the Administrator user into the new one.
For instance:
/-users-administrator
into
/-users-new_account
3) Upgrade the Web Catalog using the ua.bat:

$ORACLE_HOME/bin/ua.bat

In 11.1.1.3.0.
==============
4) Using Catalog Manager, copy the content of the 'new_account' user into the Administrator one.
For instance:
/-users-new_account
into
/-users-administrator
5) Connect to OBIEE as Administrator and check you are able to see all folders and requests.

Goal

– When Oracle supplies an OBIEE patch, its README file always says to replace the VERSION.TXT file on the [Oracle Home] directory with the one included.

– When you apply a second, unrelated patch to the environment why would we want to replace the entire VERSION.TXT file?

– Would you append the text in the second patch’s VERSION.TXT file to the first?

– How will this display on the Settings > Administration window when it displays the information in the Product Information box?

– Are OBIEE Patches cumulative?

Solution

This has been confirmed by Development.

1. Version.txt file should be replaced, following instructions in the readme files of each patch.
New version.txt file should not be appended to the end of the current one, but it should replace the current one.

2. Currently, for 10G versions, OBIEE patch installation does not provide for an automatic way of keeping track of the patches applied.

Nevertheless, Development is working to make 11g use opatch installer. Opatch provides a way to keep track of previous patches installed. There is no official date for 11G release.

3. It is recommended that you keep a record of the patches you have applied.
You could implement that in the way you prefer, but separated from OBIEE installation, and in addition to replace the version.txt file used in OBIEE.

For example, you could:
– Append the version.txt file to another file, with name version_history.txt or something like that, everytime you apply a patch.
OR
– When applying first patch, rename original version.txt from GA release to version0.txt and copy version.txt from the patch.
Then, when applying second patch, rename version.txt to version1.txt and copy new version.txt from the second patch, and so on.
OR
– copy new version.txt file to a file named like version_<YYYY_MM_DD>.txt, indicating the date when you applied it.
That way you can have in a single directory all the previous version.txt with its dates of installation.

4. OBIEE One-off patches are not cumulative at this time.

5. Production patches (the ones that do not require a password), normally, contain the fixes of older production patches.

6. When we create a new patch for you (that is when you report a new issue, never seen before, and then we create a fix for that and provide it to you) we ask you the list of one-off patches you have applied. Development uses it to create a merged patch including all those fixes plus the new one.

7. In the case a one-off patch is already available (so, it was not produced for you), you would need to open an SR to ask for a password to download it. In that same SR, please, provide the list of patches applied previously, so Support can determine if it is ok for you to apply the patch, or if a merged patch needs to be created for you.

8. When in doubt, ask ORACLE Support if a patch can be applied by you without conflict issues.

nqserver.log message
[2011-01-06T20:20:18.000+00:00] [OracleBIServerComponent] [WARNING:1] [] [] [ecid: ] [tid: 814] Warning: Clustering and cache are enabled for this OBIS node, but cluster aware cache is disabled. This can lead to inconsistencies.

Solution

Workaround: This is a temporary workaround to allow the repository (rpd) to be upgraded.Disable the repository cache in FMw Enterprise Manager Control prior to running the upgrade assistant.

Solution: The upgrade assistant does not update or configure the OBIEE 11g NQSConfig.INI file. It must be updated manually before proceeding with the upgrade. Correct, the root cause which is to configure and enable the cluster aware cache in 11g to match the configuration in 10g prior to running the upgrade assistant.

Note: If your issue does not match this exactly then check the following:

The upgrade assistant log is located at [middleware_home/[oracle_home]/upgrade/logs

If any components fail to start after the upgrade assistant completes, refer to the specific component logs (i.e. nqserver.log, saw0.log)

It may also be helpful to check the webcatupgrade.log and the upgradelog.xml to find items that failed.

Applies to:

Business Intelligence Server Enterprise Edition – Version: 11.1.1.3.0 [1905] and later [Release: 11g and later ]
Information in this document applies to any platform.

Symptoms

1) Customer upgraded 10.1.3.4.1 RPD and web catalog to 11.1.1.3.
2) Its noticed that in 11.1.1.3 the same reports take a lot longer to execute:
Eg: 1 min 30 sec in 11G vs. only 30 sec in 10G.
3) RPD doesn’t have any metadata inconsistencies, connection pool settings are good.
4) The memory usage spikes up when reports are run, and BI Server is taking too long compiling these reports.
5) Customer notices that the XML copied from 10g to 11g creates a more complicated logical query in 11g compared to 10g.
6) When customer copies the logical query from 10g and runs in 11g it gives the same performance as 10g.

Cause

Basically this is caused by many column with the empty string formula: ”, causing it to have 2nd UNION leaf to calculate the subtotal in 11.1.1.3.

Solution

These columns with a column formula ” where used as separators in the report.

Replaced all column separators with “duplicate measure” columns with a column length of 0.
This ensures the subtotals are NOT trying to use the separators as dimensions and create extra queries with UNION ALL.