Month: March 2012

Uncategorized

In-place upgrade within OBIEE 11 versions (from .3 to .5 o r .6 or from .5 to .6) can be a whole lot quicker than out-of-place ones but are also more interesting in terms of potential issues arising. After two uneventful in-place upgrades from 11.1.1.5 to 11.1.1.6 I had a more challenging third upgrade with some unexpected errors.

If you look at the official upgrade guide, all went fine up to item 6: “Upgrading system components“. Executing upgradenonj2eeapp.sh, however, threw an error while re-deploying:

./upgradenonj2eeapp.sh -oracleInstance /bishiphome/Middleware/instances/myinstance/ -adminHost localhost -adminPort 7001 -adminUsername weblogic

Command failed: NonJ2EEManagement Applicationdeployment failed.


Looking into the provision.log (situated in MW_HOME/instances/myinstance/diagnostics/logs/OPMN/opmn) read as follows:

[Deployer:149163]The domain edit lock is owned by another session in non-exclusive mode – this deployment operation requires exclusive access to the edit lock and hence cannot proceed. If you are using “Automatically Aquire Lock and Activate Changes” in the console, then the lock will expire shortly so retry this operation.


I ran the upgradenonj2eeapp.sh a second time to see what it would do:

SEVERE: Command failed:
oracle.as.config.ProvisionException: Exception while unregistering the instance
    at oracle.as.config.impl.OracleASInstanceImpl.unregister(OracleASInstanceImpl.java:290)
    at oracle.as.config.impl.OracleASInstanceImpl.unregister(OracleASInstanceImpl.java:250)
    at oracle.as.config.provisioner.commands.UnregisterInstanceCommand.execute(UnregisterInstanceCommand.java:34)
    at oracle.as.config.provisioner.InstallerCmdLine.run(InstallerCmdLine.java:146)
    at oracle.as.config.provisioner.InstallerCmdLine.main(InstallerCmdLine.java:46)
Caused by: oracle.as.config.impl.SimpleProvisionException: Failed to unregister instance instance1. It does not exist on the adminserver.

So, a real no-go situation. Luckily, the OBIEE EMG already had a post which contained part of the solution. Root cause of the initial error was that there was a lock on the configuration I hadn’t seen:
“Release Configuration” removed the immediate error source. Next step was re-running upgradenonj2eeapp.sh again to see what would happen and obviously the error “Failed to unregister instance instance1. It does not exist on the adminserver.” still persisted since initially the first half of the script had run through and un-registered my instance. So off to some opmnctl commands to undo the damage.

1.) Deploy the instance again:

./opmnctl redeploy -oracleInstance /bishiphome/Middleware/instances/myinstance -adminHost localhost -adminPort 7001 -adminUsername weblogic

Command requires login to weblogic admin server (localhost):
  Username: weblogic
  Password:

Redeploying NonJ2EEManagement Application…weblogic.Deployer invoked with options:  -adminurl localhost:7001 -username weblogic -name NonJ2EEManagement -source /bishiphome/Middleware/Oracle_BI1/opmn/applications/NonJ2EEManagement.ear -redeploy -upload -noexit

Task 1 initiated: [Deployer:149026]deploy application NonJ2EEManagement [Version=11.1.1] on AdminServer.
Task 1 completed: [Deployer:149026]deploy application NonJ2EEManagement [Version=11.1.1] on AdminServer.
Target state: redeploy completed on Server AdminServer

Done
Command succeeded.


2.) Register the instance again:

./opmnctl registerinstance

Command requires login to weblogic admin server (localhost):
  Username: weblogic
  Password:

Registering instance
Command succeeded.

 After these steps, I was able to run the actual shell for the upgrade process again:

./upgradenonj2eeapp.sh -oracleInstance /bishiphome/Middleware/instances/instance1/ -adminHost localhost -adminPort 7001 -adminUsername weblogic
Unregister instance…

Command requires login to weblogic admin server (localhost):
Username: weblogic
Password:

Unregistering instance
Command succeeded.
redeploy NonJ2EEManagement.ear…

Command requires login to weblogic admin server (localhost):
Username: weblogic
Password:

Redeploying NonJ2EEManagement Application…weblogic.Deployer invoked with options:  -adminurl localhost:7001 -username weblogic -name NonJ2EEManagement -source /bishiphome/Middleware/Oracle_BI1/opmn/applications/NonJ2EEManagement.ear -redeploy -upload -noexit

Task 2 initiated: [Deployer:149026]deploy application NonJ2EEManagement [Version=11.1.1] on AdminServer.
Task 2 completed: [Deployer:149026]deploy application NonJ2EEManagement [Version=11.1.1] on AdminServer.
Target state: redeploy completed on Server AdminServer

Done
Command succeeded.
re-register instance…

Command requires login to weblogic admin server (localhost):
Username: weblogic
Password:

Registering instance
Command succeeded.
Successfully upgraded NonJ2EEManagement.ear and the registeration.

 One of those little things that can ruin your evening…

Cheers!

Uncategorized

It has been 19 months since the GA of OBIEE
11g and its third incarnation (11.1.1.6) is celebrating its one-month-birthday
today. Time to make a point on the support situation for all OBIEE 10g
implementations out there:
The last 10gR3 versions (10.1.3.4.x) will
reach the end of the Permier Support lifecycle in 4 months, July 2012.
 
The full documentation for lifetime support
of Fusion Middleware products can be found here, on the Oracle website
(last updated February 2012). The screenshot above can be found on page
13 of the pdf.
So to wrap up: the product has had more than
one and a half years to mature, Oracle provided us with two new version
since the release and with the end of premier support quickly coming up,
this is really the moment to start thinking about upgrading your 10g solutions!
Uncategorized

It’s time again. This years BI forum (#biforum) is open for registration!

All information on topics, speakers and locations can be found here:
http://www.rittmanmead.com/biforum2012/

Direct registration links for Brighton and Atlanta respectively are here:
Booking form for UK BI Forum Event (Brighton, May 8th – 11th 2012)
Booking form for US BI Forum Event (Atlanta GA, May 15th – 18th 2012)

Thanks to Mark and his crew for continuing to host this awesome event!

Uncategorized

When hooking up OBIEE 11g to an LDAP, make sure to check some factors on the LDAP side of things as well. Not all errors have to come from your configuration in WLS:

  1. LDAP users intended to replace “OracleSystemUser”, “weblogic” and “BISystemUser MUST” all reside in the same base DN that’s used to search for users in the LDAP config
  2. They also MUST all be of the same objectClass as the one referenced in the LDAP config
  3. Creating “technical users” to distinguish them from “human users” and putting them in different branches and / or storing them as different object classes (e.g. “account” or rather than “person”)

First thing you should get is an LDAP browser with which to connect to the LDAP server to check validity of the connectivity ccount (i.e. the “Principal” for LDAP connectivity) as well as structures and object types. This will save you a lot of pain and suprising behaviour due to “ceative” LDAP management.

Cheers!