WebLogic startup failure – BackendRoot cannot cast to BackendStandard

My colleague from a previous company contacted me recently to help with a problem. OBIEE was not starting up.  They had a power failure the night before, and then OBIEE would not start up.  The system is OBIEE 11g on Linux.

This is the error that was generated when trying to start the WebLogic Admin Server…


<Mar 28, 2014 9:11:35 AM EDT> <Critical> <WebLogicServer> <BEA-000362> <Server failed. Reason: There are 1 nested errors: java.lang.ClassCastException: com.octetstring.vde.backend.BackendRoot cannot be cast to com.octetstring.vde.backend.standard.BackendStandard         at weblogic.ldap.EmbeddedLDAP.start(         at         at         at > < Mar 28, 2014 9:11:35 AM EDT> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to FAILED> < Mar 28, 2014 9:11:35 AM EDT> <Error> <WebLogicServer> <BEA-000383> <A critical service failed. The server will shut itself down> < Mar 28, 2014 9:11:35 AM EDT> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to FORCE_SHUTTING_DOWN>


After trying a few things that did not resolve the issue, an online search helped with the solution. This post was very helpful:

After reading through the post, we went to the below directory on the OBIEE server (Linux) and examined its contents:


[oracle@[SERVERNAME]]$ cd /u01/product/middleware/user_projects/domains/bifoundation_domain/servers/AdminServer/data/ldap/ldapfiles [oracle@aeledwpbi ldapfiles]$ ls -l total 11308

-rw-r—– 1 oracle oinstall 10071624 Mar 27 08:40
-rw-r—– 1 oracle oinstall    56940 Mar 27 08:40 changelog.index
-rw-r—– 1 oracle oinstall   804359 Mar 27 08:40
-rw-r—– 1 oracle oinstall     2028 Jun 25  2013 EmbeddedLDAP.delete
-rw-r—– 1 oracle oinstall     3576 Jun 25  2013 EmbeddedLDAP.index
-rw-r—– 1 oracle oinstall        0 Mar 28 12:36 EmbeddedLDAP.lok
-rw-r—– 1 root   root       615242 Mar 27 08:40 EmbeddedLDAP.tran
-rw-r—– 1 oracle oinstall        8 Mar 27 08:40 EmbeddedLDAP.trpos
-rw-r—– 1 oracle oinstall        8 Mar 27 08:40 EmbeddedLDAP.twpos

Note how one of the files (EmbeddedLDAP.tran) is owned by “root”. It seems the power outage caused something unusual to happen resulting in “root” being assigned ownership of the file.

After having the system administrator change the owner from “root” to “oracle” (the OBIEE admin user), we were able to start the OBIEE system back up.


New OBIEE Tuning Guide (Version 4) – released Jan 2014

A new version of the OBIEE Tuning Guide (Version 4) was released in January, 2014.  It is suitable for OBIEE and versions.

It can be found on Oracle Support under Document ID 1333049.1.   Or here is a direct link to the document (PDF).


New highlights from the previous document include:

  •     Optimized JVM switches for JRockit / Sun JVM / IBM JVM
  •     New tuning parameters settings / values for JavaHost / OPIS / OBIS components.
  •     Improved performance monitoring techniques.
  •     IBM WebSphere tuning parameters.
  •     More WebLogic Server tuning parameters.
  •     Windows Server 2012 tuning parameter.
  •     New optimized Linux / AIX tuning parameters.
  •     Additional Essbase ASO tuning parameters.
  •     libOVD authenticator search tuning


As always, this document provides us with recommended baselines or starting points, but the appropriate settings for each environment will vary.

User having inconsistent login issues or user taking a long time to login or authenticate in OBIEE 11g

If you are using Active Directory for authentication for your OBIEE system, and are experiencing situations where some users are taking a long time to authenticate/login, then this post might be helpful.  This could also be useful for configuring LDAP systems other than Active Directory, but I cannot say for sure.

What could potentially be happening to users experiencing the problem is … they belong to Active Directory groups (or LDAP groups) with deep hierarchies, and the system has to traverse all those hierarchies to retrieve all their LDAP information which ends up taking quite a bit of time.  A possible solution is to limit the number of LDAP levels that will be searched/traversed to get the users Groups information.

Login to WebLogic Administration Console (aka WLS or Admin Console), then click on “Security Realms” on the left, and then click the name of the realm that you use for security (for example, “myrealm”).


Click the Providers tab.   And then click the name of your Active Directory provider.


Then select the Provider Specific tab.


Scroll down to the section titled “Groups”.


Change the Group Membership Searching setting from unlimited to limited.

And then set Max Group Membership Search Level – change it from 0 (no limit) to 1 (or to the smallest number necessary for your environment).

This will prevent long searches for those users that are in many groups with deep hierarchies (such as groups within groups within groups and so on). This could cut the search time tremendously, thereby reducing the authentication time and preventing login timeouts.

Good luck!

Forgot weblogic user password – How to reset the weblogic user

If you have forgotten your weblogic user password, and would like to reset the user, this post might help…

One of my colleagues could not remember the password for his weblogic user in his local OBIEE installation, and asked for my assistance.  I did not know how to go about resetting the password, and so I had to search for a solution. 

After trying the steps from a few different posts related to this issue, the steps in the post found here worked.

I made a few minor modifications and copied the steps here for your convenience.


Note: This process will remove all users created in WebLogic’s embedded LDAP server and there will only be one user (which will act as superuser) after doing below steps.


Steps to recreate weblogic superuser (when password of existing user is forgotten)

1.      Shutdown WebLogic Server (If Running) – Optional Step

2. Login to WebLogic Server and set environment variable

cd $DOMAIN_HOME/bin   (where DOMAIN_HOME is the directory in which your domain exists, default value is $MW_HOME/user_projects/domain/base_domain), and execute the following …

. ./ (Linux/Unix)  -or- setDomainEnv.cmd (Windows)


3. Create an initialization file using the following command. (Note the DOT at end of this command)

java <weblogic_username> <weblogic_user_password> . 

For Example – (Note the DOT at end of this command):

java weblogic welcome1 .

This will create file  DefaultAuthenticatorInit.ldift in directory from which you executed this command .


4. Rename the original file DefaultAuthenticatormyrealmInit.ldift in the $DOMAIN_HOME/security/ (for example, rename to ORIG_DefaultAuthenticatormyrealmInit.ldift) and replace it with the new DefaultAuthenticatorInit.ldift generated in step 3


5. Rename the data directory under $DOMAIN_HOME/servers/<serverName>/data (for example, rename it to another directory like data.bak – the data directory contains files related to embedded LDAP and role mapping file).

Perform the above for the Admin Server, that is, where <serverName> is AdminServer; and then repeat the step for the managed server(s).

Repeat this step for all managed servers which are part of this domain.

Note: This step will remove all existing users/groups from WebLogic’s embedded LDAP server (recreate these users/groups in setp8)


6. Recreate the boot.properites file under $DOMAIN_HOME/servers/<serverName>/security with username and password created in step 3 above.  The contents of the file will be like this …

As before, perform the above for the Admin Server, that is, where <serverName> is AdminServer; and then repeat the step for the managed server(s).

Repeat this step for all managed servers which are part of this domain.


7. Start (or restart) Admin Server and test if you can login to WebLogic Console using the new username and password. Access the WebLogic Console from a URL similar to this: http://<server>:7001/console


8. Recreate any users/groups (which were part of default authenticator prior to new super user creation) or import existing users (from WebLogic’s servers embedded LDAP server backup)

OBIEE Tuning Whitepaper from Oracle (has been updated)

Oracle has released an updated version of their OBIEE Tuning Whitepaper.

You can find the document here …

… or here …

You will need to have an Oracle ID to access it (which is a free sign up).

In addition to all the great information that was in the original document, the updates to the document include:

  • New improved HTTP Server Caching algorithm
  • Oracle iPlanet Web Server tuning parameters
  • New tuning parameters settings / values for OPIS/OBIS components

The topics included in the document are:

1.0 Performance Overview

1.1 Introduction to Oracle Business Intelligence EE Performance
1.2 Performance Terminology
1.3 Understanding Key Performance Drivers

2.0 Top Tuning Recommendations for OBIEE

2.1 Tune Operating Systems parameters.
2.2 Tune Oracle WebLogic Server (WLS) Parameters
2.3 Tune 64bit Java Virtual Machines (JVM)
2.4 Tune 32bit Java Virtual Machines (JVM)
2.5 Tune HTTP Server Parameters
2.6 Tune HTTP Server Compression / Caching
2.7 Tune Oracle Database Parameters

3.0 Performance Monitoring OBIEE

3.1  Built-in BI Metrics for Performance Monitoring
3.2  Performance Monitoring In Windows Environment
3.3. Performance Monitoring In Unix Environment

4.0 Tuning OBIEE Components

4.1 Oracle BI Presentation Services Component
4.2 Oracle BI Server Component

5.0 Tuning Essbase

5.1 Essbase ASO Tuning

UPGAST-00014 error when upgrading OBIEE 10g RPD and Catalog to 11g

If you get this error during Step 4 of the Upgrade Assistant for upgrading OBIEE 10g RPD and/or Catalog to 11g, then this post might be helpful.

UPGAST-00014: unable to connect to WebLogic Server at localhost:7001
t3://localhost:7001: Destination unreachable; nested exception is: Connection refused; No available router to destination


Perform the following steps that may resolve your problem:

– Log in to Administration Console.  http://yourserver:7001/console
– Click the ‘Servers’ link.


Then in the Summary of Servers page / Configuration tab, click ‘AdminServer(admin)’.


– From the Settings for AdminServer page, select the ‘Protocols’ tab, then the ‘Channels’ subtab.
– And then Click ‘Lock & Edit’ button in the upper left Change Center.


– Click the New button to begin creating a new Network Channel.
– Enter the following information…
Name: Loopback (or whatever name you like)
Protocol: t3

– The click Next


– The enter …
Listen Address: localhost
Listen port: 7001
Click Finish


The new Network Channel (Loopback) is added.  Activate the changes by clicking on the “Activate Changes” button.


Now, retry running the Upgrade Assistant. There is no need to restart any of the services. 
You should now get past Step 4 (the point at which you were getting the error before).