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

By | In 11g, Art of BI | April 06th, 2012

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.

Contact Us
Christian Screen
Christian is an innovator in analytics and data warehousing design, best practices, and delivery. With more than fifteenyears of decision support and data warehousing with key experiences at Office Depot HQ, Sierra-Cedar, and Capgemini, he oversees the Oracle Analytics Practice which includes the technical development and delivery of Oracle BI collaboration software, data warehouse solutions, Oracle BI/EPM projects, and packaged analytics solutions at Datavail.

Leave a Reply

Your email address will not be published.
Required fields are marked (*).

7 thoughts on “Art of BI: Reasons to Conduct an out-of-place upgrade for Oracle BI 11.1.1.x”
  1. Christian, are you sure it’s safe to transfer the BIPLATFORM (and more importantly) MDS schemas between installations? I seem to recall in chats with BI Product Development that these schemas were very installation- specific/non- transferrable, though I’ve not verified this myself.

    Mark

    1. Mark,

      Yes, there are somethings that need to be adjusted like the usage tracking tables, etc. from the BIPLATFORM scheme. This is where a keen eye during this process would come in place and the potential for leveraging INSERT statements, etc. may be required. Potentially conducing a diff on all these tables should be done (or documented by Oracle) so that we can see just exactly what is being “upgraded” in the first place.

      You are right in that those tables are key and based on a few of the points I highlighted this is another reason to conduct the out-of-place upgrade in order to get this experience so that that an OBI Administrator truly knows their environment, inside and out.

      The other files, like the instanceconfig.xml files, templates, etc. are easy to move around in the file system, but the database side is where the focus needs to be. I’ll probably look into writing up a post to highlight a procedure for the MDS/BIPLATFORM manual migration now that you’ve mentioned it.

    2. Mark,

      Yes, and with 11.1.1.7 I see this is even necessary when moving from OBIEE < 11.1.1.6 especially if wanting to upgrade.

  2. isn’t this pure evidence of incapacity by Oracle, especially in times of iPhones, Androids and the like where it all is just a “one touch” even to get a new OS release installed? Also Microsoft Windows since a 10+ year manages to do an “in place” update. What if I had to buy a second PC for every Windows Patch during the last 15 years? What a waster of time reading all update/upgrade papers just to find out that you have to regression test again yourself anyway.

    1. Thomas,
      I think this happens as a by-product of large software development initiatives they get complacent or when they are after net new customers. Sometimes it’s easier to go with a clean break and force customers one way or another.

    2. I second you Thomas.

      I believe, if Oracle has the audacity to introduce radical changes in
      its tools in every new version, they should at least have the courtesy
      to support older versions. Try asking a question about OBIEE 10g via an SR to Oracle and see what they say.

      They ask you to shift to newer versions as if they cost peanuts and we just need to pick them off shelves in a store. And mind you, this is quite a frequent reply.

      Oracle really needs to learn from Microsoft what it means to “actually” support a product.

  3. I am planning to perform an out of upgrade for 11.1.1.5 to 11.1.1.9. Can you please elaborate on step 2, documentation does not
    list the archive process for other objects like Weblogic Security, Application Roles/Privileges, Custom Folders, RPD and Web Catalog.