Category Archives: OBIEE 11G


You have an OBIEE instance and a lot of folders and requests for the Administrator user.
You upgrade to, using the ua.bat tool. It finishes as complete and there are no errors in the the Upgrade Assistant (ua) log files:


For example

In OBIEE, when you log in as Administrator and go to the Catalog option, you are not able to see any folder or request.


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 to

What should have happened?
You should be able to see all folders and request you had in after 
upgrading to

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, 
there are a lot of folders and request in

What are the symptoms of the problem?
You have a web catalog in When you log in as Administrator in 
this version you see a lot of folders and request for that user.

  You upgrade to 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 and you cannot see any folder or request.

What changes have been made to the technical environment recently?

Suggested workaround is the following:
 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:
 3) Upgrade the Web Catalog using the ua.bat:
 4) Using Catalog Manager, copy the content of the 'new_account' user into the Administrator one.
 For instance:
 5) Connect to OBIEE as Administrator and check you are able to see all folders and requests.

OBIEE 11g Upgrade Assistant (UA) Fails When Upgrading A 10g RPD File To OBIEE 11g

Applies to:

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

On OBIEE, When attempting to upgrade a 10g RPD file via the Upgrade assistant
( ) , the upgrade fails and the following error can be seen in the log file:

[BIEE] [ERROR] [] [upgrade.BIEE] [tid: 18] [ecid: 0000IoEFnYP2RP1pNsXBie1D4VU2000009,0] Error in starting opmn server[[
Operation aborted because of a system call failure or internal error
at oracle.ias.upgrade.config.oraclebi.OPMNUtil.startOpmn(

[Framework] [ERROR] [UPGAST-00138] [upgrade.Framework] [tid: 18] [ecid: 0000IoEFnYP2RP1pNsXBie1D4VU2000009,0] upgrade exception occurred
[Framework] [ERROR] [] [upgrade.Framework] [tid: 18] [ecid: 0000IoEFnYP2RP1pNsXBie1D4VU2000009,0] Cause: An unexpected upgrade exception has occurred. Action: See the secondary error message for additional details.
[Framework] [ERROR] [] [upgrade.Framework] [tid: 18] [ecid: 0000IoEFnYP2RP1pNsXBie1D4VU2000009,0] Error in starting opmn server[[
Operation aborted because of a system call failure or internal error



The system component services for BI components are not started.

The upgrade assistant is not able to communicate to OPMN.


  1. Start OPMN services via the command:

    [middleware_home]/instances/instance1/bin> opmnctl startall

  2. Confirm the status of opmn and the system components under the instance home with:

    [middleware_home]/instances/instance1/bin> opmnctl status

Note: You may  also start the System Components and check the status via Fusion Middleware Control


  1. Retry the RPD file upgrade.


How to Keep Track of OBIEE 10g Patches Applied? How To Handle Version.Txt Files When You Have Multiple Patches? Are Patches Cumulative?

Applies to:

Business Intelligence Server Enterprise Edition – Version: to [2405] – Release: 10g to 10g
Business Intelligence Suite Enterprise Edition – Version: to [2405]   [Release: 10g to 10g]
Information in this document applies to any platform.


– How to handle VERSION.TXT files when you have multiple patches?

– 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?


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.
– 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.
– 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.

Upgrading OBIEE 10g Repository To 11g Using The Upgrade Assistant ( UA ) Fails To Start The BI Server

Applies to:

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


The 10g repository fails to upgrade when running the Upgrade Assistant Utility because the BI Server will not restart.


The OBIEE 10g Repository was configured for a cluster aware cache

10g NQSConfig.INI file (partial)

// A comma separated list of <directory maxSize> pair(s)
// e.g. DATA_STORAGE_PATHS = “d:\OracleBIData\nQSCache” 500 MB;
DATA_STORAGE_PATHS = “E:\OracleBIData\cache” 500 MB;
MAX_ROWS_PER_CACHE_ENTRY = 100000; // 0 is unlimited size


// Cluster-aware cache

GLOBAL_CACHE_STORAGE_PATH = “\\01AL10015011002\Global_BI_Cache” 1000 MB;

However, OBIEE 11g was not configured for a cluster aware cache prior to the upgrade assistant running

11g NQSConfig.INI file (partial)


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.



  1.   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.
  2. 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.


Obiee 11g: After upgrade from 10g, 11g report generated UNION ALL in SQL

Applies to:

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


1) Customer upgraded RPD and web catalog to
2) Its noticed that in 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.


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


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.