The ArtOfBI.com Newsletter

Is stupid new and freshly informative on BI and EPM.

Save one little gremlin by not pouring water on its head.

Or, sign up for killer tips, tricks and other BI / EPM goodness delivered right to your inbox.

Hell just do both. Enter your email below.

Oh no what happened?
I already signed up.

BTW, Signing up gets rid of this annoying banner.

Cheers,
Christian & The ArtOfBi.com Team

Art of Business Intelligence > 11gtitle_li=Best Practice

Archive | OBIEE

Reasons to Conduct an out-of-place upgrade for Oracle BI 11.1.1.x

I received a comment on one of the last post regarding upgrading a Oracle BI 11.1.1.6 from 11.1.1.5 and why I recommended doing a out-of-place upgrade, i.e. deinstall and re-install of the updated version, versus using a patch of 11.1.1.6 over 11.1.1.5.  So on a plane ride a few weeks ago I made a short list of reasons to clarify.

Oracle

Oracle (Photo credit: joepub)

I made the comment that I “recommend conducting a re-install of Oracle BI 11g (for 11.1.1.6) instead of conducting an in-place upgrade” and “…an in place upgrade is a bad idea in my opinion”. Let’s be clear, that this statement was made regarding a minor patch release and not a release patch of Oracle BI 11g.  The former requires the download of all compressed installation files while the latter requires the download of a single one-off patch file/script that is then executed using OPatch.

If that’s clear then here are the top X reasons I would recommend conducting a full de-install and re-install of the Oracle BI 11g platform when upgrading minor releases:

1.  The Oracle documentation does not describe one approach as a best practice versus the other.

2. All major artifacts such as WebLogic Security, Applications Roles/Privilege files, Custom Folders, RPD, web catalog can be easily archived and restored just as easily.  This in my opinion should already be conducted via a weekly backup process so that the key artifacts can be easily retrieved, especially if operating in a highly used OBIEE environment.

3. The RCU database tables, etc. can be data dumped and restored carefully enough into the new RCU MDS/BIPLATFORM schemas.  Selecting just the core pieces from these schemas such as auditing, usage tracking ,etc. can be done quite efficiently using INSERT backups or similar routine with your favorite SQL IDE.

4. Most companies haven’t leveraged Oracle BI 11g to its fullest anyway so conducting this full effort for the larger percentage of users this is no more disruption to the environment that the in-place upgrade and possibly less since the team will have been familiar with the Oracle BI 11g de-install and install process.  The advantage here is experienced gained – see next reason.

5. The OBI team becomes much more versed to the workings of the Oracle BI architecture by doing an uninstall and re-install

6. A de-install prevents the chance of screwing something up in the under pinnings of the FMW environment by modifying critical pieces of the environment using a non-automated upgrade process such as the inlace upgrade.

High-Availability configurations of Oracle BI 11g would be my only hesitation with this logic, but again, the fact that the original installation should have been very well documented should allow a de-install to be more efficient than an in-place upgrade.  Taking also into consideration that if a team wants to move from 11.1.1.5 to 11.1.1.6 then this is already an effort where they will have to schedule time for the process, such as downtime of the system, etc. They might as well do it right the first time with no chance of having backlash later on with an issue that they can’t track down.  We’ve seen how deep that FMW file structure is, right?  So, get the experience, and reduce the chance for any hidden problems from arising.

I’m curious to any feedback you may offer.

Thanks to Robin for asking the burning question which prompted this reply post.

Posted in 11g, Best PracticeComments (2)

Proxy Act As Cannot Cross Identity Providers

The proxy act as capability of Oracle BI is still well and alive in 11g.

I came across this error recently when configuring this functionality, “Actual user’s GUID is not empty but Acting as user’s GUID is empty.”

The GUIDs have a lot to do with the way the proxy user is able to log into Presentation Services as the target user.  Refreshing GUIDs can also play a role in affect the correct configuration with Proxy As.

This error however, is due to the fact that the implementation was using two different Identity Providers which apparently breaks the functionality of the Proxy As feature.

For example, I want to log into OBI Dashboards as the ‘weblogic‘ user which is housed under the default Identity Provider of the WLS LDAP system.  I want to set up my proxy as table so that the ‘weblogic’ user can proxy as a target user that resides in an MS Active Directory LDAP Identity Provider that I’ve configured in WLS or that I am using via the backwards compatible 10g security method stemming from the RPD (I tested this using only the latter method).  So, I’d set up my proxy table to show the combination of weblogic user to MSAD user with full privileges.  The outcome of this is that when I log in with the ‘weblogic’ user, I am able to see my MSAD user in the Act As dropdown list.  That is accurate because that is just a database retrieve.  However, if I select the MSAD user from the list to act as that user, I will be sent to the login screen of Presentation Services and the proxy as login will fail.  The error message above will be logged and can then be seed from the Diagnostics tab within the Fusion Control console.

So, ultimately you can only proxy Act As with a users stemming from the same Identity Provider.

In my opinion that is how is should work anyway.  Just know that the limitation exists.

Let me know if you’ve figured out a work around or if I missed something.

Enhanced by Zemanta

Posted in 11gComments (0)

Creating a New Presentation (Web) Catalog in OBI 11g

Here is a crib-sheet on creating a new Presentation Catalog in OBI 11g.

The Oracle BI Server and WebLogic Server should be up and running.

  1. Stop the system component service for Presentation Services.
  2. Specify a new web catalog folder location (one that does not exist) for the catalog on the Repository tab of the Deployment main tab page in Fusion Middleware Control Enterprise Manager.
    • Example: <INSTANCE_HOME>/…/catalogs/mynewcatalog
  3. Apply Changes.
  4. Activate Changes.
  5. Restart Presentation Services.

Upon restarting presentation services the new web catalog folder will be  created for you automatically and be set as the active catalog.

References

Posted in 11g, OBIEE, Tricks n' TipsComments (0)